Update chrono from 2.3.9 to 2.4.1

Description
We need to update chrono from 2.3.9 to 2.4.1
Background:

#1061
#1176 - which has detail on the changes between the two versions

chrono 2.4.1 has features that we would like, and also changes the wording for expressing some dates.
@Cito and @kenfeliciano have recorded lots of useful information in #1176.
Recommendation
The latest from @Cito is:

Suggestion: Maybe we can add a constant that contains the currently used version of chrono, and also setting that stores the last used version (if missing, it would be considered to be 2.3.9). When the plugin loads, we check whether the two differ, and in this case we show a warning with a link to the chrono changelog or a special page in our docs that lists all incompatible changes in chrono. After showing the warning, we update the chrono version in the settings, so that the warning will not appear again.

Of course when updating chrono to an incompatible version, we should also update at least the minor version of Tasks. A new major version is not really required in my view. In any case what we should not do is wait for the next major version and only then update chrono. I think the earlier we update, the fewer users will have relied on the old chrono.

I agree with all this, especially "I think the earlier we update, the fewer users will have relied on the old chrono."
Required Steps

Actually update the dependency
Update the docs
Add new tests
Suggestion: show a warning with a link to the chrono changelog or a special page in our docs that lists all incompatible changes in chrono, when the user updates

How to Test
The areas that use chrono are:

Date filters
Add/edit Task
Auto-complete

Also:

It would be good to see jest tests for the newly-available instructions, to detect any possible breakages in future chrono updates

Just want to mention something that bit me today when experimenting with the new version of chrono: When figuring out how chrono interprets dates, you may be tempted to use the "edit task" dialog, because it displays the parsed dates. However, be aware that in this dialog, dates are interpreted with the "forwardData" flag, i.e. they will be always in the future, even if you enter dates like "last Monday". This is different how these dates are interpreted in filters.
Maybe we should add a checkbox "force future dates" to the edit task dialog that would be checked by default, but could be also reset. Could be useful for testing and also to enter tasks with missed deadlines that shall be shown as overdue.

Oh that's interesting. I had looked in the current EditTask.svelte and not seen where it specified forwardDate, so assumed it was false.
I think my head is about to explode! 🤯

Maybe we should add a checkbox "force future dates" to the edit task dialog that would be checked by default, but could be also reset. Could be useful for testing and also to enter tasks with missed deadlines that shall be shown as overdue.

I do quite like this idea, though I'm a bit worried that the scope of 'updating chrono' just keeps on growing! 😄

not seen where it specified forwardDate

It does so in the parseDate method and also in the _onSubmit method.
I have created PR #1183 for the additional checkbox now. I think this is a feature separate from this issue.


Opinion on noised clip

Glide and dalle2 use a noised clip
Openai reports in dalle2 paper that it improves things a bit compared to vanilla clip
What do you think about this? Is that noised clip important ? Could it have more properties beyond improving diffusion ? (IE could it improve robustness for zero shot / retrieval/ clip guiding)

Could it have more properties beyond improving diffusion ? (IE could it improve robustness for zero shot / retrieval/ clip guiding)

In my experience with adversarial training, a little bit of training on (even slight) perturbations in an image can greatly improve your ability to perform on adversarial samples. You may see a slight decrease in performance in the higher-percentiles of accuracy, but overall I would expect an a more robust model.
It's probably worth noting, however, that slight perturbations aren't as aggressive as a x_t noised images. It is unclear what exactly they mean by "noise-aware CLIP" ... but If you had some way of informing CLIP what noise-level you are at  (i,e, an additional input token) you may be able to generalize to both (heavier noised) clip-guidance tasks, as well as (lower-noise) tasks like zero-shot and retrieval.
I could imagine such a large contrastive model like CLIP would have incredibly sensitive gradients. As a result the biggest gain, as mentioned in the GLIDE paper, would be to have the proper gradients as you guide the diffusion process. Those early steps are crucial for landing you in the proper image space. Undoubtedly, this is why they continued to use the noised clip from GLIDE in DALLE2 as they probably found it necessary to taking the performance of clip-guided diffusion to the next level.

the current designs of denoising the image embeddings that we see as the diffusion prior

nice catch, I didn't even make that connection--I think you might be right!

I think we got this answered and don't need to do any action on this here


Update to vscode-flow v0.6.1

Work towards #306
Description
Update the binary of the extension to the latest version v0.6.1

For contributor use:

[x] Targeted PR against master branch
[x] Linked to Github issue with discussion and accepted design OR link to spec that describes this work
[x] Code follows the standards mentioned here
[x] Updated relevant documentation
[x] Re-reviewed Files changed in the Github PR explorer
[x] Added appropriate labels

Codecov Report

Merging #307 (c534e18) into master (4928b2b) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #307   +/-   ##
=======================================
  Coverage   52.41%   52.41%
=======================================
  Files          36       36
  Lines        1778     1778
=======================================
  Hits          932      932
  Misses        724      724
  Partials      122      122

Flag
Coverage Δ

unittests
52.41% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out 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 4928b2b...c534e18. Read the comment docs.


Update docker ssh passthrough docs

As discussed in Discord with @zeripath, a major rewrite and simplification of the docker SSH passthrough docs.
Changelog summary

Remove the option to create a softlink for .ssh/authorized_keys → confusing and unstable due to SSH_AUTHORIZED_KEYS_BACKUP option
Explain in more details how the SSH request process is happening from start to end
Pretty much rewrite the section from scratch in passive voice

Related issues

https://github.com/go-gitea/gitea/issues/12625
https://github.com/go-gitea/gitea/issues/13716
https://github.com/go-gitea/gitea/issues/12625
https://github.com/go-gitea/gitea/issues/11318
and possibly more

I am not sure if PR https://github.com/go-gitea/gitea/pull/12626 is valid or not - for me it worked with the current setup on the latest dev version. But this is not necessarliy important for this PR.

Codecov Report

Merging #13732 (22a4106) into master (e7b47c5) will increase coverage by 0.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master   #13732      +/-   ##
==========================================
+ Coverage   42.19%   42.21%   +0.01%
==========================================
  Files         697      697
  Lines       76825    76825
==========================================
+ Hits        32418    32430      +12
+ Misses      39059    39048      -11
+ Partials     5348     5347       -1

Impacted Files
Coverage Δ

modules/process/manager.go
72.50% <0.00%> (-2.50%)
:arrow_down:

services/pull/pull.go
40.68% <0.00%> (-0.50%)
:arrow_down:

modules/queue/workerpool.go
60.81% <0.00%> (+0.81%)
:arrow_up:

modules/log/event.go
59.90% <0.00%> (+0.94%)
:arrow_up:

modules/log/file.go
75.20% <0.00%> (+1.60%)
:arrow_up:

services/pull/patch.go
55.68% <0.00%> (+1.70%)
:arrow_up:

services/pull/check.go
51.82% <0.00%> (+2.91%)
:arrow_up:

services/pull/temp_repo.go
29.78% <0.00%> (+3.19%)
:arrow_up:

Continue to review full report at Codecov.

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

Thanks for this PR, @pat-s, it helped me get ssh passthrough working :)


Fails to save big DB to remote [tested on GDrive & OneDrive]

KeePass
OS
plugin version

2.39.1
Win 10 x64 pro (french) 14393
1.4.1

Introduction
It seems this issue only occurs on DB which size is > 5 MB. One of my DB is used to save documents like images or pdf (ID, etc.) as attachments in several entries. This DB size is 5.06 MB. My main DB size is 0.99 MB and the sync feature works. This bug is discussed on Keepass forum here.
Steps to reproduce

Add GDrive or OneDrive account to KeeAnywhere
Test by Open from cloud drive… and load you db → it works
File>Synchronize>Synchronize with URL

Results

No issue to read the DB from cloud.
The sync is reported as successful but there is a warning dialog during process and my DB on the cloud has not been updated
GDrive

OneDrive

Note: Sync used to work with no issue at least until june 2018 with big DB. Plugin successfully used during at least 1 year.
Steps to try to solve/debug to no avail

Delete PluginCache folder
Delete/recreate GDrive account on KeeAnywhere
Clear offline cache in KA settings
Disable Windows firewall and everything I think it could affect connection

Note: I uninstall KeeAnywhere then tried the KeePassOneDriveSync plugin and I had the same sync issue, it can read/download from the cloud but not write/upload to it.

Thanks for you issue report.
I will take a look to improve this. Seems to be the same limitation on both providers. Maybe others follow the same restriction.
Ressources:

https://blogs.technet.microsoft.com/sharepointdevelopersupport/2018/02/05/uploading-large-files-using-microsoft-graph-api/

@freMea: could you please measure the time span between hitting "save" and the occurance of this error?


most recent basemap package for win64+py27 broken?? (1.1.0 build 5)

Issue:
The most recent basemap package available through conda-forge for win64+py27 that gets installed by default seems broken (see e.g. here, breaking our appveyor CI tests in obspy/obspy). I think the underlying problem (proj data directory not being found) was already fixed on master but at the same time of the fix the builds for win-64+py27 were deactivated, so no packages including the fix were built for win64. In any case this problems seems to circle around certain combinations of basemap+pyproj+proj4 installed versions.
After some hours of debugging I still don't understand what is getting wrong and why PROJ_LIB env var is empty in our CI (untarring the packages that get installed there have it properly in the activation script).
I'll try to monkey patch this in our CI by setting PROJ_LIB manually for now, lacking a better solution right now..

@megies we are stretched thin and fixing Windows+Python 2.7 is not a priority at the moment. Do you want to send PRs back-porting the fixes?

Closing this as a won't fix b/c it would need a rebuild of old proj.4 that works with vc9, than pyproj, than basemap. I don't have the time for that and the advantages of supporting a deprecated package, on a dying Python version, on Windows is really low at the moment.


zsjed: init at 0.3

Motivation for this change
Packaging my semi-stenography tool (hiding file snippets at the end of other files).
Things done

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

[X] NixOS
[ ] macOS
[ ] other Linux distributions

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

Could I do anything to speed this process up?
(I think nix.useSandbox is enabled by default in NixOS, so that is already done; I'm unsure what "relevant documentation" in this case might be)

I think nix.useSandbox is enabled by default in NixOS, so that is already done

yes it is.

I'm unsure what "relevant documentation" in this case might be

Not relevant for simple packages.

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

1 package failed to build and already failed to build on hydra master:

zsjed: plain log  |  pretty log

The following issues got detected with the above build packages.
Please fix at least the ones listed with your changed packages:

zsjed:

checkPhase should probably contain runHook preCheck and runHook postCheck.
Near pkgs/tools/misc/zsjed/default.nix:29:3:
   |
29 |   checkPhase = ''
   |   ^

See: https://github.com/jtojnar/nixpkgs-hammering/blob/master/explanations/missing-phase-hooks.md
installPhase should probably contain runHook preInstall and runHook postInstall.
Near pkgs/tools/misc/zsjed/default.nix:46:3:
   |
46 |   installPhase = ''
   |   ^

See: https://github.com/jtojnar/nixpkgs-hammering/blob/master/explanations/missing-phase-hooks.md

I'm probably going to port zsjed in a few weeks, and this program isn't critical, so I'm skipping this for now.


Kubelet dying on error - root container [kubepods] doesn't exist

Bug
Environment

Platform: bare-metal
OS: fedora-coreos
Release: 61557e89a66248f846250f0faa7dd5138f54f9f7

Problem
Kubelets on 2 of our worker nodes would die, and get into this loop of dying/restarting with the following error: Failed to start ContainerManager failed to initialize top level QOS containers: root container [kubepods] doesn't exist
Reboot fixes it. But some would die again at some point later, thus getting into the same loop.
Eventually, we had to set the following kubelet parameters in order for kubelet to come up successfully.
--cgroups-per-qos=false
--enforce-node-allocatable=""
We got this workaround from this old thread
All of our worker nodes are on the same kernel. They might have all had this issue in the past where we simply rebooted them. We started digging into this issue when one worker node repeatedly ran into this within the last few days.
Desired Behavior
Kubelet should be able to come up successfully.
Steps to Reproduce
On the problematic worker node, if I remove those parameters and restart kubelet, it would get into this dying/restarting again with the same error.

This was a known race in upstream Kubernetes QoS before Kubernetes v1.16.0. It hasn't been observed on our Fedora CoreOS clusters on any plaform since QoS was enabled September last year.
Please check you're on a recent Kubernetes and Fedora CoreOS version. If you can reproduce the issue after that, please provide the details of your digging.

After i opened this issue, another node starting showing the same behavior, and I had to put the same workaround in there to prevent kubelet from failing. All of my worker nodes are on the same kernel. I know this should've gotten fixed already, which is why it's so puzzling. I've attached the kubelet snippet that shows from starting to dying. I am hoping to get some insight on what's going on.
kubelet.log
uname -r
4.19.106-coreos

Client Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.3", GitCommit:"06ad960bfd03b39c8310aaf92d1e7c12ce618213", GitTreeState:"clean", BuildDate:"2020-02-13T18:06:54Z", GoVersion:"go1.13.8", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.4", GitCommit:"8d8aa39598534325ad77120c120a22b3a990b5ea", GitTreeState:"clean", BuildDate:"2020-03-12T20:55:23Z", GoVersion:"go1.13.8", Compiler:"gc", Platform:"linux/amd64"}

Looks like you're actually using CoreOS Container Linux (unknown version) and Kubernetes v1.17.4 (hyperkube).
On CoreOS Container Linux clusters, the Kubelet has used QoS defaults from the very earliest releases. There have been no changes or observations of QoS cgroup issues on our CL clusters on any platform (including v1.17.4 on bare-metal, when it was the current version).
Given that, be sure CoreOS is updated, look into any modifications you may have made (e.g. cgroup driver), and remove any privileged workloads that could be mucking with docker or other settings, compare your nodes to determine how they differ. If it happens to existing nodes (rather than fresh nodes with no workloads), consider what recently ran on those. This is about the extent of the support advice I'll offer.

Thanks @dghubble, much appreciated.


how to display the function of ${ test }$?

I add the below code in my header.php,but it do not work.
	<script type="text/javascript" id="MathJax-script" async src="/opt/homebrew/var/www/WordPress/wp-content/plugins/mathjax-latex/mathjax/es5/tex-svg.js">
	</script>

	<script>
		MathJax = {
		loader: {
				load: ['[tex]/textmacros']
			},
		tex: {
			inlineMath: [['$', '$'], ['\\(', '\\)']],
			packages: {'[+]': ['textmacros']}
		},
		svg: {
			fontCache: 'global'
		}
		};
	</script>

There is not really enough information here to tell you what is happening.  One thing that is a problem, however, is that your configuration script needs to come before the script that loads MathJax itself.  So you need to switch the order of the two scripts in your code example.  That might be the issue right there.  If your browser is using a cached version of tex-svg.js, then that will defined the MathJax variable before your next script runs, and then you redefine that in the second script, wiping out MathJax's code from the first script.
The URL used for your copy of MathJax seems to be coming from the Wordpress mathjax-latex plugin.  If you are using Wordpress and mathjax-latex, then you should not need to load MathJax yourself, as the plugin should be doing that already.  But you have not said anything about the environment you are using, or how you have set it up.  So it is hard to give you any advice.  For example, what version of MathJax have you installed?
The URL itself may actually be the problem.  As a reference from a web page, this URL would be relative to the root URL of the web server, not the root of your filing system.  It looks like the web server root is probably /opt/homebrew/www, so you would want the src attribute to src="/WordPress/wp-content/plugins/mathjax-latex/mathjax/es5/tex-svg.js".
Finally, "it do not work" is not a very precise description.  Does that mean that MathJax seems to be loading, but not processing the page?  Or does it mean that you are getting error message from MathJax?  Or is it something else?  For example, are there error messages in the browser console?  If the URL is incorrect, as I suspect it is, there would be a warning message in the browser console indicating that.


Adds swiftlint

@cb-gadagoju Can you please review this one? Its been open for a while now and it will be difficult to merge and update this PR everytime there is a change new change.


Custom UserFields

Is it possible to specify the fields of a User manually? Or is a user only allowed the fields that are defined in the interface?

Hi @yorickdevries, are you using TypeScript or JavaScript? I am working on updating this library and am considering rewriting everything using generics so users of this library can decide what fields the User should have.
Currently the MockStrategy type doesn't assume anything about the user. However some of the other helper functions exported by this library do assume certain fields (ex: id).

I am using Typescript and there indeed the fields id, name, emails, provider are expected. What I do now is:
const strategy = new MockStrategy({
  name: "mock",
  // eslint-disable-next-line @typescript-eslint/no-explicit-any
  user: user as any,
});
passport.use(strategy);

But if you could make an update using generics, that would certainly be a nice addition!


Dataaugmentation promble

hi,
I want to add dataaugmentation in datagenerator.py. According to your comments in def _parse_function_train(self, filename, label):
        """
    Dataaugmentation comes here.
    """

say I want to flip_up_and down and flip_left_right, in this way, and corp from 4 corner, one input image could have 6 output images.
so my question is: does the _parse_function_train() function still work for data.map(self._parse_function_train,....). if not, how I add my dataaugmentation in the code?
thanks!

My point is in _parse_function_train() function, one input image could have 6 output images. Is that ok?

I guess I don't understand your question very well. You can do what ever you want in the _parse_function_train, e.g. adding dataaugmentation, and the _parse_function_inference won't be affected by this. This is exactly the reason, why there are two different functions.

closed due to inactivity


One App-Wide Layout and Load Function

Describe the problem
I am trying to load data only once per application instance. Just before the app is initialized. Current infrastructure suggests that I put this logic in the load funciton in the main __layout.svelte. However, it's not ideal when I mix per-layout data and per-app data within one load function. Another issue occures when I am going back and forth beween some __layout and __layout.reset. Those per-app data get loaded again.
Another problem is when I want to keep some components even when I use layout.reset. Notifications component, for example, which stays mounted even when I reset the parent layout.
Describe the proposed solution
I suggest creating one more file [maybe] called __app.svelte which will follow the same logic as __layout.svelte but it will be available only once per app. Either src/app.svelte or src/routes/__app.svelte.
It will sit above all the layouts. Example:
<script context="module">
export async function load() {
  // load per-application data
}
</script>

<script>
import '../css/index.css' // import global css stylesheet
import { navigating } from '$app/stores' // create app-wide preloader
import Toaster from '$lib/Toaster.svelte' // app-wide toaster component
import Modal from '$lib/Modal.svelte' // modal component

function width() {
  return {
    duration: 400,
    css: (t) => {
      return `width: ${t * 100}%;`
    },
  }
}
</script>

{#if $navigating}
  <div class="n" in:width />
{/if}
<Toaster />
<slot />
<Modal />

<style>
.n {
  position: fixed;
  left: 0;
  top: 0;
  width: 100%;
  height: 2px;
  background-color: var(--blue);
}
</style>

Alternatives considered
Using root-level __layout, however breakes when some __layout.reset is accessed.
Importance
would make my life easier
Additional Information
No response

This seems like it's mostly a duplicate of #1165 and #2169, though one part of this request isn't a duplicate:

Another problem is when I want to keep some components even when I use layout.reset. Notifications component, for example, which stays mounted even when I reset the parent layout.

This part of the request is something I haven't seen in any other feature request, to the best of my knowledge.

This is now be possible with (rather advanced, don't freak out) usage of named layouts:
/src/routes/
  /__layout-app.svelte             # your app-wide layout, holds components and `load()`ed data
<EMAIL_ADDRESS>           # your default layout, goes inside app-wide layout `/__layout-app.svelte`
<EMAIL_ADDRESS>     # an empty <slot/> layout, goes inside app-wide layout `/__layout-app.svelte`
  /some/regular/page.svelte        # goes inside layout<EMAIL_ADDRESS><EMAIL_ADDRESS> # goes inside reset layout<EMAIL_ADDRESS>


Integration with Emarsys

I have a suggestion to consider integration with Emarsys - they are a great marketing automation engine for enterprise eCommerce companies. The integration could contain 1) e-mail 2) tracking on the web 3) recommendation engine.
If someone would be interested - I can arrange a demo account and configure the tool so we could have eCommerce extended with this robust eCommerce tool used only by enterprise companies.

@karolbzik do you have any progress here? I am interested in this integration too


Pid controls

I am working on doing swarm tasks with a group of 9 crazyflies. I am having trouble with the controls due to the added weight. I have added prop guards to all the crazy flies, and reflectors for motion tracking.
My issue is that the crazyflie does not generate enough thrust on takeoff for a good vertical lift. I adjsuted the stating thrust in the controller but would like input on the best way to correct this.
Another issue I am having is the PID controller. The crazyflie is struggling to correct itself in the z direction. I fixed this by increasing kp in the z direction to nearly double its original value. I am getting a large overshoot of my intended height before it slowly descends to the correct position.
When I have the crazyflies execute intricate movements they are stuggling to correct in time.

I recommend using the Crazyswarm instead, which has a much improved onboard-controller that can take the mass of the CF into account. Furthermore, it supports proper takeoff and landing trajectories and has much better support for multiple CFs (you could control 9 with just a single radio). You can find more information here: http://crazyswarm.readthedocs.io/en/latest/.
For the given controller, the mass in accounted for at take-off to initialize the z-integral part. You can try increase the integral bounds in case you run into out-of-bounds errors: https://github.com/whoenig/crazyflie_ros/blob/master/crazyflie_controller/config/crazyflie2.yaml#L24.


CloudFlare worker

We could have an contrib.cloudflare module/package exporting a function for easy AGP worker creation for cloudflare, eg:
from ariadne_graphql_proxy.contrib.cloudflare import create_cf_worker

worker = create_cf_worker(...)

Cloudflare workers don't properly support python, they require js/ts. The solution mentioned here compiles python to js, but it lacks most of the standard library and focuses on js libraries. So for now I'm closing this issue.

Yup. We should focus on alternatives that are Python-native, and only then move on to more complex alternatives like transpiling (which sound like something that has no right to work for project of our complexity).


Shader using source_color uses a more saturated color than the actual one chosen

Godot version
v4.0.beta1.official [20d667284]
System information
Arch Linux, Vulkan, Intel HD Graphics 4400
Issue description
The shader uses a more saturated version of the color you give it

The shader parameter for color is lighter, and yet shows up as a more saturated color on the preview and the object itself.
This is my first time making an issue on this GitHub, So I may have done something incorrectly, If I have please let me know!
Steps to reproduce
You can write a shader as simple as this:
shader_type canvas_item;

uniform vec4 color : source_color;

void fragment() {
    COLOR = color;
}

And use it on an object (I've only tested with a Sprite2D, i don't know if this happens on 3D objects)
Choose a lighter color for the color shader parameter and watch it be more saturated.
I have uploaded the ZIP file for a reproduction project. It includes an example scene with a sprite that has the shader using the code above.
Minimal reproduction project
Shader Issue.zip

I just figured out that this code:
shader_type canvas_item;
uniform vec4 color : source_color;

void fragment() {
	COLOR = vec4(color.r*2.0, color.g*2.0, color.b*2.0, color.a);
}

fixes the issue

I just figured out that this code:
shader_type canvas_item;
uniform vec4 color : source_color;

void fragment() {
	COLOR = vec4(color.r*2.0, color.g*2.0, color.b*2.0, color.a);
}

fixes the issue

Okay this mostly fixes the issue, it's more of a weird workaround

Okay this mostly fixes the issue, it's more of a weird workaround

I would have been very surprised if that actually fixed the issue.
I have a feeling this issue is a part of https://github.com/godotengine/godot/issues/61697, but we need to investigate a bit more to see if it actually is

It's a lack of srgb/linear conversion issue. The color needs to be converted to SRGB to display properly. Should be built in, but this will fix it:
shader_type canvas_item;

uniform vec4 color : source_color;

vec4 toSRGBSlow(vec4 col) {
    bvec4 cutoff = lessThan(col, vec4(0.0031308));
    vec4 higher = vec4(vec3(1.055)*pow(col.rgb, vec3(1.0/2.4)) - vec3(0.055), col.a);
    vec4 lower = vec4(col.rgb * vec3(12.92), col.a);
    return mix(higher, lower, cutoff);
}

void fragment() {
    COLOR = toSRGBSlow(color);
}

Alternative versions that are faster:
vec4 toSRGBFast(vec4 col) {
	return vec4(sqrt(col.rgb), col.a);
}
vec4 toSRGBMed(vec4 col) {
	return vec4(pow(col.rgb, vec3(.4545)), col.a);
}

The color looks fine on 3D shaders.

it should really convert to SRGB by default, but thanks for the workaround

source_color is formerly what was called hint_albedo. It should not be used in 2D, only in 3D.

what should I use for 2d instead then?
On Thu, Sep 29, 2022, 7:14 PM Hugo Locurcio @.***>
wrote:

source_color is formerly what was called hint_albedo. It should not be
used in 2D shaders – only in 3D.
—
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/66572#issuecomment-1262958430,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ALWVYOS3JCKJ3UODC4C6NOTWAYWIHANCNFSM6AAAAAAQYF7BTE
.
You are receiving this because you authored the thread.Message ID:
@.***>

what should I use for 2d instead then?

Nothing – remove the source_color hint entirely.

what should I use for 2d instead then?

Nothing – remove the source_color hint entirely.

Well i want to be able to choose a color with 2D without having to use this

Seconding @swordcube, I'm using hint_color for my 2D shaders to be able to pick colors in editor


no sizing information for the report server database itself

it mentions the version requirements but nothing about how important the database is, what it contains, how to size it, etc..

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

ID: 5f20394b-f5b1-2924-3670-932dba073875
Version Independent ID: 71ec4d31-53e6-16d4-c250-c38f1bba2ba6
Content: Hardware and software requirements for installing Power BI Report Server - Power BI
Content Source: powerbi-docs/report-server/system-requirements.md
Service: powerbi
Sub-service: powerbi-report-server
GitHub Login: @maggiesMSFT
Microsoft Alias: maggies

Thanks for your comment, @iturner1. This issue has been assigned to the doc author for review.

Any news?


Fetching crashpad fails when python2.7 is unavailable

Build fails if python2.7 is not available when fetching crashpad module.
Yet python2.7 is not installed by bootstrap-orbit.sh
________ running 'download_from_google_storage --no_resume --no_auth --bucket=chromium-clang-format --sha1_file buildtools/linux64/clang-format.sha1' in '/home/florent/.conan/data/crashpad/20200624/orbitdeps/stable/source'
Failed to fetch file gs://chromium-clang-format/942fc8b1789144b8071d3fc03ff0fcbe1cf81ac8 for buildtools/linux64/clang-format. [Err: [E2022-08-26T18:11:42.296567+02:00 31551 0 annotate.go:241] goroutine 1:
[E2022-08-26T18:11:42.296593+02:00 31551 0 annotate.go:241] #0 go.chromium.org/luci/vpython/python/find.go:93 - python.Find()
[E2022-08-26T18:11:42.296609+02:00 31551 0 annotate.go:241]   annotation #0:
[E2022-08-26T18:11:42.296614+02:00 31551 0 annotate.go:241]     reason: no Python found
[E2022-08-26T18:11:42.296619+02:00 31551 0 annotate.go:241]   annotation #1:
[E2022-08-26T18:11:42.296624+02:00 31551 0 annotate.go:241]     reason: could not find appropriate executable for: "python2.7"
[E2022-08-26T18:11:42.296629+02:00 31551 0 annotate.go:241]   annotation #2:
[E2022-08-26T18:11:42.296633+02:00 31551 0 annotate.go:241]     reason: could not find target in system
[E2022-08-26T18:11:42.296638+02:00 31551 0 annotate.go:241]     internal reason: target(python2.7)/dirs([/home/florent/.conan/data/depot_tools/20200407/_/_/package/cb054d0b3e1ca595dc66bc2339d40f1f8f04ab31/bin /home/florent/.conan/data/ninja/1.10.2/_/_/package/252f7e09f641bef29a75fc98d05ac217b842cde4/bin /home/florent/.conan/data/openssl/1.1.1k/_/_/package/f246571472552ef75bc9871dbfa2a3622e57b7f1/bin /home/florent/.local/bin /usr/local/cuda/bin /usr/local/sbin /usr/local/bin /usr/sbin /usr/bin /sbin /bin /usr/games /usr/local/games /snap/bin /home/florent/.conan/data/depot_tools/20200407/_/_/package/cb054d0b3e1ca595dc66bc2339d40f1f8f04ab31/bin])
[E2022-08-26T18:11:42.296647+02:00 31551 0 annotate.go:241]
[E2022-08-26T18:11:42.296652+02:00 31551 0 annotate.go:241] #1 go.chromium.org/luci/vpython/venv/config.go:271 - venv.(*Config).resolvePythonInterpreter()
[E2022-08-26T18:11:42.296658+02:00 31551 0 annotate.go:241]   reason: could not find Python for: 2.7.0
[E2022-08-26T18:11:42.296663+02:00 31551 0 annotate.go:241]
[E2022-08-26T18:11:42.296669+02:00 31551 0 annotate.go:241] #2 go.chromium.org/luci/vpython/venv/config.go:186 - venv.(*Config).makeEnv()
[E2022-08-26T18:11:42.296675+02:00 31551 0 annotate.go:241]   reason: failed to resolve system Python interpreter
[E2022-08-26T18:11:42.296683+02:00 31551 0 annotate.go:241]
[E2022-08-26T18:11:42.296688+02:00 31551 0 annotate.go:241] #3 go.chromium.org/luci/vpython/venv/venv.go:150 - venv.With()
[E2022-08-26T18:11:42.296694+02:00 31551 0 annotate.go:241]   reason: failed to initialize empty probe environment
[E2022-08-26T18:11:42.296699+02:00 31551 0 annotate.go:241]
[E2022-08-26T18:11:42.296704+02:00 31551 0 annotate.go:241] #4 go.chromium.org/luci/vpython/run.go:62 - vpython.Run()
[E2022-08-26T18:11:42.296709+02:00 31551 0 annotate.go:241] #5 go.chromium.org/luci/vpython/application/application.go:320 - application.(*application).mainImpl()
[E2022-08-26T18:11:42.296717+02:00 31551 0 annotate.go:241] #6 go.chromium.org/luci/vpython/application/application.go:406 - application.(*Config).Main.func1()
[E2022-08-26T18:11:42.296723+02:00 31551 0 annotate.go:241] #7 go.chromium.org/luci/vpython/application/support.go:46 - application.run()
[E2022-08-26T18:11:42.296728+02:00 31551 0 annotate.go:241] #8 go.chromium.org/luci/vpython/application/application.go:405 - application.(*Config).Main()
[E2022-08-26T18:11:42.296734+02:00 31551 0 annotate.go:241] #9 vpython/main.go:106 - main.mainImpl()
[E2022-08-26T18:11:42.296739+02:00 31551 0 annotate.go:241] #10 vpython/main.go:112 - main.main()
[E2022-08-26T18:11:42.296747+02:00 31551 0 annotate.go:241] #11 runtime/proc.go:203 - runtime.main()
[E2022-08-26T18:11:42.296752+02:00 31551 0 annotate.go:241] #12 runtime/asm_amd64.s:1357 - runtime.goexit()
]
0> Failed to fetch file gs://chromium-clang-format/942fc8b1789144b8071d3fc03ff0fcbe1cf81ac8 for buildtools/linux64/clang-format, skipping. [Err: [E2022-08-26T18:11:42.296567+02:00 31551 0 annotate.go:241] goroutine 1:
[E2022-08-26T18:11:42.296593+02:00 31551 0 annotate.go:241] #0 go.chromium.org/luci/vpython/python/find.go:93 - python.Find()
[E2022-08-26T18:11:42.296609+02:00 31551 0 annotate.go:241]   annotation #0:
[E2022-08-26T18:11:42.296614+02:00 31551 0 annotate.go:241]     reason: no Python found
[E2022-08-26T18:11:42.296619+02:00 31551 0 annotate.go:241]   annotation #1:
[E2022-08-26T18:11:42.296624+02:00 31551 0 annotate.go:241]     reason: could not find appropriate executable for: "python2.7"
[E2022-08-26T18:11:42.296629+02:00 31551 0 annotate.go:241]   annotation #2:
[E2022-08-26T18:11:42.296633+02:00 31551 0 annotate.go:241]     reason: could not find target in system
[E2022-08-26T18:11:42.296638+02:00 31551 0 annotate.go:241]     internal reason: target(python2.7)/dirs([/home/florent/.conan/data/depot_tools/20200407/_/_/package/cb054d0b3e1ca595dc66bc2339d40f1f8f04ab31/bin /home/florent/.conan/data/ninja/1.10.2/_/_/package/252f7e09f641bef29a75fc98d05ac217b842cde4/bin /home/florent/.conan/data/openssl/1.1.1k/_/_/package/f246571472552ef75bc9871dbfa2a3622e57b7f1/bin /home/florent/.local/bin /usr/local/cuda/bin /usr/local/sbin /usr/local/bin /usr/sbin /usr/bin /sbin /bin /usr/games /usr/local/games /snap/bin /home/florent/.conan/data/depot_tools/20200407/_/_/package/cb054d0b3e1ca595dc66bc2339d40f1f8f04ab31/bin])
[E2022-08-26T18:11:42.296647+02:00 31551 0 annotate.go:241]
[E2022-08-26T18:11:42.296652+02:00 31551 0 annotate.go:241] #1 go.chromium.org/luci/vpython/venv/config.go:271 - venv.(*Config).resolvePythonInterpreter()
[E2022-08-26T18:11:42.296658+02:00 31551 0 annotate.go:241]   reason: could not find Python for: 2.7.0
[E2022-08-26T18:11:42.296663+02:00 31551 0 annotate.go:241]
[E2022-08-26T18:11:42.296669+02:00 31551 0 annotate.go:241] #2 go.chromium.org/luci/vpython/venv/config.go:186 - venv.(*Config).makeEnv()
[E2022-08-26T18:11:42.296675+02:00 31551 0 annotate.go:241]   reason: failed to resolve system Python interpreter
[E2022-08-26T18:11:42.296683+02:00 31551 0 annotate.go:241]
[E2022-08-26T18:11:42.296688+02:00 31551 0 annotate.go:241] #3 go.chromium.org/luci/vpython/venv/venv.go:150 - venv.With()
[E2022-08-26T18:11:42.296694+02:00 31551 0 annotate.go:241]   reason: failed to initialize empty probe environment
[E2022-08-26T18:11:42.296699+02:00 31551 0 annotate.go:241]
[E2022-08-26T18:11:42.296704+02:00 31551 0 annotate.go:241] #4 go.chromium.org/luci/vpython/run.go:62 - vpython.Run()
[E2022-08-26T18:11:42.296709+02:00 31551 0 annotate.go:241] #5 go.chromium.org/luci/vpython/application/application.go:320 - application.(*application).mainImpl()
[E2022-08-26T18:11:42.296717+02:00 31551 0 annotate.go:241] #6 go.chromium.org/luci/vpython/application/application.go:406 - application.(*Config).Main.func1()
[E2022-08-26T18:11:42.296723+02:00 31551 0 annotate.go:241] #7 go.chromium.org/luci/vpython/application/support.go:46 - application.run()
[E2022-08-26T18:11:42.296728+02:00 31551 0 annotate.go:241] #8 go.chromium.org/luci/vpython/application/application.go:405 - application.(*Config).Main()
[E2022-08-26T18:11:42.296734+02:00 31551 0 annotate.go:241] #9 vpython/main.go:106 - main.mainImpl()
[E2022-08-26T18:11:42.296739+02:00 31551 0 annotate.go:241] #10 vpython/main.go:112 - main.main()
[E2022-08-26T18:11:42.296747+02:00 31551 0 annotate.go:241] #11 runtime/proc.go:203 - runtime.main()
[E2022-08-26T18:11:42.296752+02:00 31551 0 annotate.go:241] #12 runtime/asm_amd64.s:1357 - runtime.goexit()
]
Downloading 1 files took 0.323675 second(s)
Error: Command 'download_from_google_storage --no_resume --no_auth --bucket=chromium-clang-format --sha1_file buildtools/linux64/clang-format.sha1' returned non-zero exit status 1 in /home/florent/.conan/data/crashpad/20200624/orbitdeps/stable/source
ERROR: crashpad/20200624@orbitdeps/stable: Error in source() method, line 77
	self.run("gclient sync --no-history")
	ConanException: Error 2 while executing gclient sync --no-history

Note : when building v1.71

Hey,
You should probably be able to build by disabling crashpad, as described in https://github.com/google/orbit/issues/3232.


rippled: 1.6.0 -> 1.7.0

Motivation for this change
Updates rippled to 1.7.0
This does not include support for the recent postgres and cassandra archival settings.
Putting this up first as 1.6.0 no longer syncs with the network. I will make a separate PR for the export to postgres features in a few days.
Things done

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

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

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

@SuperSandro2000 submodules?

Putting this up first as 1.6.0 no longer syncs with the network.

@RaghavSood Then release branch should be updated as well.

I think NuDB may be hash mismatching on hydra now due to this PR. https://hydra.nixos.org/build/141546110


Error on getting Realtime Database reference in service

I am getting error:

06-24 10:41:36.497 17316-17316/com.example.waseem.geolocation:location_service E/AndroidRuntime: FATAL EXCEPTION: main
Process: com.example.waseem.geolocation:location_service, PID: 17316
java.lang.RuntimeException: Unable to instantiate service com.example.waseem.geolocation.LocationService: java.lang.IllegalStateException: FirebaseApp with name [DEFAULT] doesn't exist.
at android.app.ActivityThread.handleCreateService(ActivityThread.java:3085)
at android.app.ActivityThread.access$1900(ActivityThread.java:172)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1505)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:145)
at android.app.ActivityThread.main(ActivityThread.java:5832)
at java.lang.reflect.Method.invoke(Native Method)
at java.lang.reflect.Method.invoke(Method.java:372)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1399)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1194)
Caused by: java.lang.IllegalStateException: FirebaseApp with name [DEFAULT] doesn't exist.
at com.google.firebase.FirebaseApp.getInstance(Unknown Source)
at com.google.firebase.FirebaseApp.getInstance(Unknown Source)
at com.google.firebase.database.FirebaseDatabase.getInstance(Unknown Source)
at com.example.waseem.geolocation.LocationService.(LocationService.java:34)
at java.lang.reflect.Constructor.newInstance(Native Method)
at java.lang.Class.newInstance(Class.java:1650)
at android.app.ActivityThread.handleCreateService(ActivityThread.java:3082)
at android.app.ActivityThread.access$1900(ActivityThread.java:172)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1505)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:145)
at android.app.ActivityThread.main(ActivityThread.java:5832)
at java.lang.reflect.Method.invoke(Native Method)
at java.lang.reflect.Method.invoke(Method.java:372)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1399)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1194) `.

on
DatabaseReference mDatabase = FirebaseDatabase.getInstance().getReference();

statement in service but its works fine in activity.

@ch-muhammad-adil are you making any calls to the service in your Application's onCreate method?  FirebaseApp is automatically initialized by a ContentProvider but this does not happen until after the Application#onCreate method has been called.

no I am starting service from activity using this method startService(intent) and service is sticky

@ch-muhammad-adil is the service running in the same process as your Activity?  If it's not, you would have an android:process="..." entry in the AndroidManfiest.xml for the service.

how chould I make sure both run in same thread?

@ch-muhammad-adil glad this worked for you, thanks for following up.

good evening sir, I also experience this exception but in my case - I want my service(receiving child events) to run in separate process so that it still running whenever the main thread(App) is stopped or killed. how do I do this? hoping for your kind response. tnx :)

@pastillas could you post your question on StackOverflow and include some code to show your particular situation?  That would be a better place to address this.

http://stackoverflow.com/questions/39642304/unable-to-get-databasereference-and-firebaseauth-currentuser-on-a-remoteseparat is my question sir. tnx :)

http://stackoverflow.com/questions/39642304/unable-to-get-databasereference-and-firebaseauth-currentuser-on-a-remoteseparat here is link sir thanks :)


Set default terminal size to 80x25

It looks like otherwise the default is 0, which crashes some programs.
I would make it customizable, but I'm not sure how to make API for that.
Also see #10

thanks for the PR @tailhook and sorry that I didn't respond so far. I'm giving this project some love again, and would like to also look into this PR and maybe a way to customize the terminal size.
I'd like to play with it, what's your use case? or asked differently: what program crashes currently without the terminal size?

I'd like to play with it, what's your use case? or asked differently: what program crashes currently without the terminal size?

This is the crash: https://github.com/edgedb/edgedb-cli/runs/666845514?check_suite_focus=true
Note, the crash is actually in rustyline library. And that may involve some PR which isn't yet landed into a master.
Now as I'm thinking about it more, maybe it's better to fix rustyline to treat that as "infinite width". But being able to specify terminals size in rexpect makes sense anyway.

Also see this this thread on the similar issue: https://github.com/containers/libpod/issues/351

Hi! I am closing this PR now as it seems to be no longer relevant to you. Feel free to open a new one if you're still running into issues!


Dataset loading problem

Hello, first of all thank you for your hard work!
My question is: after downloading the MOSI data set, I encountered this problem during the loading of the data set:
Traceback (most recent call last):
File "F:/MLP/2023_Summer/Git/MMIM/src/main.py", line 57, in
solver.train_and_eval()
File "F:\MLP\2023_Summer\Git\MMIM\src\solver.py", line 281, in train_and_eval
train_loss = train(model, optimizer_main, criterion, 1)
File "F:\MLP\2023_Summer\Git\MMIM\src\solver.py", line 128, in train
for i_batch, batch_data in enumerate(self.train_loader):
File "F:\Anaconda\envs\self_mm\lib\site-packages\torch\utils\data\dataloader.py", line 435, in next
data = self._next_data()
File "F:\Anaconda\envs\self_mm\lib\site-packages\torch\utils\data\dataloader.py", line 475, in _next_data
data = self._dataset_fetcher.fetch(index) # may raise StopIteration
File "F:\Anaconda\envs\self_mm\lib\site-packages\torch\utils\data_utils\fetch.py", line 47, in fetch
return self.collate_fn(data)
File "F:\MLP\2023_Summer\Git\MMIM\src\data_loader.py", line 135, in collate_fn
bert_sentences = torch.LongTensor([sample["input_ids"] for sample in bert_details])
ValueError: expected sequence of length 50 at dim 1 (got 39)

can you remove
https://github.com/declare-lab/Multimodal-Infomax/blob/cd0774c5a712ca5f1a5497dbf27dde11cade7434/src/data_loader.py#L131
'truncation=True' and see how it works

Thank you for your reply. I have done what you said but the same problem still occurs.

I found the reason. The version of transformers is wrong and I need to use version 4.0.


Safari e Safari Mobile Http Referer in Header

Hi,
I've a problem about html2canvas with Safari & Safari Mobile.
My single page application is into an iframe: when I call html2canvas function with Safari (also Safari mobile) http request don't have referer in the header. All http request, for css and image elements, receive a 403 error. It's possible add for every request referer value? I thing that safari didn't implements this features.
Thanks
Specifications:

html2canvas version tested with: 0.4.1
Browser & version: Safari
Operating system: Mac Desktop & IOS

Hi,
is not possibile disable new iframe creation, and use a div?


Implement AbstractPlugin API

superseeds #5
This PR implements the LemminxPlugin based on the AbstractPlugin API.
The server.json is replaced by hardcoded URL and SHA256 checksum to reduce efforts to install the server binary.
All entry points to edit the LSP-lemminx.sublime-settings are removed as it intended to be a provider-only plugin.
It uses the new DottedDict settings structure.

Why do you think that it's not worth to make it easy for the user to edit (customize) settings. It seems like this server has some that user might want to change.

Is the plan to have a separate release for ST4? Otherwise it will break compatibility with ST3.


How to create correct amino-converter for Duration type

Hello,
I have a big problem with amino converter for Duration type.
Here is my proto definition of a message:
message MsgCreateVestingPool {
  string owner = 1;
  string name = 3;
  string amount = 4 [
    (gogoproto.customtype) = "github.com/cosmos/cosmos-sdk/types.Int",
    (gogoproto.nullable) = false
  ];
  google.protobuf.Duration duration = 5 [
    (gogoproto.nullable) = false,
    (gogoproto.stdduration) = true
  ];
  string vesting_type = 6;
}

Here is my typescript type for protobuf signing:
export interface MsgCreateVestingPool {
  owner: string;
  name: string;
  amount: string;
  duration: Duration | undefined;
  vestingType: string;
}

Duration is of this type:
export interface Duration {
  seconds: number;
  nanos: number;
}

And here is my AminoMsgCreateVestingPool
 export interface AminoMsgCreateVestingPool extends AminoMsg {
    readonly type: "cfevesting/CreateVestingPool";
    readonly value: {
        readonly amount: string,
        readonly duration: string,
        readonly name: string,
        readonly owner: string,
        readonly vesting_type: string,
    };
}

Here i have my amino converter:
 "/chain4energy.c4echain.cfevesting.MsgCreateVestingPool": {
      aminoType: "cfevesting/CreateVestingPool",
      toAmino: ({
                    amount,
                    duration,
                    vestingType,
                    name,
                    owner,
                }: MsgCreateVestingPool): AminoMsgCreateVestingPool["value"] => ({
          amount,
          duration: "100s",
          name: name,
          vesting_type: vestingType,
          owner,
      }),
      fromAmino: ({
                      amount,
                      duration,
                      name,
                      owner,
                      vesting_type,
                  }: AminoMsgCreateVestingPool["value"]): MsgCreateVestingPool => ({
          amount,
          duration: {seconds: 100, nanos: 0},
          name,
          owner,
          vestingType: vesting_type
      }),
  },

Here is error from the chain:
Error: Broadcasting transaction failed with code 4 (codespace: sdk). Log: signature verification failed; please verify account number (108756), sequence (16) and chain-id (veles-dev-test-1): unauthorized
    at SigningStargateClient.broadcastTx (@cosmjs_stargate.js?v=f839367f:40795:33)
    at async Proxy.createVestingPool (SplitVesting.vue:128:13)

I know that i'm hardcoding duration conversion for now but i don't know how to do it correctly. I was trying passing objects, numbers and other formats to AminoMsgCreateVestingPool type. I don't know what I can do more.
Thank's in advance!

@dawid-kruk Did you find a solution to this?

@ppoliani Yes I did :) Below is code example:
 export interface MsgExample {
  duration: Duration | undefined;
}

 export interface AminoMsgExample extends AminoMsg {
  readonly type: "correct/Type";
  readonly value: {
    readonly duration: string,
  };
}

 "/abcd.abcd.abcd.MsgExample": {
      aminoType: "correct/Type",
  toAmino: ({
             duration,
           }: MsgExample): AminoMsgExample["value"] => ({
        duration: duration?(duration.seconds *<PHONE_NUMBER> + duration.nanos).toString():"0",
      }),
      fromAmino: ({
                    duration,
                  }: AminoMsgExample["value"]): MsgExample => {
        const durationInNanoseconds = parseInt(duration, 10);
        const seconds = Math.floor(durationInNanoseconds / 1_000_000_000);
        const nanos = durationInNanoseconds % 1_000_000_000;
        return {
          duration: {
            seconds,
            nanos,
          },
        }
      },
      }

Thanks @dawid-kruk  I fell I'm having a similar issue https://github.com/cosmos/cosmjs/issues/1596 but can't get my head around it.


Just throws an error

When it tries to save it throws an error like noSuchFieldError in line 204 of serverAutoSave Class

Thanks for repeating! But I have not played mindustry for a long time, and this plugin is built for release build 126.2. So I don't konw if APIs were changed, and I think this maybe cause the error.


Added tests

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

1 of 1 (100.0%)  changed or added relevant line in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+8.8%) to 31.25%

Totals

Change from base Build<PHONE_NUMBER>:
8.8%

Covered Lines:
30

Relevant Lines:
96

💛  - Coveralls

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

6 of 8 (75.0%)  changed or added relevant lines in 3 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+22.6%) to 45.098%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/headers/StrictTransportSecurity.ts
3
5
60.0%

Totals

Change from base Build<PHONE_NUMBER>:
22.6%

Covered Lines:
46

Relevant Lines:
102

💛  - Coveralls

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

6 of 8 (75.0%)  changed or added relevant lines in 3 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+35.4%) to 57.843%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/headers/StrictTransportSecurity.ts
3
5
60.0%

Totals

Change from base Build<PHONE_NUMBER>:
35.4%

Covered Lines:
59

Relevant Lines:
102

💛  - Coveralls

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

9 of 11 (81.82%)  changed or added relevant lines in 4 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+74.6%) to 97.059%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/headers/StrictTransportSecurity.ts
3
5
60.0%

Totals

Change from base Build<PHONE_NUMBER>:
74.6%

Covered Lines:
99

Relevant Lines:
102

💛  - Coveralls

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

9 of 11 (81.82%)  changed or added relevant lines in 4 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+74.6%) to 97.059%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/headers/StrictTransportSecurity.ts
3
5
60.0%

Totals

Change from base Build<PHONE_NUMBER>:
74.6%

Covered Lines:
99

Relevant Lines:
102

💛  - Coveralls

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

9 of 11 (81.82%)  changed or added relevant lines in 4 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+74.6%) to 97.059%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/headers/StrictTransportSecurity.ts
3
5
60.0%

Totals

Change from base Build<PHONE_NUMBER>:
74.6%

Covered Lines:
99

Relevant Lines:
102

💛  - Coveralls


Remaining Flaky Tests

We are ignoring failures with these tests currently. This needs to be addressed ASAP

[x]     long::targeted::tests::test_calculate_targeted_long_with_budget
[x]     short::max::tests::fuzz_calculate_absolute_max_short_execute
[x]     short::max::tests::fuzz_calculate_max_short_no_budget

https://github.com/delvtech/hyperdrive-rs/pull/95 resolves the remaining flaky tests, but unfortunately introduces a new one:

[ ] long::max::fuzz_calculate_max_long

I'm investigating that now

another one:
failures:

---- short::max::tests::fuzz_calculate_max_short stdout ----
thread 'short::max::tests::fuzz_calculate_max_short' panicked at crates/hyperdrive-math/src/short/max.rs:723:17:
expected (base=34326359.285477447501009068) < (budget=35401424.462665845134388594) * 0.001000000000000000 = 35401.424462665845134388

failures:
    short::max::tests::fuzz_calculate_max_short

#95 resolves the remaining OP flaky tests, but unfortunately introduces a new one:

[x]  long::max::fuzz_calculate_max_long

I'm investigating that now

resolved by https://github.com/delvtech/hyperdrive-rs/pull/101

another one:
failures:

---- short::max::tests::fuzz_calculate_max_short stdout ----
thread 'short::max::tests::fuzz_calculate_max_short' panicked at crates/hyperdrive-math/src/short/max.rs:723:17:
expected (base=34326359.285477447501009068) < (budget=35401424.462665845134388594) * 0.001000000000000000 = 35401.424462665845134388

failures:
    short::max::tests::fuzz_calculate_max_short

I ran the fuzz test 4 * 1000 times without failure against the branch for this PR https://github.com/delvtech/hyperdrive/pull/1028
I'm going to close the issue; we can re-open one later if we find new flaky tests after v1.0.7 hits with #1028 merged


http/rpc provider middleware

Introduces a Chained middleware to allow for possible multiple providers for request

Also you should integrate the middleware into the http provider


Fix flaky e2e test TestL7NetworkPolicy/TLS

Fix #5296

Can we describe what was the problem and why switching to github.com could fix it?

Can we describe what was the problem and why switching to github.com could fix it?

I found that apis.google.com is redirected to developers.google.com. I'll find the further reason.

The issue should be caused by the short timeout of wget since 1 second should not enough to download a https web like apis.google.com. I have tried to set the timeout to 5 second and it works every time.

/skip-all as only specific builds that have enabled L7NetworkPolicy feature gate run it.


Successfully deployed account to devnet but transaction failed because address not deployed

Describe the bug (observed vs expected behavior)
I create and deployed a new account on devnet, but failed to send transaction because StarknetErrorCode.UNINITIALIZED_CONTRACT.
Not reproducible on alpha-goerli

[ ] This issue is only present on Devnet and cannot be reproduced on alpha-goerli (check the box if true).

To Reproduce
Steps to reproduce the behavior:

starknet new_account --gateway_url=http://<IP_ADDRESS>:5050 --account=dev
starknet deploy_account --gateway_url=http://<IP_ADDRESS>:5050 --account=dev
starknet declare --contract path_to_compiled_contract.json --gateway_url=http://<IP_ADDRESS>:5050 --account=dev
...

Devnet version
alpha-goerli

I am using Devnet version:
[ ] This happens with a dockerized Devnet (check the box if true).
This does not appear on the following Devnet version:

System specifications

OS: MacOS 13.1
CPU:
Memory: 16G
Python version: 3.9

Can you please provide your Devnet version and your starknet CLI version? You can obtain them with:
$ starknet-devnet --version
$ starknet --version

Can you please provide your Devnet version and your Starknet CLI version? You can obtain them with:
$ starknet-devnet --version
$ starknet --version

starknet-devnet: 0.4.6
starknet: 0.10.3

My guess is that account deployment failed because the account address needs to be funded beforehand. I.e. after creating the account with starknet new_account, you get the address where it will be deployed with starknet deploy_account. Before actually running starknet deploy_account you need to give some token to that address, which you can achieve on Devnet by relying on minting: https://shard-labs.github.io/starknet-devnet/docs/guide/mint-token

Another thing, when you send a transaction, it is useful to check its status with
$ starknet get_transaction --hash <TX_HASH>

You could do this on the account deployment tx.

Thanks for the reply!
I ran the above command after running
starknet new_account --gateway_url http://<IP_ADDRESS>:5050 --account=dev4
starknet deploy_account --gateway_url http://<IP_ADDRESS>:5050 --account=dev4

and got
{
    "status": "NOT_RECEIVED"
}

Is there anything wrong with my usage of the new_account and deploy_account command on devnet?

If you're getting NOT_RECEIVED then probably one of the following happened:

You restarted Devnet
You provided the wrong tx hash (be sure it's the hash printed as the transaction hash after running starknet deploy_account)

Starknet CLI thinks your deploy_account transaction was successful, that's why it thinks the account is already deployed (it's actually not). You can avoid getting the Account ... already deployed error by passing a force flag:
$ starknet deploy_account --force ...

That worked for account deployment, thanks! But still failing on contract declaration 🤣

starknet get_transaction --feeder_gateway_url http://<IP_ADDRESS>:5050 --hash 0x46b52c7e43230c0571b228356b78e378c9715953b838712f058c8179f80648
{
    "block_hash": "0x2e7000b7ef3ef5816212c550aa1a59fc2826fd0bc3fd621e02ff2bee4d94c04",
    "block_number": 5,
    "status": "ACCEPTED_ON_L2",
    "transaction": {
        "class_hash": "0x6f500f527355dfdb8093c7fe46e6f73c96a867392b49fa4157a757538928539",
        "constructor_calldata": [
            "0x7d34e699d0edc327c8ad30227c9ee7576d743d315c38590dc51090261210f19"
        ],
        "contract_address": "0x31757f498b24925814d1d0978f4141624ab830d017d3eb1167b9b94efd04d3b",
        "contract_address_salt": "0x2cb122984ae481d343d3c9519636b4d8cf394707dc38c135ab077e2a5a16ce2",
        "max_fee": "0x37c429987bffa",
        "nonce": "0x0",
        "signature": [
            "0x790d7436364d3922cb2b498078e7363305df4bc29771de0788ea6c12a6d2e7d",
            "0x7db325f6130e321621a36a23d3882e98d91eb61a8ebd00314bae6454f2fbb14"
        ],
        "transaction_hash": "0x46b52c7e43230c0571b228356b78e378c9715953b838712f058c8179f80648",
        "type": "DEPLOY_ACCOUNT",
        "version": "0x1"
    },
    "transaction_index": 0
}

starknet declare --contract compiled_contract.json --gateway_url http://<IP_ADDRESS>:5050 --account dev4
Got BadRequest while trying to access https://alpha4.starknet.io/feeder_gateway/simulate_transaction?blockNumber=pending. Status code: 500; text: {"code": "StarknetErrorCode.UNINITIALIZED_CONTRACT", "message": "Requested contract address 0x31757f498b24925814d1d0978f4141624ab830d017d3eb1167b9b94efd04d3b is not deployed."}.
Traceback (most recent call last):
  File "/Users/ccsoloist/multichain/Starknet/multichain-contracts/env/lib/python3.9/site-packages/services/external_api/client.py", line 117, in _send_request
    raise BadRequest(status_code=response.status, text=text)
services.external_api.client.BadRequest: HTTP error ocurred. Status: 500. Text: {"code": "StarknetErrorCode.UNINITIALIZED_CONTRACT", "message": "Requested contract address 0x31757f498b24925814d1d0978f4141624ab830d017d3eb1167b9b94efd04d3b is not deployed."}
Error: BadRequest: HTTP error ocurred. Status: 500. Text: {"code": "StarknetErrorCode.UNINITIALIZED_CONTRACT", "message": "Requested contract address 0x31757f498b24925814d1d0978f4141624ab830d017d3eb1167b9b94efd04d3b is not deployed."}

Ah it worked by replacing gateway_url with feeder_gateway_url

If you look at the error message, it says it failed while trying to access https://alpha4.starknet.io/feeder_gateway/simulate_transaction.
This happens if you don't specify a --max_fee. Starknet CLI attempts to estimate the max_fee by simulating the transaction. But this is done using the feeder_gateway and the default is probably alpha-goerli where your contract hasn't been deployed. So you should do one of the following:

Provide BOTH --feeder_gateway_url and --gateway_url (they can have the same URL)
Specify your own max_fee (something big)

If you look at the error message, it says it failed while trying to access https://alpha4.starknet.io/feeder_gateway/simulate_transaction.
This happens if you don't specify a --max_fee. Starknet CLI attempts to estimate the max_fee by simulating the transaction. But this is done using the feeder_gateway and the default is probably alpha-goerli where your contract hasn't been deployed. So you should do one of the following:

Provide BOTH --feeder_gateway_url and --gateway_url (they can have the same URL)
Specify your own max_fee (something big)

Thanks! That finally makes sense.
Appreciate your help! 👍


Proposed fix for #40

This PR edits thread_safe_queue to have more functionality and serve as a priority queue for the threads.
At the end of each thread execution, the threads bump themselves up to the top of the priority list for work assignment.

I have addressed the issues found by the workflows, and added a new unit test that I confirmed (on my machine) fails on master but passes on this branch.

Thank you for this! Once I have some time i can look into this more thoroughly and run it on my machine. I don't see any issues with merging it once I've don't that. Thanks again!

Overall this looks really good. It seems that this has a significant performance impact on the thread pool as well but I'm skeptical on the numbers I'm seeing. Here are the new benchmark results with MSVC

relative
ms/op
op/s
err%
total
matrix multiplication 8x8

100.0%
73.49
13.61
0.8%
18.22
dp::thread_pool - std::function

105.5%
69.62
14.36
0.3%
16.94
dp::thread_pool - std::move_only_function

98.0%
74.99
13.34
1.1%
18.22
dp::thread_pool - fu2::unique_function

39.7%
185.12
5.40
0.4%
44.72
BS::thread_pool

50.7%
144.83
6.90
0.7%
34.89
task_thread_pool

40.2%
182.84
5.47
0.5%
44.23
riften::Thiefpool

relative
ms/op
op/s
err%
total
matrix multiplication 64x64

100.0%
58.25
17.17
4.4%
14.69
dp::thread_pool - std::function

108.8%
53.55
18.68
0.7%
13.01
dp::thread_pool - std::move_only_function

101.3%
57.53
17.38
0.9%
13.94
dp::thread_pool - fu2::unique_function

40.3%
144.52
6.92
0.3%
34.92
BS::thread_pool

45.2%
128.80
7.76
0.2%
31.15
task_thread_pool

42.4%
137.50
7.27
0.3%
33.40
riften::Thiefpool

relative
ms/op
op/s
err%
total
matrix multiplication 256x256

100.0%
47.36
21.11
2.6%
11.54
dp::thread_pool - std::function

106.5%
44.49
22.48
0.2%
10.74
dp::thread_pool - std::move_only_function

100.1%
47.31
21.14
0.2%
11.46
dp::thread_pool - fu2::unique_function

47.0%
100.80
9.92
0.3%
24.42
BS::thread_pool

51.1%
92.77
10.78
0.4%
22.41
task_thread_pool

46.3%
102.20
9.78
0.7%
24.99
riften::Thiefpool

relative
ms/op
op/s
err%
total
matrix multiplication 512x512

100.0%
38.02
26.30
0.3%
9.20
dp::thread_pool - std::function

134.7%
28.23
35.42
2.3%
6.85
dp::thread_pool - std::move_only_function

97.3%
39.08
25.59
0.6%
9.50
dp::thread_pool - fu2::unique_function

49.5%
76.79
13.02
0.2%
18.57
BS::thread_pool

53.1%
71.65
13.96
0.2%
17.35
task_thread_pool

48.6%
78.29
12.77
0.4%
18.91
riften::Thiefpool

relative
ms/op
op/s
err%
total
matrix multiplication 1024x1024

100.0%
42.87
23.33
1.9%
10.32
dp::thread_pool - std::function

99.9%
42.91
23.31
2.2%
10.30
dp::thread_pool - std::move_only_function

101.9%
42.08
23.76
1.4%
10.21
dp::thread_pool - fu2::unique_function

73.0%
58.70
17.03
0.6%
14.22
BS::thread_pool

77.5%
55.32
18.08
0.7%
13.45
task_thread_pool

99.5%
43.08
23.21
2.2%
10.47
riften::Thiefpool

@jtd-formlabs Do you have any input or insights on what could be causing this large of a performance uplift? Previous benchmarks showed my library edging out some other popular libraries but now it blows them out of the water. I'm not mad at that, but I'm wondering if there is something I'm missing here...

This is really interesting! I'll run your benchmarks on my Ubuntu system to get some additional metrics as well.
One theory is that this new scheduling system is relying on the work stealing process much less, as it will always defer to a thread that is ready for work first so there is less delay.
It may be worth adding some code to before and after this PR to see how many workloads are stolen during the benchmarks.

Yes I agree with your comments. This should result in the threads always having work to do in general and having to steal less (if at all).
I'm curious to see the numbers on Ubuntu as well as I haven't tried running benchmarks there yet.

So I ran two benchmarks, one with pyperf system and one without:
WITH:

| relative |               ms/op |                op/s |    err% |     total | matrix multiplication 8x8
|---------:|--------------------:|--------------------:|--------:|----------:|:--------------------------
|   100.0% |              182.55 |                5.48 |    0.4% |     32.67 | `dp::thread_pool - std::function`
|    99.0% |              184.43 |                5.42 |    0.3% |     33.04 | `dp::thread_pool - std::move_only_function`
|    98.9% |              184.60 |                5.42 |    0.5% |     33.13 | `dp::thread_pool - fu2::unique_function`
|    74.9% |              243.85 |                4.10 |    0.3% |     44.00 | `BS::thread_pool`
|    56.0% |              326.01 |                3.07 |    0.5% |     58.38 | `task_thread_pool`
|   132.7% |              137.60 |                7.27 |    1.6% |     25.69 | `riften::Thiefpool`

| relative |               ms/op |                op/s |    err% |     total | matrix multiplication 64x64
|---------:|--------------------:|--------------------:|--------:|----------:|:----------------------------
|   100.0% |              159.72 |                6.26 |    0.6% |     28.60 | `dp::thread_pool - std::function`
|    96.7% |              165.12 |                6.06 |    0.3% |     29.62 | `dp::thread_pool - std::move_only_function`
|   100.5% |              158.87 |                6.29 |    0.4% |     28.42 | `dp::thread_pool - fu2::unique_function`
|    82.0% |              194.82 |                5.13 |    0.4% |     35.09 | `BS::thread_pool`
|    63.3% |              252.48 |                3.96 |    0.4% |     45.24 | `task_thread_pool`
|   105.8% |              150.96 |                6.62 |    4.1% |     27.27 | `riften::Thiefpool`

| relative |               ms/op |                op/s |    err% |     total | matrix multiplication 256x256
|---------:|--------------------:|--------------------:|--------:|----------:|:------------------------------
|   100.0% |              118.77 |                8.42 |    0.2% |     21.26 | `dp::thread_pool - std::function`
|    92.9% |              127.82 |                7.82 |    0.7% |     22.89 | `dp::thread_pool - std::move_only_function`
|    99.0% |              119.94 |                8.34 |    0.7% |     21.49 | `dp::thread_pool - fu2::unique_function`
|    81.2% |              146.29 |                6.84 |    1.0% |     26.19 | `BS::thread_pool`
|    66.0% |              180.02 |                5.55 |    0.1% |     32.26 | `task_thread_pool`
|    88.6% |              134.01 |                7.46 |    1.5% |     24.10 | `riften::Thiefpool`

| relative |               ms/op |                op/s |    err% |     total | matrix multiplication 512x512
|---------:|--------------------:|--------------------:|--------:|----------:|:------------------------------
|   100.0% |               99.88 |               10.01 |    1.3% |     17.86 | `dp::thread_pool - std::function`
|    99.9% |              100.00 |               10.00 |    0.3% |     17.93 | `dp::thread_pool - std::move_only_function`
|   101.0% |               98.93 |               10.11 |    0.3% |     17.75 | `dp::thread_pool - fu2::unique_function`
|    85.7% |              116.59 |                8.58 |    0.7% |     20.96 | `BS::thread_pool`
|    76.1% |              131.28 |                7.62 |    0.8% |     23.60 | `task_thread_pool`
|   100.0% |               99.90 |               10.01 |    4.1% |     18.02 | `riften::Thiefpool`

| relative |               ms/op |                op/s |    err% |     total | matrix multiplication 1024x1024
|---------:|--------------------:|--------------------:|--------:|----------:|:--------------------------------
|   100.0% |               78.76 |               12.70 |    1.5% |     14.20 | `dp::thread_pool - std::function`
|    95.5% |               82.48 |               12.12 |    1.0% |     14.78 | `dp::thread_pool - std::move_only_function`
|   100.1% |               78.70 |               12.71 |    1.1% |     14.08 | `dp::thread_pool - fu2::unique_function`
|    78.6% |              100.23 |                9.98 |    1.3% |     18.05 | `BS::thread_pool`
|    77.3% |              101.88 |                9.82 |    0.5% |     18.29 | `task_thread_pool`
|    88.8% |               88.66 |               11.28 |    3.3% |     15.83 | `riften::Thiefpool`

WITHOUT:
Warning, results might be unstable:
* CPU frequency scaling enabled: CPU 0 between 400.0 and 4,700.0 MHz
* CPU governor is 'powersave' but should be 'performance'
* Turbo is enabled, CPU frequency will fluctuate

Recommendations
* Use 'pyperf system tune' before benchmarking. See https://github.com/psf/pyperf

| relative |               ms/op |                op/s |    err% |     total | matrix multiplication 8x8
|---------:|--------------------:|--------------------:|--------:|----------:|:--------------------------
|   100.0% |              114.40 |                8.74 |    2.0% |     20.56 | `dp::thread_pool - std::function`
|    92.6% |              123.52 |                8.10 |    0.5% |     22.06 | `dp::thread_pool - std::move_only_function`
|    92.7% |              123.39 |                8.10 |    0.7% |     22.20 | `dp::thread_pool - fu2::unique_function`
|    70.6% |              162.04 |                6.17 |    0.3% |     28.88 | `BS::thread_pool`
|    53.2% |              214.96 |                4.65 |    0.6% |     38.59 | `task_thread_pool`
|   114.4% |              100.03 |               10.00 |    0.3% |     18.20 | `riften::Thiefpool`

| relative |               ms/op |                op/s |    err% |     total | matrix multiplication 64x64
|---------:|--------------------:|--------------------:|--------:|----------:|:----------------------------
|   100.0% |              114.62 |                8.72 |    1.0% |     20.52 | `dp::thread_pool - std::function`
|   104.1% |              110.14 |                9.08 |    0.8% |     19.79 | `dp::thread_pool - std::move_only_function`
|   106.4% |              107.77 |                9.28 |    1.0% |     19.31 | `dp::thread_pool - fu2::unique_function`
|    86.4% |              132.71 |                7.54 |    1.5% |     23.65 | `BS::thread_pool`
|    68.8% |              166.60 |                6.00 |    0.7% |     29.88 | `task_thread_pool`
|   112.9% |              101.49 |                9.85 |    1.6% |     18.09 | `riften::Thiefpool`

| relative |               ms/op |                op/s |    err% |     total | matrix multiplication 256x256
|---------:|--------------------:|--------------------:|--------:|----------:|:------------------------------
|   100.0% |               82.04 |               12.19 |    0.6% |     14.73 | `dp::thread_pool - std::function`
|    97.6% |               84.06 |               11.90 |    0.6% |     14.99 | `dp::thread_pool - std::move_only_function`
|   101.0% |               81.26 |               12.31 |    2.1% |     14.56 | `dp::thread_pool - fu2::unique_function`
|    81.7% |              100.41 |                9.96 |    0.6% |     17.96 | `BS::thread_pool`
|    68.2% |              120.34 |                8.31 |    0.4% |     21.49 | `task_thread_pool`
|    86.0% |               95.37 |               10.49 |    1.3% |     17.16 | `riften::Thiefpool`

| relative |               ms/op |                op/s |    err% |     total | matrix multiplication 512x512
|---------:|--------------------:|--------------------:|--------:|----------:|:------------------------------
|   100.0% |               68.46 |               14.61 |    0.6% |     12.26 | `dp::thread_pool - std::function`
|   100.9% |               67.83 |               14.74 |    1.0% |     12.21 | `dp::thread_pool - std::move_only_function`
|   100.1% |               68.37 |               14.63 |    0.3% |     12.26 | `dp::thread_pool - fu2::unique_function`
|    84.3% |               81.25 |               12.31 |    0.7% |     14.59 | `BS::thread_pool`
|    72.1% |               94.99 |               10.53 |    0.6% |     17.00 | `task_thread_pool`
|    92.2% |               74.27 |               13.46 |    1.6% |     13.36 | `riften::Thiefpool`

| relative |               ms/op |                op/s |    err% |     total | matrix multiplication 1024x1024
|---------:|--------------------:|--------------------:|--------:|----------:|:--------------------------------
|   100.0% |               59.33 |               16.86 |    0.6% |     10.66 | `dp::thread_pool - std::function`
|    95.8% |               61.94 |               16.14 |    1.1% |     11.14 | `dp::thread_pool - std::move_only_function`
|    97.9% |               60.61 |               16.50 |    1.0% |     10.82 | `dp::thread_pool - fu2::unique_function`
|    81.9% |               72.44 |               13.80 |    1.0% |     13.04 | `BS::thread_pool`
|    71.4% |               83.11 |               12.03 |    3.3% |     15.51 | `task_thread_pool`
|    92.2% |               64.37 |               15.54 |    1.0% |     11.47 | `riften::Thiefpool`

This was on a laptop running Ubuntu 20.04 with the power cable plugged in. 20 core system with 32 gb of ram on an Intel processor.

I also needed a new include to compile with gcc 12, so I pushed that change. Both benchmarks were run compiling in release mode.

Hmm, very interesting results. I think your results are much more reasonable. I thought running benchmarks on windows might be a problem since there is no equivalent to pyperf system on windows that I know of, but I didn't think it would make such a difference. Unfortunately, pyperf system also doesn't work on WSL 2 either so I'm not sure what else I can do.
Regardless, I like the direction of this PR and will merge, but I will be hesitant to publish any new benchmark numbers until I can get more stable results.

Seems totally reasonable! thank you for taking the time to look this over and merge it!


Documentation of what parameter options are

Hi!
A bit of a generic question.
I am trying to, given a 2D phantom of materials of my own, simulate a flat pannel standard CT scanner, I guess with all "turned on".
However I am finding a bit hard time understanding what parameters mean in general. e.g.
protocol.spectrumUnit_mm = 0;               # Is the spectrum file in units of photons/sec/mm^2/<current>?
What does this mean? is 0=photons, 1=sec etc? what is <current>? current, as in electrical current?
or
scanner.detectorCallback = "Detector_ThirdgenCurved" # name of function that defines the detector shape and model
What are other options?
On top of that, partially due to #27 I have not been able to run any full demo to try to inspect values of functions etc and learn a bit more about it.
Where do you suggest I start looking at this?
I'd be happy to help adding more demos/docs/code, if that helps.

protocol.spectrumUnit_mm = 0;               # Is the spectrum file in units of photons/sec/mm^2/<current>? protocol.spectrumUnit_mA = 1;               # Is the spectrum file in units of photons/sec/<area>/mA?
These two options are mutual exclusive - you can only have one unit for spectrum, and the unit is specified by the one with 1.
current means tube current.
Regarding detector, currently we only support curved detector.
For the issue related to #27 a workaround is to simply copy the reconstruction directory into (xcist **installation** directory)/catsim/pyfiles.

Thanks for the explanation. But in general, is there any further docs anywhere for this?
Is there any intention of supporting flat-panel detectors? If not, would it be possible for me to ask if you could point out which files are the relevant ones that define this geometry (I assume just the DD ray tracer) so I can try to make the changes? Supporting flat panel detectors is a "small" change in the ray-tracing code, right? or is there something else I am missing?

cfg.scanner.detectorCallback, currently Detector_ThirdgenCurved.py, defines the detector geometry.
It's piece-wised geometry, made of many small flat detectors (modules).
If there's only one module, i.e., at its line 21, if nMod is one, then it's a big flat detector.

Yes, the geometry is that the center ray of each module is perpendicular to the module.
ct.scanner.detectorColCount should be the number of columns of the detector, and yes, set ct.scanner.detectorColCount=cfg.scanner.detectorColsPerMod.

Thanks. I still have some questions about how to run some of the things, I'll ask them here if that's ok:
I want the projection data (sinograms), not the recon from the simulations. When I run the demos, I can get tif files of the recon, but the other output files (.scan, .offset etc)  are a bit opaque on what they do and what they are. Is any of these the projection data? how can I get that?

sinograms are files ending with .prep, and you can read them using
xcist.rawread('xxx.prep', [views, rows, cols], 'float')


Considerations for an RV32EG

The RV32/64G extensions define a standard baseline, that being RV32I or RV64I plus MAFD, Zicsr, and Zifencei.
Would it make sense to add an RV32EG replacing FD with Zfinx when drafted?
I'm particularly considering FPGA implementations, from small (2,000LE) to larger (80,000LE) FPGAs, both for embedded microcontrollers and more general-purpose RISC-V Soft CPUs.  I selected the above extensions because:

Modern FPGAs provide hardware multipliers, so the M extension has a small footprint
Single-hart implementations can implement atomic instructions by decoding to equivalent non-atomic instructions (I think?)
Zfinx will (assumedly) avoid a bunch of floating point instructions and registers, saving a great deal of space while still providing floating-point operations

I imagine these will provide a significantly-smaller implementation for FPGA by eliminating F and D instructions in favor of Zfinx; while for ASIC, the RV32E implementation saves a ton of space, and Zfinx extension provides valuable floating-point without adding a heavy register file.  It remains to be seen if the Zfinx instruction implementation will be substantially more space-efficient than F.
I imagine Linux and Minix could be induced to run on these with minimal effort.
One consideration:  if using Zfinx, then the code is not compatible with RV32G; whereas RV32E-MAFD-Zicrs-Zifencei would run on RV32G.  Should future revisions of RV32G specify Zfinx?  Will Zfinx provide some performance advantages?  (For that matter, the concept of Zfinx—reusing the integer registers as floating-point registers—seems to reduce the instruction count and processor complexity in general.  I might have preferred it to FD, had Zfinx and Zdinx been drafted before RV32/64G; but what do I know anyway?)

To avoid confusion, we should avoid reusing the G moniker.  In the long run, ISA names are going to get long.  Perhaps compressing IMAFD into G was a false economy to begin with.
RV32EMAFCZfinx is probably going to be a popular design point.  Adding D implies adding the concept of values spanning two x-registers--not inherently problematic, but certainly a new thing to deal with.
I'm a little surprised this is coming up in the context of a soft core.  The main cost of I vs. E, or not-Zfinx vs. Zfinx, is regfile capacity, which should not command a premium cost in FPGAs.  If you're building deeply threaded cores, I can understand the desire to reduce regfile capacity, though.

There is no toolchain support yet for rv32ef or rv32efd.  There is also a problem that the current rv32e abi can't support rv32efd correctly because d requires 64-bit alignment and the rv32e abi requires 32-bit stack alignment.  This is one of the reasons why the toolchain support hasn't been implemented yet.  To fix this, we need a new rv32e abi.  There are plans for a new embedded abi that would fix the problem, but those plans have been stalled for about 2 years now and not clear when the work will continue.
There is also no toolchain support for Xfinx yet.  This also requires ABI changes, but I think they are simpler than the new embedded abi.  There was some discussion about defining a Zfinx ABI recently, so this may happen before the new embedded abi.  But this doesn't solve the alignment issue for doubles, so there may still be a problem, depending on whether there is still a load double instruction and whether it still requires 64-bit alignment.
if your timelines are short, you might want to pick an architecture combination that already has toolchain support.  if you timelines are long, there is a chance the toolchain support might be written before you need it.

To avoid confusion, we should avoid reusing the G moniker.

Fair enough.  I guess the embedded implementation isn't a common-target thing anyway.  My thinking was mostly to supply the same facilities, although Zfinx isn't in IG and so RV32EG as described wouldn't run on RV32IG (which might not be useful anyway).

RV32EMAFCZfinx is probably going to be a popular design point.
I'm a little surprised this is coming up in the context of a soft core. The main cost of I vs. E, or not-Zfinx vs. Zfinx, is regfile capacity, which should not command a premium cost in FPGAs. If you're building deeply threaded cores, I can understand the desire to reduce regfile capacity, though.

I'm thinking in terms of both soft and hard cores, although floating-point is huge—a small RV32I costs 700 LUTs on a Xilinx FPGA, while I've seen low-area single-precision floating-point multiply-and-accumulate boast such small areas as 250-275 4-input LUTs.  The floating-point logic would be
larger than the CPU itself.  To be fair, they implemented an adder and a multiplier; and the multiplier they used (Nikhilam) may or may not be the most efficient (I've seen a Paravartya 8-bit integer divider in 72 LUTs and it was twice as fast as a 200-LUT Nikhilam divider and had half the delay—and apparently 80% of the delay of a typical reference divider).
RV32EMAZfinx might be sensible if float is needed in ASIC because it cuts back on all that register space, which you're going to need if you implement floating-point operations.  Not sure F would be interesting in that context, nor C (ROM space is cheaper than ASIC space, right?). Integer multipliers and dividers are cheap.
Anyway all this was probably pointless.

Thinking back, this discussion was probably ill-considered and can be closed.


Updated IconButton.iconSize to get value from theme

IconButton couldn't use Icon.size from IconThemeData.size. Changed IconButton.iconSize to be nullable so that when null, Icon.size will take the value from IconThemeData.size and when non-null, will precede theme value.

Before
After

fixes #77801
Pre-launch Checklist

[x] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[x] I read the Tree Hygiene wiki page, which explains my responsibilities.
[x] I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
[x] I signed the CLA.
[x] I listed at least one issue that this PR fixes in the description above.
[x] I updated/added relevant documentation (doc comments with ///).
[x] I added new tests to check the change I am making or feature I am adding, or Hixie said the PR is test-exempt.
[x] All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

Closing; Duplicate of #83995

Reopening as duplicate was closed.

Gold has detected about 1 new digest(s) on patchset 5.
View them at https://flutter-gold.skia.org/cl/github/87643

@kjlubick is the skia-gold bot confused on this one? I do not see image changes. :)

I think the comment could be due to a short-cut the commenting logic takes - If a digest has been triaged positively, but not produced recently, it will (incorrectly) flag it as new.
See them here https://flutter-gold.skia.org/search?crs=github&issue=87643&patchsets=5&positive=true (by checking positive and "exclude results from primary branch").

Ah I see! This is an older PR as well, I do not think it has been updated with changes from master. I can see an old image that was approved before, that has changed since then. Makes sense, thanks for explaining @kjlubick!

Hi @werainkhatri thanks for the update! Can you check the test failures? There are some broken doc references in your PR.

Yes. The failure is because your suggested doc change had broken doc references. Could you review if the below doc is okay?
/// If null, uses size from [IconTheme]. If it is also null, the default size
/// is 24.0.

It looks like it is referencing the wrong class. IconThemeData.size looks like the correct reference.

Gold has detected about 1 new digest(s) on patchset 6.
View them at https://flutter-gold.skia.org/cl/github/87643

I think this will need a second reviewer per our new commit policy - for folks that are not a member of flutter-hackers, two approving reviews from folks that are is required.
Although, I do see that you have contributed several times to flutter, can you check out Contributor Access in the wiki and let me know if you are interested and feel that you qualify to be a member? If so, I'd be happy to sponsor you.

Although, I do see that you have contributed several times to flutter, can you check out Contributor Access in the wiki and let me know if you are interested and feel that you qualify to be a member? If so, I'd be happy to sponsor you.

Thank you so much for the opportunity!
Yes, I am interested in becoming a member and do qualify as per the first criteria, which is:

You have recently submitted several PRs that have landed successfully (received an LGTM, PR was merged, no regressions reported, PR was not reverted), without needing extensive tutoring in the process.

I have landed 12 PRs (with 2 in progress) to the flutter/flutter repository without any regression or revert, without extensive tutoring (imo).

That's great to hear @werainkhatri! Can you ping me on the discord in the #server-support channel so we can see about adding you? My user name is the same, @Piinks.


Clairify language in sumbission guidelines

Clarify the submission guidelines to make it clear that associatedSites and serviceSites also serve a /.well-known/first_party_sets.json containing a primary reference at a minimum.

Chris,
As I mentioned, still a bit of a GitHub newbie and making newbie mistakes.
The good thing is that I am not afraid to learn from my mistakes! :-)
Thanks,
Ralph
On May 1, 2023 at 3:48:15 PM, Chris Fredrickson @.***)
wrote:
@.**** commented on this pull request.
In FPS-Submission_Guidelines.md
https://github.com/GoogleChrome/first-party-sets/pull/21#discussion_r1181918542
:

@@ -138,7 +138,7 @@ Upon submission of a PR, a series of technical checks will run on GitHub to veri

Each domain must satisfy the /.well-known/ metadata requirement:

The /.well-known/ metadata requirement demonstrates that the
submitter has administrative access to the domains present in the set,
since administrative access is required to modify the /.well-known/
file. This will help prevent unauthorized actors from adding domains
to a set.
-The primary domain must serve a JSON file at
/.well-known/first-party-set.json. The contents of the file must be
identical to the submission. Each member domain must serve a JSON file
at /.well-known/first-party-set.json. The contents of the file must
name the primary domain. These files must be maintained for the
duration of the domain’s inclusion in the set.
+The primary domain must serve a JSON file at
/.well-known/first-party-set.json. The contents of the file must be
identical to the submission. Each of the associatedSites and
serviceSites domain must also serve a JSON file at
/.well-known/first-party-set.json. The contents of the
first-party-set.json file on these domains must at a minimum name the
primary domain. These files must be maintained for the duration of the
domain’s inclusion in the set.
(For future reference - you can iterate on a pull request and add more
commits to your branch, as it goes through code review, without having to
close the PR and open a new PR for each round of feedback. In this
particular case, I had written my suggestion as a "suggested change"
https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/incorporating-feedback-in-your-pull-request,
so that you could click "commit suggestion" and automatically incorporate
the feedback if you agreed with it.)
—
Reply to this email directly, view it on GitHub
https://github.com/GoogleChrome/first-party-sets/pull/21#discussion_r1181918542,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AWC4XZGOJI43KLJ7WOX4APLXEAVR7ANCNFSM6AAAAAAXR2U3RI
.
You are receiving this because you modified the open/close state.Message
ID: @.***>


*: implement configurable backup timeout

ref: https://github.com/coreos/etcd-operator/issues/1906

kube client doesn't take-in context

k8s client upstream issue ref: https://github.com/kubernetes/kubernetes/issues/46503
It also looks like in the REST API level client-go provides context support: https://github.com/kubernetes/client-go/blob/4def1285ff0e4d1fee7cc9e2684ef9923dca591f/rest/request.go#L411
But this is not propogated onto upper level.
There is a default 30s Dialer.Timeout:
https://github.com/kubernetes/client-go/blob/f4d24c8a47016d9ffcc8a44c4011d153cb413367/transport/cache.go#L84-L87
But no default timeout for http request.
My current conclusion is that this is not limited to backup. This is a general issue we need to work around or solve in upstream. Otherwise if it keeps hanging, anything using client-go will have problems.
My current suggest would be to leave a TODO signifying the current limitation of timeout.

cc/ @hongchaodeng @hasbro17

all fixed. PTAL cc/ @hongchaodeng

After offline discussion, we are going to add ctx to BackupWriter.Write() method too.

Let's move forward this and change BackupWriter in following PR.


Update server: opengrid and website

If I understand it correctly, the server currently runs OpenGrid via pip, not via git anymore?
In order to test the Slackbot on the website, following steps are needed:

[ ] Update the pip package on pypi
[ ] Update the package on the server
[ ] Pull the latest version of the website on the server
[ ] Manually change Slackbot config stuff on the server
[ ] Restart the web server (sudo service uwsgi restart opengrid or something)

@saroele could you answer the first question? If so, could you take care of the first 2 steps?

Indeed, it's to be sure we run a specific release.
I have some maintenance work to do.  I plan to do that in the coming days.
thanks for your work!
roel
On Wed, Nov 9, 2016 at 1:10 AM, Jan Pecinovsky<EMAIL_ADDRESS>wrote:

If I understand it correctly, the server currently runs OpenGrid via pip,
not via git anymore?
In order to test the Slackbot on the website, following steps are needed:

Update the pip package on pypi
Update the package on the server
Pull the latest version of the website on the server
Manually change Slackbot config stuff on the server
Restart the web server (sudo service uwsgi restart opengrid or
something)

@saroele https://github.com/saroele could you answer the first
question? If so, could you take care of the first 2 steps?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/opengridcc/opengrid/issues/160, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAiVBmcA-F2pFUWbangd-Uv_7Oj3R52nks5q8Q9egaJpZM4KtDzO
.

Don't forget the version bump!

the coming days passed too quickly for me, but tomorrow evening seems like more than enough to get this done.


Update introduction headings in guidance

Update introduction headings in guidance (specifically on Styles where "Introduction" is repeated) and subheadings (specifically on Styles which have no subheadings)

Go through every page and check if it has an h2 heading at top. If not, we need to add one.
Ideally the heading would describe whatever is in the first paragraph, but in times where that doesn't make sense we should use the term 'Inroduction' instead.
Some pages use the word 'Overview' and where we find pages with 'Overview' we should change it to 'Introduction' for consistency.

What is the purpose of the enhancement?
Consistency of page headings and subheadings
Why do we need it?
All the first headings to be the same for consistency. Currently some begin with 'Introduction' while others begin with 'Overview'. Refer to @MI6-94 for clarification

Overview of changes:


Updating login page to add TNA logo

This PR is to update the logo that is currently on the login page, to the TNA logo.

Here's the card for rebuilding the Keycloak login theme: https://national-archives.atlassian.net/browse/TDR-245
So we can close this PR, and revisit the logo changes when we've got our own Keycloak theme.


feat(outbound-pg): Reuse connection during request lifecycle

Also, pg_backend_pid endpoint into outbound-pg example.
Before the fix:
$ curl -i localhost:3000/pg_backend_pid
HTTP/1.1 500 Internal Server Error
content-length: 0
date: Tue, 27 Sep 2022 14:03:50 GMT

thread '<unnamed>' panicked at 'assertion failed: `(left == right)`
  left: `592913`,
  right: `592914`', src/lib.rs:112:5

After the fix:
$ curl -i localhost:3000/pg_backend_pid
HTTP/1.1 200 OK
content-length: 23
date: Tue, 27 Sep 2022 14:07:14 GMT

pg_backend_pid: 595194

Ideally, this fix has to be covered by an integration test rather than
manual testing through examples, but the testing environment has to be
set up first.
Refs: https://github.com/fermyon/spin/issues/667.
Signed-off-by: Konstantin Shabanov<EMAIL_ADDRESS>

@itowlson yep, it should be ready to go. The only thing I was thinking about is the difference with redis connections map implementation - https://github.com/fermyon/spin/blob/main/crates/outbound-redis/src/lib.rs#L19-L21
My understanding is that as the state is built per request then it's single-threaded. Am I missing something?

My understanding is that as the state is built per request then it's single-threaded. Am I missing something?

The difference with the outbound-redis example is that it is reusing connections between requests. Since this PR only caches within a single request it does not need to lock; individual requests are handled on a single thread.

@etehtsea Given Lann's edit to his comment, it looks like the pattern we should be adopting is the one you already have, so I'll merge this as it stands.  Thanks for the contribution and for taking the time to cross-check!


Nit: Fixing VMware spelling

Sorry for Nit, but VMware is spelled with lower-case "w"

LGTM. Thanks.