accessibility* props are not available for backdrop view

ModalProps extends ViewProps that should contains all accessibility props (https://reactnative.dev/docs/accessibility), but they are not used/applied to any view.
As backdrop is pressable, we should have ability to set accessibility attributes on this view.
For example:
    <Modal
      isVisible={visible}
      hasBackdrop={true}
      onBackdropPress={onBackButtonPress}
      accessible
      accessibilityRole="button"
      accessibilityLabel="Close modal"
      ...

But they are not taken into account because only onPress is passed here:
https://github.com/react-native-modal/react-native-modal/blob/b580105f4b2b4e1163bed1228f241b16ea17dacb/src/modal.tsx#L758
So I might be useful to add this accessibility attributes to backdrop view to help disabled people.
(maybe prefix accessib* props with backdropAccessib* to avoid concern confusion)
PS: I know there is customBackdrop, but I will be helpful to be handled out of the box by default backdrop

any updates about accessibility ?
Here is my workaround:
diff --git a/node_modules/react-native-modal/dist/modal.d.ts b/node_modules/react-native-modal/dist/modal.d.ts
index b63bcfc..6029d06 100644
--- a/node_modules/react-native-modal/dist/modal.d.ts
+++ b/node_modules/react-native-modal/dist/modal.d.ts
@@ -26,6 +26,7 @@ declare const defaultProps: {
     backdropOpacity: number;
     backdropTransitionInTiming: number;
     backdropTransitionOutTiming: number;
+    backdropAccessibilityLabel: string | undefined;
     customBackdrop: React.ReactNode;
     useNativeDriver: boolean;
     deviceHeight: number | null;
@@ -62,7 +63,7 @@ export declare type ModalProps = ViewProps & {
     onOrientationChange?: OnOrientationChange;
     presentationStyle?: PresentationStyle;
     useNativeDriverForBackdrop?: boolean;
-} & typeof defaultProps;
+} & Partial<typeof defaultProps>;
 export declare class ReactNativeModal extends React.Component<ModalProps, State> {
     static propTypes: {
         animationIn: PropTypes.Requireable<string | object>;
@@ -74,6 +75,7 @@ export declare class ReactNativeModal extends React.Component<ModalProps, State>
         hasBackdrop: PropTypes.Requireable<boolean>;
         backdropColor: PropTypes.Requireable<string>;
         backdropOpacity: PropTypes.Requireable<number>;
+        backdropAccessibilityLabel: PropTypes.Requireable<string>;
         backdropTransitionInTiming: PropTypes.Requireable<number>;
         backdropTransitionOutTiming: PropTypes.Requireable<number>;
         customBackdrop: PropTypes.Requireable<PropTypes.ReactNodeLike>;
diff --git a/node_modules/react-native-modal/dist/modal.js b/node_modules/react-native-modal/dist/modal.js
index 80f4e75..3b72366 100644
--- a/node_modules/react-native-modal/dist/modal.js
+++ b/node_modules/react-native-modal/dist/modal.js
@@ -398,7 +398,7 @@ export class ReactNativeModal extends React.Component {
                 !React.isValidElement(this.props.customBackdrop)) {
                 console.warn('Invalid customBackdrop element passed to Modal. You must provide a valid React element.');
             }
-            const { customBackdrop, backdropColor, useNativeDriver, useNativeDriverForBackdrop, onBackdropPress, } = this.props;
+            const { customBackdrop, backdropColor, useNativeDriver, useNativeDriverForBackdrop, onBackdropPress, backdropAccessibilityLabel, } = this.props;
             const hasCustomBackdrop = !!this.props.customBackdrop;
             const backdropComputedStyle = [
                 {
@@ -418,7 +418,7 @@ export class ReactNativeModal extends React.Component {
             }
             // If there's no custom backdrop, handle presses with
             // TouchableWithoutFeedback
-            return (React.createElement(TouchableWithoutFeedback, { onPress: onBackdropPress }, backdropWrapper));
+            return (React.createElement(TouchableWithoutFeedback, { onPress: onBackdropPress, accessibilityLabel: backdropAccessibilityLabel, accessibilityRole: "button", accessible: true }, backdropWrapper));
         };
         const { animationIn, animationOut } = buildAnimations(extractAnimationFromProps(props));
         this.animationIn = animationIn;

+1


Ethereum blockchain extractor and builder

Leveldb blockchain extractor to extract block related data from the blockchain. Builder enables to store blockchain data extracted using the extractor in an analyzable structure.

It's better to remove the code from header files

@prabushitha Can you format the cpp files using a linter?

@tharidu sure! I'll do.

@tharidu done. I've used cpplint which adhere with google C++ coding style.


cilium/ebpf memory optimizations

btfgen: optimization: return BTF when kernel supports it
This makes use of:

https://github.com/cilium/ebpf/pull/1584

See also https://github.com/cilium/ebpf/pull/1588

https://github.com/cilium/ebpf/pull/1585

See also https://github.com/cilium/ebpf/pull/1590

cilium/ebpf has two loading options:

opts.KernelTypes: BTF for the kernel
opts.KernelModuleTypes: map of BTFs for kernel modules

They are both optional: cilium/ebpf tries to figure out where the BTF is located if not provided by the caller.
Inspektor Gadget has different categories of ebpf programs:

Internal ebpf programs:

socket enricher
kfilefields
container-hook

Programs from builtin gadgets
Programs from image-based gadgets

In categories 1 and 2, ebpf programs are not attached to functions from kernel modules so we don't need cilium/ebpf support for that. Unfortunately, even without needing kernel module support, the cilium/ebpf implementation is costly in memory and cpu: it parses /proc/kallsyms to find out if a ebpf program should be attached to a function from a kernel module.
With a coming cilium/ebpf patch, we can avoid the cost of parsing /proc/kallsyms when providing opts.KernelTypes without providing opts.KernelModuleTypes. This patch does this to improve performances.
This patch does not affect programs from image-based gadgets (category 3), because opts.KernelTypes and opts.KernelModuleTypes are set from different code.


Make dominant pollutant nullable

Make dominant pollutant nullable. Also Pollutant.UNKNOWN is removed, as None would be a better value for an unknown pollutant.
Fixes #73

Codecov Report

Merging #74 (0fc04aa) into main (ab2057b) will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##              main       #74   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files            6         6
  Lines          181       184    +3
  Branches        26        27    +1
=========================================
+ Hits           181       184    +3

Files
Coverage Δ

src/aiowaqi/models.py
100.00% <100.00%> (ø)

src/aiowaqi/util.py
100.00% <100.00%> (ø)

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Add LEXBOR_C_FLAGS to Windows and remove -Wunused-function to posix c…

…ompilation (already added by -Wall)

Thanks!


IGamepad: Add extension methods to return a Thumbstick

Summary of the PR
This pull request adds extension methods to GamepadExtensions.cs to facilitate retrieving a Thumbstick as opposed to a Button. The current behavior is pretty confusing to new users like yours truly, so this PR aims to make this aspect more intuitive.
More details are noted in the issue linked down below.
Related issues, Discord discussions, or proposals
Closes https://github.com/dotnet/Silk.NET/issues/1468
Further Comments
This PR deprecates the old Button-returning methods IGamepad.LeftStick() and IGamepad.RightStick(), replacing them with IGamepad.LeftThumbstickButton() and IGamepad.RightThumbstickButton() respectively.
The new extension methods are named IGamepad.LeftThumbstick() and IGamepad.RightThumbstick(). The exact naming of all four new functions is of course not final, so feedback is appreciated on this manner.

I don't recall signing anything with Microsoft or the dotnet foundation, so it's very strange seeing that check pass. I'll run the command anyways just in-case:
@dotnet-policy-service agree

I take it these CI failures are not my fault? I'm unable to build Silk on my machine so I can't say for sure.
(I'm on Linux so the iOS frameworks are a no-go.)


ActiveRecord::SubclassNotFound: The single-table inheritance mechanism failed to locate the subclass: 'local'. This error is raised because the column 'type' is reserved for storing the class in case of inheritance. Please rename this column if you didn't

View details in Rollbar: https://rollbar.com/trystant/BOW/items/691/

NameError: wrong constant name local
  File<EMAIL_ADDRESS>line 261, in const_get
  File<EMAIL_ADDRESS>line 261, in block in constantize
  File<EMAIL_ADDRESS>line 259, in each
  File<EMAIL_ADDRESS>line 259, in inject
  File<EMAIL_ADDRESS>line 259, in constantize
  File<EMAIL_ADDRESS>line 566, in get
  File<EMAIL_ADDRESS>line 597, in constantize
  File<EMAIL_ADDRESS>line 181, in find_sti_class
  File<EMAIL_ADDRESS>line 169, in discriminate_class_for_record
  File<EMAIL_ADDRESS>line 67, in instantiate
  File<EMAIL_ADDRESS>line 50, in block (2 levels) in find_by_sql
  File<EMAIL_ADDRESS>line 51, in block in each
  File<EMAIL_ADDRESS>line 51, in each
  File<EMAIL_ADDRESS>line 51, in each
  File<EMAIL_ADDRESS>line 50, in map
  File<EMAIL_ADDRESS>line 50, in block in find_by_sql
  File<EMAIL_ADDRESS>line 20, in instrument
  File<EMAIL_ADDRESS>line 49, in find_by_sql
  File<EMAIL_ADDRESS>line 24, in find_by_sql
  File<EMAIL_ADDRESS>line 639, in exec_queries
  File<EMAIL_ADDRESS>line 515, in load
  File<EMAIL_ADDRESS>line 243, in to_a
  File<EMAIL_ADDRESS>line 62, in to_a
  File<EMAIL_ADDRESS>line 500, in find_nth_with_limit
  File<EMAIL_ADDRESS>line 484, in find_nth
  File<EMAIL_ADDRESS>line 127, in first
  File<EMAIL_ADDRESS>line 57, in first_by_friendly_id
  File<EMAIL_ADDRESS>line 21, in find
  File "/home/ubuntu/workspace/app/controllers/agencies_controller.rb", line 72, in set_agency
  File<EMAIL_ADDRESS>line 432, in block in make_lambda
  File<EMAIL_ADDRESS>line 145, in block in halting_and_conditional
  File<EMAIL_ADDRESS>line 504, in block in call
  File<EMAIL_ADDRESS>line 504, in each
  File<EMAIL_ADDRESS>line 504, in call
  File<EMAIL_ADDRESS>line 92, in __run_callbacks__
  File<EMAIL_ADDRESS>line 778, in _run_process_action_callbacks
  File<EMAIL_ADDRESS>line 81, in run_callbacks
  File<EMAIL_ADDRESS>line 19, in process_action
  File<EMAIL_ADDRESS>line 29, in process_action
  File<EMAIL_ADDRESS>line 32, in block in process_action
  File<EMAIL_ADDRESS>line 164, in block in instrument
  File<EMAIL_ADDRESS>line 20, in instrument
  File<EMAIL_ADDRESS>line 164, in instrument
  File<EMAIL_ADDRESS>line 30, in process_action
  File<EMAIL_ADDRESS>line 250, in process_action
  File<EMAIL_ADDRESS>line 153, in process_action
  File<EMAIL_ADDRESS>line 18, in process_action
  File<EMAIL_ADDRESS>line 137, in process
  File<EMAIL_ADDRESS>line 30, in process
  File<EMAIL_ADDRESS>line 196, in dispatch
  File<EMAIL_ADDRESS>line 13, in dispatch

@IsaacBell Type is a reserved name in Rails, which is why you ran into this error.


add location informationt to runaway errors

fixes #572
pretty straightforward change to make sure we pass location information
along with the error when detecting a runaway program

@dmajda @bkutil

Oh example output:
rlgomes@x230> bin/juttle -e 'read file -file "xxx" -from :beginning: -to :end: | tail 1'
<input>:1:53:
   1:read file -file "xxx" -from :beginning: -to :end: | tail 1
                                                         ^^^^^^
Error: Not starting program as it would run forever with no output. Add a -to option to read? (RUNAWAY-PROGRAM)

Shouldn't the location point to readNode instead of nextNode? I.e. highlight the read not tail in the example above?

@bkutil yo'ure right since its indicating to add the -to message that makes more sense... let me look at each one and make sure the message matches the node that is at fault. Good catch!

And I'll add tests to verify the location stays correct with any future changes in this area.

@bkutil
rlgomes@x230> bin/juttle -e 'read file -file "xxx" -from :beginning: -to :end: | tail 1'
<input>:1:1:
   1:read file -file "xxx" -from :beginning: -to :end: | tail 1
     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Error: Not starting program as it would run forever with no output. Add a -to option to read? (RUNAWAY-PROGRAM)

Looks good! :) +1


update badges, readme

Codecov Report
All modified lines are covered by tests :white_check_mark:

Comparison is base (865525d) 19.19% compared to head (f7fa2ed) 19.19%.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@           Coverage Diff           @@
##             main     #112   +/-   ##
=======================================
  Coverage   19.19%   19.19%
=======================================
  Files          22       22
  Lines        1490     1490
=======================================
  Hits          286      286
  Misses       1204     1204

Flag
Coverage Δ

unittests
19.19% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


[TD-33178] test: stmt2 performance test

Stmt2 performance test

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 74.74%. Comparing base (722bb51) to head (3591ca9).
Report is 3 commits behind head on feat/TD-32234.

Additional details and impacted files
@@                Coverage Diff                @@
##           feat/TD-32234     #398      +/-   ##
=================================================
+ Coverage          74.65%   74.74%   +0.09%
=================================================
  Files                102      102
  Lines              38747    38812      +65
=================================================
+ Hits               28925    29009      +84
+ Misses              9822     9803      -19

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


landing page for GatherTownJS

I might need help on this, basic landing is enough that can be improved later.
I will include the branding here in this issue.

I got this one! What are the requirements?

I got this one! What are the requirements?

Same thing with the buymeacoffee.js almost the same.
The color would be the same as the branding of https://gather.town

Here's the sample look I'm thinking.

For now, follow the color hex which is based on their website.
Indigo - #333A64
Dark Indigo - #282D4E
Green - #51E2BD
Make sure the copy button is green.

Here's the sample look I'm thinking.

For now, follow the color hex which is based on their website. Indigo - #333A64 Dark Indigo - #282D4E Green - #51E2BD
Make sure the copy button is green.

Got it! This seems simple enough. I can start working on this.

Here's the sample look I'm thinking.

For now, follow the color hex which is based on their website. Indigo - #333A64 Dark Indigo - #282D4E Green - #51E2BD
Make sure the copy button is green.

Got it! This seems simple enough. I can start working on this.

Did you start working on this?

Here's the sample look I'm thinking.

For now, follow the color hex which is based on their website. Indigo - #333A64 Dark Indigo - #282D4E Green - #51E2BD

Make sure the copy button is green.

Got it! This seems simple enough. I can start working on this.

Did you start working on this?

I can start working on this tomorrow.

Here's the sample look I'm thinking.

For now, follow the color hex which is based on their website. Indigo - #333A64 Dark Indigo - #282D4E Green - #51E2BD

Make sure the copy button is green.

Got it! This seems simple enough. I can start working on this.

Did you start working on this?

I can start working on this tomorrow.

Awesome! Same procedure... PR to the dev branch.

Closing this now! Any additional improvements and enhancements to the landing page should create a separate issue.


/amazon/opensearch-dashboards:1.1.0 not found: manifest unknown: manifest unknown

I am trying to deploy Opni on a private kubernetes environment using a proxy. I was able to push all the yaml files with no problem and while trying to deploy the elastic image I got the following message: /amazon/opensearch-dashboards:1.1.0 not found: manifest unknown: manifest unknown
As I did for all the other images. I added the proxy before the image link and it didn't work.
my question is : can we change the source of the elastic image and how can we do this?

Hi @Zakaria-laktati,
defaultRepo should contain the name of your private image registry, e.g.
elastic:
  defaultRepo: your.image.registry/amazon

You can also specify the full image references as follows (this will override defaultRepo and version)
elastic:
  image: your.private.registry/amazon/opensearch:tag
  kibanaImage: your.private.registry/amazon/opensearch-dashboards:tag

Regarding the first solution, it's the same thing I did at the beginning when I got the error: /amazon/opensearch-dashboards:1.1.0 not found: manifest unknown: manifest unknown
and when i tried to put the full image references like you suggested. I got the following error message:

thanks in advance

Sorry, it should actually be:
elastic:
  image:
    image: your.private.registry/amazon/opensearch:tag
  kibanaImage:
    image: your.private.registry/amazon/opensearch-dashboards:tag


Is it possible to drop everything inside the main branch before creating a new branch?

Is it possible to add a flag to create_branch that would allow everything from the main branch to be dropped when creating a new branch? For example, create_branch(orphan=true)

sounds reasonable to me from quick glance
I'm also wondering if we have a way to create a branch from a specific commit (i don't remember 🤔 ) – as you could programmatically create a branch from the initial commit on main

no issues, created an internal issue

Makes sense :+1:  I'll keep you updated about our internal progress :)
I'm cc-ing @patrickvonplaten @SBrandeis @apolinario @julien-c @osanseviero @LysandreJik if you want to add something on this topic as I remember the "how should we handle different variations of the same weights"-question  has been heavily discussed internally (private thread). Decision was to encourage further to have all checkpoints on the same branch but some adjustments have to be made to the existing libraries, so it's more a mid-term perspective.

thanks @Wauplin ❤ if we put all the checkpoints in the same branch and If people only want to use the flax models, they have to clone 4000000GB of data maybe more 😋

When I first heard the idea from @patrickvonplaten, it sounded cool, but when I tried using the idea, I found that we should put everything in different branches, this is the way 😋

@camenduru I just merged https://github.com/huggingface/huggingface_hub/pull/1293 which allows you to create a branch from any given revision. As mentioned in https://github.com/huggingface/huggingface_hub/pull/1293#issue-1536352063, you still need to know the initial commit hash in order to create a branch from it.
If that is enough for your use case, you can close this issue. Otherwise, let's keep it open to remember about having an endpoint to retrieve the git history (note: we already have an internal issue for that but it might not be implemented before next release of hfh)

I will try this git rev-list --max-parents=0 HEAD

Yep, I understand the problem of not having a get_first_revision_hash-like helper in the API at the moment (or something like initial=True). The problem is that it requires to add a new endpoint server-side. This is still not done (and will not be done before hfh v0.12) but we have an internal ticket to track the feature request.
About git rev-list --max-parents=0 HEAD, that's true it's a solution but only if you've clone the repo locally. The goal of create_branch(repo_id, branch="branch", initial=True) would be to have this helper using only HTTP endpoints.

Server-side implementation is done, PR is on its way to have it in huggingface_hub @camenduru :wink: https://github.com/huggingface/huggingface_hub/pull/1331


Another deadlock - or at least a very slow lock

I added this to #57 but thought that since it's closed, the repro for an bug there may not have been noticed.
Here's the last post from that thread...  Basically it's an issue which v3 doesn't exhibit but v4 and v5 do.  I think I may have hit this in production, just after I finally moved to v4.x after staying on a patched v3.x for many months.
It's intermittent but definitely does reproduce for me after a few executions.  Hoping you can shed some light on the issue :)
Thanks for the library and the general community work!
Post from #57 starts now...
The repro provided by @Allon-Guralnek will cause the issue for me.
In LinqPad I've got this
AsyncLock l = new AsyncLock();

void Main()
{
	Task.Run(() =>
	{

		Console.WriteLine("Starting tasks...");
		var tasks = Enumerable.Range(0, 100).Select(i => Task.Run(() => Do1(i))).ToArray();

		Console.WriteLine("Tasks started. Waiting for all to complete...");
		Task.WaitAll(tasks);

		Console.WriteLine("All done!");
	}).Wait();
}

void Do1(int i)
{
	if (i == 0)
		Thread.Sleep(100);

	using (l.Lock())
	{
		// mutate shared state atomically
	}

	Console.WriteLine("Done: " + i);
}

void Do2(int i)
{
	if (i == 0)
		Thread.Sleep(100);

	lock (l)
	{
		// mutate shared state atomically
	}

//	Console.WriteLine("Done: " + i);
}

You'll note that I've got a Task.Run() in the main() method to get it started.
Sometimes it runs through just fine.  Other times it'll stop.
Example output
Starting tasks...
Done: 1
Tasks started. Waiting for all to complete...
Done: 2
Done: 99

and 1 minute 13 seconds later I'm still nowhere :(
After 1 minute 28 seconds it suddenly finished
Starting tasks...
Done: 1
Tasks started. Waiting for all to complete...
Done: 2
Done: 99
Done: 4
Done: 3
Done: 6
Done: 7
Done: 8
Done: 5
Done: 9
Done: 98
Done: 0
Done: 10
Done: 11
Done: 12
Done: 13
Done: 14
{{snip}}All the rest were in order{{/snip}}

But I can hit stop & start and get it working again.  9 times out of 10 it works properly.  Removing the Console.WriteLine inside the loop seems to make it fail more often.
With LinqPad I can quickly swap between
Nito.AsyncEx.Coordination NuGet package -  this made the poor output above
Nito.AsyncEx NuGet package v3.x - works
Nito.AysyncEx NuGet package v4.x (strong named one was convenient to use) - failed first go with no output at all :(
Nito.AsyncEx v3.x with one line patched from earlier - works
So this appears to be a regression where v3.x - with the one-line patch from earlier in this issue - is good but AsyncEx v4.x and v5.x are both bad.
It's a tricky one as it's intermittent and does eventually come good.

Yes, this is actually a known problem (though it didn't have a GH issue before). In fact, this is exactly the reason why AsyncEx v5 is still in prerelease. One of my commercial clients first made me aware of it, and while they're waiting for a fix they just cranked up the min-threads on the thread pool as a workaround.
This problem comes up most often when:

Many thread pool threads are synchronously waiting on an AsyncEx primitive.
The thread pool is exhausted.

What's actually happening is that the first lock goes through just fine (synchronously). Then the thread pool is exhausted with a bunch of threads synchronously blocked on that lock. Then when the first thread unlocks, it releases the next waiter, but requires a thread pool thread to do so. Thus, it must wait until the thread pool gets around to running that "release" code. Meanwhile, the thread pool is injecting one new thread every 2 seconds or so, in no rush. So we end up with a lock convoy with huge wait times due to the thread pool injection rate.
This is due to the core change of v4 -> v5: all continuations are asynchronous in the core of all the primitives (AsyncWaitQueue is the "core"). This simplifies the code considerably, but does assume that there is available room on the thread pool.
For a solution, I'm trying out variations of a custom "completer" thread. Something very similar to Ayende's blog here.

Hi @StephenCleary - thanks very much for the comprehensive answer.
Ayende's solution looks pretty smart.  Having a thread set aside to "keep things going" whilst also letting the ThreadPool race to handle the continuation might add a tiny bit of overhead (negligible probably) but avoids this, which is a huge plus.
Your mention of min threads does remind me that in our web app I've bumped up min threads as it helped with something similar a while ago.  Maybe I've just run into it again?  Anyway, v3.x (with the one change discussed about a year ago from #57 ) is working fine for me at the moment.
I only ran into this, I think, because in our web app I have some leases on some image & blob objects which are acquired asynchronously.  There's also a background process which releases them from memory if they haven't been actively used in a while.  That's handled using IDisposable, and to ensure a lease isn't returned whilst disposing (returning a lease after dispose just disposes rather than pooling again) I took a sync lock during the Dispose.
I still have that code, but since the only thing really doing a Dispose is that background task, it does the resource cleanup asynchronously, effectively using an AsyncDispose call, before calling the real Dispose.  Therefore the real Dispose just checks to see if disposed is already set, and if so, doesn't do any extra work.  I'm safe enough in case I do a Dispose via other means in future but avoid the sync-lock on an AsyncLock.
Thanks again for the great library & support!
Feel free to close this issue, or if it helps with planning, leave it open.

Basically these starvation issues can only ever happen when using the AsyncEx primitives both synchronously and asynchronously.
Isn't it?

No; the problem can be caused by either synchronous or asynchronous APIs when the thread pool is saturated. At the core, both sync and async lock APIs require a thread pool to become unlocked, and that's what causes the issue.

Thanks it's clear now.

This is due to the core change of v4 -> v5: all continuations are asynchronous in the core of all the primitives (AsyncWaitQueue is the "core"). This simplifies the code considerably, but does assume that there is available room on the thread pool.

For a solution, I'm trying out variations of a custom "completer" thread.

Don't you think that spawning your own thread to solve this issue would be both overkill and complex? Making continuations synchronous again seems, so we don't have this issue, seems way nicer and easier to debug.

Making the continuations synchronous has its own problems. For a given TaskCompletionSource, its continuations can either be forced-asynchronous (used by v5) or unspecified (used by v4).
Synchronization primitives in v4 avoid this thread pool exhaustion issue by using synchronous continuations. However, since end-user code is also expressed as a continuation, we have to force those continuations to be asynchronous or else we'd end up with a callback-under-lock scenario, which very easily results in deadlock. So in v4, all continuations are actually semi-asynchronous; they're synchronous enough to avoid the thread pool exhaustion but asynchronous enough to avoid the deadlock. As you can imagine, this complicates the code considerably.
I do much prefer the approach forcing asynchrony for end-user continuations, just from a code perspective (simpler, easier to prove correct, easier to maintain). Assuming I keep this, there are two options for avoiding the thread pool exhaustion issue: introducing a separate thread, and separating end-user continuations from internal continuations (requiring separate TCSs). I've played with both and am definitely leaning towards the thread solution.

Anytime I've used AsyncEx I've typically bought into multithreading enough that paying the overhead of one more dedicated thread was not an issue for performance. I don't think it would make a difference, one way or the other, for the experience of debugging client code. The thread solution gets my vote if it's simpler to maintain.

The beauty of asynchronous programming is that "there is no thread". I learned from Stephen, both by his book and articles.
If it's easier to maintain I understand of course, but I just find it a bit "sad" we have to rely on spawning a manual Thread, which isn't controlled by the ThreadPool. It still feels complicated.

Possibly complicated, but it's entirely abstracted away by the library to the point where 99% of library consumers won't even know it's there.
Making continuations asynchronous avoids the "sometimes sync, sometimes async" behaviour that brought jQuery promises a bad name.  I appreciate the environment is different - since JS is completely single-threaded - but the consistency argument still applies  (see http://blog.izs.me/post/59142742143/designing-apis-for-asynchrony and https://medium.com/@bluepnume/intentionally-unleashing-zalgo-with-promises-ab3f63ead2fd for the JS-side of the fence).

Thanks Ian these are very good arguments, I agree most people will just consume the library, without looking deep in the internals.
One remark though: even today when you await in C#, it may go synchronous or asynchronous as well.
If the Task is already completed then the continuation will most likely be synchronous.
So what you describe is already happening now.

Just to clarify, the synchronous vs asynchronous continuations that I'm talking about are only when there is a continuation, so from the end-user's perspective this only applies when the await is asynchronous. When I'm talking about the continuation being synchronous or asynchronous, that's from the perspective of the TCS-completing thread.
To use a lock example, LockAsync will behave synchronously if the lock is unlocked; that's not going to change. The situation we're fixing here is when the lock is already locked, and some code UseResource calls LockAsync (which behaves asynchronously since the lock is already locked) and awaits on the returned task. Then when some thread releases the lock, we need to complete that TCS, but we can't do it while holding an internal lock. We need to push that completion outside of the lock, which is most easily done by forcing the continuation to be asynchronous.
So there are still plenty of situations with AsyncEx where end-user code will await, and it will behave synchronously, just like other TAP code. This issue is purely about a careful internal design that will be maintainable, prevent deadlocks, and also continue to work when the thread pool is exhausted. It won't have any effect on end-user semantics as far as which operations act synchronously and which ones are asynchronous.
This actually comes down to how await schedules continuations. Specifically, it always schedules them synchronously - so, after an await acts asynchronously, when its task is completed, the asynchronous method that did the await attempts to resume synchronously on the same thread and stack that is completing the task. When I discovered this, I found it very surprising and reported it as a bug (closed as "by design"). It can cause deadlocks (as described in my bug report) as well as stack overflows, unless end-user code take steps to prevent it.
It's my personal opinion that JavaScript's promise callback and await semantics are much better than C#'s await semantics. I think Microsoft was too focused on micro-benchmarks and missed out on providing an easier-to-use abstraction for developers.

Reading the VS release notes for 15.4.1 (out as of about 40 minutes ago) I came across this Roslyn thread
https://github.com/dotnet/roslyn/issues/22650#issuecomment-335638013
It's not quite the same issue but it reminded me of this discussion.  A block synchronous resource - disk - coupled with lots of async calls piling up, then the thread pool starving (or growing very slowly).  Their problem is they also gobbled up RAM at the same time.  The solution they seem to be discussing (and have released) is to have a single thread to which the other tasks post their requests for work.
Sorry if this is off-topic - I just found it interesting as another manifestation of a problem in the same ballpark as this thread's issue.

That is very interesting. Particularly since the thread pool has special dedicated I/O threads so that the limited thread injection rate shouldn't affect that kind of scenario. But in reality, a lot of the time the BCL code running on the I/O thread will post work to a worker thread so it "jumps" over to the more limiting side before it executes end-user code.

Why not just create a SemaphoreSlim(1,1) and use WaitAsync() on it.  That has the effect of locking?

@waynebrantley Yes, that's a fine workaround while this bug is still in AsyncEx.

Seems it's ok in netcoreapp(but not ported to netfx), Task.Wait() don't need an new thread in netcoreapp(whether TaskCreationOptions.RunContinuationsAsynchronously is set).
https://github.com/dotnet/coreclr/blob/v2.1-rc1/src/mscorlib/src/System/Threading/Tasks/Task.cs#L2955
https://github.com/dotnet/coreclr/commit/0163ed29ca05275f94101051284be9a8ccf235ed
So maybe similar logic can be apply to AsyncEx's TaskExtensions.Wait*()?
    public static class TaskExtensions
    {
        ///......

        //Change all `task.GetAwaiter().GetResult()/Wait(...)` before to `task.WaitResultSync(...)/WaitSync(...)

        private static T WaitResultSync<T>(this Task<T> task, CancellationToken cancellationToken = default(CancellationToken))
        {
            task.WaitSync(cancellationToken);
            return task.GetAwaiter().GetResult();
        }

        private static void WaitResultSync(this Task task, CancellationToken cancellationToken = default(CancellationToken))
        {
            task.WaitSync(cancellationToken);
            task.GetAwaiter().GetResult();
        }

        private static void WaitSync(this Task task, CancellationToken cancellationToken = default(CancellationToken))
        {
            if (task.IsCompleted)
                return;
            var t2 = task.ContinueWith(t => { }, cancellationToken, TaskContinuationOptions.ExecuteSynchronously | TaskContinuationOptions.HideScheduler, ForceInlineTaskScheduler.Instance);
            t2.Wait(cancellationToken);
        }

        private class ForceInlineTaskScheduler : TaskScheduler
        {
            public static ForceInlineTaskScheduler Instance { get; } = new ForceInlineTaskScheduler();

            private ForceInlineTaskScheduler() { }

            protected override IEnumerable<Task> GetScheduledTasks() => null;

            protected override void QueueTask(Task task)
            {
                TryExecuteTask(task);
            }

            protected override bool TryExecuteTaskInline(Task task, bool taskWasPreviouslyQueued)
            {
                return TryExecuteTask(task);
            }
        }
    }

The problem isn't that Task.Wait needs a thread pool thread.
The problem is that TaskCompletionSource.TrySetResult executes end-user callbacks (continuations) synchronously, and I call it while holding a lock. To prevent deadlocks, I use TaskCreationOptions.RunContinuationsAsynchronously with that TaskCompletionSource. This is what is requiring the thread pool thread, and causing extreme slowdowns (and possibly deadlocks) when the thread pool is exhausted.
Running the continuations synchronously would just trade one deadlock for another.

Yes, the before code didn't change that. All continue outside still run in async. WaitSync() just create an temp Task t2, and force it to be run after the orig task in sync, and Wait the new Task.

Ah, I see now. That is an interesting approach! I'll take this into consideration.

Can the thread pool exhaustion be detected upfront? So if you start off something that needs one additional thread, could you know that it's going to be a problem and do something about it while a thread is still awake?

@ygoe: I've never tried. There's ThreadPool.GetAvailableThreads, but it has unclear semantics - is the value the number of currently available threads, or the number of threads that can be created without a cooldown delay?

I'm sorry I don't know it myself. Just tried to throw in an idea to get this resolved. My own library is now tied to being a pre-release because of this dependency.

I've been working on a few different experiments related to this issue. During my travelling for OSCON, I thought it would be useful to write out the background and context in which I'm thinking about this problem. Doing this was a great exercise; it allowed me to step back and identify each of the issues at hand (and then choose a new approach). This comment is mostly a brain-dump for now, but some of it will be reworked into a CONTRIBUTING doc at some point.
Central Postulates:

AsyncEx uses locks, not lockless code. Lockless code is difficult to understand and verify, and - even more dangerously - it's very common to think one understands how to write lockless code when this is not the case, due to the incredible complexity of memory models. See Double-Checked Locking Is Broken for a good historical example from Java.

The greatest cardinal sin of concurrent programming is invoking arbitrary code while holding a lock. In the general case, this includes completing a TCS, since continuations may run synchronously.

AsyncEx Code
Most AsyncEx coordination primitive code is straightforward and doesn't even use async/await. However:

Some methods do use async/await.
One interaction is particularly notable: the relationship between AsyncLock and AsyncConditionVariable. The ACV needs to be able to unlock and relock the AL without affecting the IDisposable "key" that the user already has.
Coordination primitives which queue are built on a wait queue abstraction, which permits users to do fancy things like create priority locks. This wait queue abstraction does force us to use sync-over-async in some places instead of using the (preferred) boolean argument hack; AsyncConditionVariable is a good example of this.

So, a good cross-section for experimentation purposes is:

AsyncManualResetEvent (extremely simple, no queue)
AsyncSemaphore (simple with queue)
AsyncLock + AsyncConditionVariable (internal interaction, and code that requires sync-over-async).

When I run experiments like this, I focus on these four types. If it works for them, it should work anywhere.
AsyncEx v4
In v4, all TCS's used synchronous continuations, just like "normal" async code. v4 avoided invoking end-user callbacks under lock by separating the TCS completion code from internal logic. This necessitated a bit of a "dance" between the wait queue and the coordination primitives, with the completion code represented by a disposable.
This worked well enough, but has always had one theoretical issue: stack overflow is a possibility. The TPL does have heuristics in place to prevent this, but they don't always work. AFAIK, this was never actually observed in production.
In v5, one of the main changes was to use asynchronous continuations for TCS's. This simplified the wait queue code (and coordination primitive code) by removing the "dance" completely. Unfortunately, this has caused a dependency on the thread pool even for internal operations. And this issue is not theoretical; it is very rare but has certainly been observed.
Possible Solutions
Solutions must maintain the Central Postulates above, in addition to these considerations:

If we have a dedicated thread, then we want to keep end-user code from ever running on that thread. The thread must be dedicated to executing our own short, nonblocking internal code.
Our internal code must not depend on a thread pool thread. In the original example code for this problem, Lock returned an IDisposable whose Dispose implementation dependended on a thread pool thread. However, it is permissible to depend on a thread pool thread to resume executing asynchronous end-user code.

The solutions that I've considered (some of these have experimental code in different branches):

ForceInline:

Use RunContinuationsAsynchronously | DenyChildAttach flag for all TCS tasks. These can be returned to the user or our own code.
Our code uses ForceInline to override the RunContinuationsAsynchronously flag and force our continuations to be synchronous.
Evaluation:
:+1: Similar to how the old code works.
:-1: No protection from stack exhaustion. The old code did (in theory).
:-1: Users can use ForceInline to override our own force-asynchronous behavior.

Dedicated Thread:

Use RunContinuationsAsynchronously | DenyChildAttach flag for all TCS tasks. These can be returned to the user or our own code.
Our code uses ResumeOnDedicatedThread to override the RunContinuationsAsynchronously flag and force the continuations to run asynchronously on our dedicated thread.
Our code does not need to complete TCS's from the dedicated thread.
:+1: Our code always runs on the dedicated thread.
:-1: Users can use ForceInline to override our own force-asynchronous behavior, and thus execute end-user code on our dedicated thread.

TCS Pair with ConfigureAwait(false)

FirstTcs is a normal TCS.
SecondTcs is a normal TCS, linked from FirstTcs by giving FirstTcs a continuation that propagates its completion to SecondTcs, wrapped with an explicit Task.Run.
Our code awaits FirstTcs using ConfigureAwait(false).
User only sees SecondTcs, which is forced asynchronous (due to Task.Run).
:+1: Similar to how the old code works, including (theoretical) protection from stack exhaustion.
:+1: Users cannot force synchronous behavior using ForceInline, due to the explicit Task.Run.
:-1: Our awaits are not guaranteed to be synchronous. If stack exhaustion is imminent, or if the user is (indirectly) completing a TCS that doesn't want to run our continuation, then we will still require a thread pool thread. The old v4 code had this same problem.

TCS Pair with ForceInline

Just like above, but instead of awaiting FirstTcs.ConfigureAwait(false), our code awaits FirstTcs.ForceInline().
:+1: Similar to how the old code works.
:+1: Users cannot force synchronous behavior using ForceInline, due to the explicit Task.Run.
:-1: No protection from stack exhaustion. The old code did (in theory).

TCS Pair with ResumeOnDedicatedThread

Just like above, but instead of awaiting FirstTcs.ConfigureAwait(false), our code awaits FirstTcs.ResumeOnDedicatedThread().
:+1: Our code always runs on the dedicated thread.
:+1: Users cannot use ForceInline to override our own force-asynchronous behavior, due to the explicit Task.Run. This prevents users from executing end-user code on our dedicated thread.

Conclusion
After writing all these out, I believe the best solution going forward is the last one. My next step is to experiment with that solution on the experimental cross-section (AsyncManualResetEvent + AsyncSemaphore + AsyncLock + AsyncConditionVariable), and if that looks good, apply it through the rest of the code.

I'm very sorry to sound demanding, but this project appears dead to me. This library does a really great job and is really helpful in my project. I've read a lot of helpful and profound comments and answers from you in several places, that's why I consider your work valuable. I decided to use the v5 branch of AsyncEx to be more future-proof and I think there was also another reason to use it. But this ongoing delay of a release is starting to get in my way now. I'm about to release a library myself and it makes use of some of the AsyncEx functions. NuGet forces me to label my package as a pre-release because it has a pre-release dependency. So I'm considering to remove that package dependency and incorporate all referenced code into my own code base. This isn't something I like to do, but it seems the only way out of this release handling. A regular fork of the library would be more difficult because I'd need a new name and do all the packaging. And even though forks might immediately help others, too, they usually hurt the community in the long run.
So if you could find some time to resolve this last issue or maybe at least note it as a known issue in a stable release, I'd really appreciate that. There have been some suggestions in this discussion that sound promising. I know I'm not very helpful in the matter, I've tried before but this just exceeds my experience.

@ygoe Yes, I have considered releasing a stable version with this as a known bug. The perfectionist in me doesn't like that, but commercial software does it all the time.
I've done a ton of work in different branches, approaching the problem different ways, but hitting blocks each time. I did finally find a permanent solution, but haven't had time to implement it (the final solution also requires careful documentation).
At the same time, I'm aware of the problems with keeping a library prerelease for so long. My current plan is to try to finish this issue once and for all over MVP summit (one time of the year when I have a lot more free time than normal). If I don't finish it then, then I promise I'll release it as stable with a known issue.

@StephenCleary Thank you for the update. I'm looking forward to end of March this year. :-)

Concerning the use of SemaphoreSlim, I observe the same issue here, but only when async and sync stuff are mixed.
Here is the code to reproduce this issue using SemaphoreSlim:
using System;
using System.Diagnostics;
using System.Threading;
using System.Threading.Tasks;

namespace Example
{
  public class Program
  {
    static readonly SemaphoreSlim s = new SemaphoreSlim(1, 1);

    static void Main()
    {
      Task.Run(() =>
      {
        Console.WriteLine("Starting tasks...");
        var sw = new Stopwatch();
        sw.Start();

        var tasks = RunTasks(onlySync: true, onlyAsync: false);

        Console.WriteLine("Sync tasks started. Waiting for all to complete...");
        Task.WaitAll(tasks);

        sw.Stop();

        Console.WriteLine("All sync tasks done! Time elapsed: " + sw.Elapsed.TotalSeconds + " seconds");

        sw.Reset();
        sw.Start();

        tasks = RunTasks(onlySync: false, onlyAsync: true);

        Console.WriteLine("Async tasks started. Waiting for all to complete...");
        Task.WaitAll(tasks);

        sw.Stop();

        Console.WriteLine("All async tasks done! Time elapsed: " + sw.Elapsed.TotalSeconds + " seconds");

        sw.Reset();
        sw.Start();

        tasks = RunTasks(onlySync: false, onlyAsync: false);

        Console.WriteLine("Mixed tasks started. Waiting for all to complete...");
        Task.WaitAll(tasks);

        sw.Stop();

        Console.WriteLine("All mixed tasks done! Time elapsed: " + sw.Elapsed.TotalSeconds + " seconds");
      }).Wait();

      Console.ReadLine();
    }

    static Task[] RunTasks(bool onlySync, bool onlyAsync)
    {
      bool mixed = !onlySync && !onlyAsync;
      var tasks = new Task[30];

      for (int i = 0; i < 30; i++)
      {
        Task task;
        int i1;

        if (mixed)
        {
          if (i % 2 == 0)
          {
            i1 = i;
            task = Task.Run(() => DoWithSemaphore(i1));
          }
          else
          {
            i1 = i;
            task = Task.Run(async () => await DoWithSemaphoreAsync(i1));
          }
        }
        else if (onlySync)
        {
          i1 = i;
          task = Task.Run(() => DoWithSemaphore(i1));
        }
        else
        {
          i1 = i;
          task = Task.Run(async () => await DoWithSemaphoreAsync(i1));
        }

        tasks[i] = task;
      }

      return tasks;
    }

    static void DoWithSemaphore(int i)
    {
      s.Wait();

      try
      {
        // mutate shared state atomically
        Thread.Sleep(100);
      }
      finally
      {
        s.Release();
      }

      Console.WriteLine("Done: " + i);
    }

    static async Task DoWithSemaphoreAsync(int i)
    {
      await s.WaitAsync();

      try
      {
        // mutate shared state atomically
        await Task.Delay(100);
      }
      finally
      {
        s.Release();
      }

      Console.WriteLine("Done (async): " + i);
    }
  }
}

When running the code and we only use "sync" tasks, the program completes after about 3 seconds.

When running the code and we only use "async" tasks, the program completes after about 3 seconds.

When running the code and we use mixed tasks, the program takes much longer to terminate (it varies a bit).

When you take a look at the source code of SemaphoreSlim, you can see that they are using a TaskNode class that is just a derived Task<> constructed with parameter TaskCreationOptions.RunContinuationsAsynchronously.
As soon as async waiters are in the game (see line 358 of SemaphoreSlim), all follow-up sync waiters are also put in the queue of async waiters.
On the other side, of we only have sync waiters (and no async ones), a pulse-wait approach is used, which does not need a thread pool.
And if we only have async waiters, the problem does not come into play, since we do not lock a task; instead we await it, and when awaited, the underlying thread goes back to the tread pool.
So, I don't think that using SemaphoreSlim solves the issue.
@StephenCleary You mentioned that you have a final solution in mind. I'm looking forward for it and a little bit curious what kind of solution it is.

@StephenCleary How about this approach? Is it safe?

Hey @StephenCleary, I just ran into this problem in production. Until a v5 fix is in place, do you recommend downgrading to v4 or increasing the thread pool minimum thread count? Also, any idea as to when the issue might be resolved in v5?

@tmendez3 Whether or not increasing your thread pool minimum will help depends on your system.
I use AsyncLock mainly as part of a cache-aside implementation to keep multiple consumers from going to remote caches or system-of-record for the same cache key and I call through that code 500M times a day.
It doesn't matter what I set minimum threads to, when using v5 it will sporadically (between a few times a week and a few times a day) use them all up and as many more as it can create before the process gets recycled for being unresponsive. If that start happening on more than 1 of my VMs at a time it's a quick and slippery slope to cascading overload failure.
On v3, everything is peachy, been running this system for years with 99.995% reliability. I haven't really given v4 a shot, so I cannot comment on that.
We do have two key prefixes in our system that can end up calling AsyncLock.Lock() and AsyncLock.LockAsync() from different places on the same AsyncLock object and I haven't yet tested if removing that overlap clears up our issues with v5 or if they persist.

Thanks for that use case @qstarin.
I did de-prioritize this for quite a while due to concerns that fixing this wouldn't actually fix the underlying issue. Specifically, if your code is exhausting the thread pool, sure that would cause a deadlock (technically slow lock) with AsyncEx, but that same underlying problem of thread exhaustion would just cause other asynchronous code to have the same issue (severely delayed, deadlock-like behavior); this is because almost all I/O APIs require a free thread pool thread for completion.
However, I do want to fix this issue.
There are a couple of paths forward. One is the "fully correct" solution outlined above; this would require several consecutive days of work and considerably complicate the implementation. Unfortunately, my opportunity for "several consecutive days of work" on a hobby project isn't great. Historically, I've been able to do the "hard" work on AsyncEx at the Microsoft MVP conference. But 2020's MVP conference was virtual so I lost that opportunity, and next year's conference is also virtual.
The other solution is to essentially take the AsyncEx 4 solution. This would only require a weekend or so, not an entire week. Technically, this solution is incorrect because it assumes ExecuteSynchronously always executes synchronously. This is true the vast majority of the time but could be false if the stack is too deep at the point the lock is released. However, I think this is an acceptable drawback; in all the years of AsyncEx, no one has actually reported that as a real production issue. On the other hand, I have suspicions that the stack overflow detection heuristic (which never worked that well on .NET Framework) is more sensitive on .NET Core - and if that is true - this situation would happen more commonly on .NET Core. But I'm guessing that it wouldn't trigger this scenario often enough to cause this issue (which always happens with the current v5).
Well, there are no obviously correct answers. :)  But I think that in the interest of resolving this issue for AsyncEx v6 and above (the fix would require a major version rev), I'm going to take a weekend (sometime...) and restore the v4-style completion behavior.

@milspiir Not that I've seen, and I'm still on v3.
I did remove any and all mixed sync/async locking on any AsyncLock objects and that made no difference in the deadlocking behavior observed in v5. I also tested v4 and found similar sporadic deadlocking.
A simple SemaphoreSlim lock in place of AsyncLock does not appear to deadlock, but performs quite badly. v3 appears to perform noticeably better in both uncontested and contested (especially contested) use than v4 & v5 - all of which perform vastly better than a simple SemaphoreSlim.

Technically, this solution is incorrect because it assumes ExecuteSynchronously always executes synchronously. This is true the vast majority of the time but could be false if the stack is too deep at the point the lock is released. However, I think this is an acceptable drawback; in all the years of AsyncEx, no one has actually reported that as a real production issue.

fwiw, @StephenCleary, I've had StackOverflowExceptions trigger with the default v3 behavior of resuming TaskCompletionSource's synchronously - it happens when I have close to 300 or more tasks waiting on the same lock object. In those cases, providing AsyncLock with an implementation of IAsyncWaitQueue that creates the TaskCompletionSource with the TaskCreationOptions.RunContinuationsAsynchronously option, but is otherwise the same as the wait queue in v3 of the library, avoids the deadlock - but also performs more poorly than the included implementation that continues synchronously.

I'm still planning to eventually fix this, and I still haven't had time. As noted previously, my primary hacking time is during conferences, which haven't happened since covid hit.

As an aside, we just got bit by this. Removing a background task (started with Task.Factory.StartNew()) 'fixes' the issue, although obviously has some significant drawbacks.

Hello Stephen. I'm currently being hit by this (I think). Hope you get a conference soon :-)


Fix problem bug in MobileBert with vectorization enable.

It looks like this improves the performance of MobileNetV2 on S20...
https://mako.dev/run?run_key=6441876564475904&~cpu=1&~vmla=1&~vlk=1
@antiagainst could you help verify if ToT does have 15ms performance? I'm hitting some weirdness on S20 in the lab, and I don't have one on local side.

I tested on S10 and I feel that there are issues in benchmarking infrastructure...

The variance is bug. There are 8 iterations in one benchmark and the range is 64 ms ~ 90 ms. We probably want to ping GPU frequency for lab phones.
I still feel that there is a performance improvement, so it'd be good if you can help check it.


NoMethodError - undefined method `refinery_help_tag' for #<#Class:0x000000059a0830:0x00000005981a70>:

Hi,
I've followed the readme doc and after that when I'm starting my server and access the page where I've added the
<%= render 'seo_meta/form', form: f %>
its giving me error for
NoMethodError - undefined method refinery_help_tag' for #<#Class:0x000000059a0830:0x00000005981a70>:`
As I checked in this gem we have no where define method 'refinery_help_tag'
Let me know how can I resolve this issue.
Thanks in advance .

Hi - you're right! We don't define that helper.. and it's something from Refinery that we never removed when extracting to this gem.

Here is the implementation in Refinery
But probably we should just remove it from this gem?

Fixed with #32


Unknown template tag 'else'

Reraising an issue from Sourcery repository: https://github.com/krzysztofzablocki/Sourcery/issues/735
With the very latest release of Sourcery, my templates (that were 100% working) are now completely broken.
Can you please help me with understanding what is incorrect in my template?

I've encountered the same error when a UTF8 template contained the character "Combining Diaeresis" at some point before the tag.


remedy for eh_personality error

If one happens to have a Cargo.toml profile set to unwinding panics, a language item required, but not found: 'eh_personality' error will result. PR #42 adds a brief note explaining how to resolve the error.

It happened to me as well but it was caused by not setting a proper target
[build]
target = "thumbv7m-none-eabi"

in .cargo/config or via command-line options.

[build]
target = "thumbv7m-none-eabi"

It should be:
[build]
target = "thumbv7em-none-eabihf"


Move forc's LSP support into a dedicated forc-lsp plugin crate

NOTE: This PR is Based on #1178 - we should land that first. I've opened this draft as a working demonstration of plugin support implemented in #1178.
This creates a dedicated forc-lsp plugin crate. With forc's new
plugin support, having this plugin installed and available via PATH
enables the original behaviour of starting the sway language server via
forc lsp <args>.
This also acts as a local test for forc plugin support and as a simple
example of how to implement a forc plugin.
The old lsp and forc_lsp modules have been removed from forc in
favour of this new forc-lsp plugin.

See this comment for a demonstration of how to install and use this forc plugin.


Cowgol cannot detect EOF character on Unix?

Hello.
I have been running Cowgol on OpenBSD for a while, preparing to create a cowgol package with all the different permutations of native and cross compiler. It works great on OpenBSD. I have been able to create native programs with it as well as programs for all the different CPU and platform combinations that get built by the standard ninja build.
One thing I noticed is that Cowgol does not seem able to detect the standard Unix EOF character. If I'm reading the code correctly, the FCB struct holds a sliding window of the current file, including the current character, but that buffer is of uint8's, whereas (modern) Unix uses -1 as its EOF character. Because you always zero out the window containing the currently read in piece of the open file, you can test for 0 as an EOF character. Fine if you're working with text files. Less fine if you're working with binary files, such as if you're writing a hexdump utility in Cowgol: https://github.com/ibara/cowgol-utilities/blob/main/hexdump.cow
As you can see, I did come up with a workaround. But that workaround is both surprising to the programmer and probably not something that should be exposed by the average program (use of the @asm semantics to hook into libc functions).
Wondering if I missed something that would have made detecting EOF on Unix easier. If not, wondering if it is desirable for me to go about figuring out how to make Unix and CP/M and DOS and the rest to all be happy with EOF detection.
Thanks!

Yes, that's correct. The FCB API is a bit bodged together (and some of the implementations are just plain wrong and I need to fix them; don't trust FCBSeek for now). The way it's supposed to work is: you can seek and read anywhere in the file from 0 to FCBExt. Inside that range you get data. Outside that range you get 0. To determine where the end of the file is, you need to use FCBExt to look at the current file position. FCBExt is guaranteed to be at or after the last byte written to the file.
You can blame CP/M and Acorn MOS for this, as CP/M doesn't track the length of files beyond how many sectors there are, and MOS has really weird EOF behaviour when reading blocks. Plus, FCBs always refer to files, which have a fixed size, unlike Unix file descriptors which are streams. It's not very satisfactory but it is at least pretty simple. (It'll be simpler when I fix FCBSeek...) Also the buffering behaviour is... poor... and really needs to be replaced with something better.
Also: I'm glad it works on OpenBSD! I don't have one of those, or at least, I don't think I do, and github's CI only supports Linux. There are lots of gotchas when making things work outside the Linux world.

Sounds good. I'll wait for the fixes and between then and now I'll just make slightly different versions of the utility for different platforms as I need them.

You shouldn't need to, actually. Provided you start at the beginning and read through to the end, which the hex dumper is, it should work fine. You don't need FileLength() as FCBExt() should give you the same result, although most platforms appear to round it up to the nearest block --- not sure why I did that.
BTW: you're actually writing code in Cowgol? Gosh. I'm not sure how I feel about that... also, I've just added an extremely bad ARM backend.

I see what you mean. I will try that out later.
And I've only written that hex dumper so far. I enjoy one-person languages.
And I saw about the ARM backend. I explicitly turn off the 80386 and arm native toolchains (I leave their cross compilers available) because the 80386 backend does not produce assembly that passes OpenBSD's strict checks (forbidden relocations). I have not tried the arm backend yet. Can get you a log of the 80386 backend later if you're interested.

You're right. FCBExt got me what I needed. It does round up to the nearest block on Unix but that's fine with me. Thanks again!

Re OpenBSD: yes, please. I found an old machine and installed OpenBSD on it, but of course Cowgol only generates Linux binaries. If you have something which should (but doesn't) generate OpenBSD binaries that'd be good to have.

FWIW, I've rewritten the file I/O stuff so that there's proper buffering and byte-accurate file lengths on platform which support it. I'd like to keep the same EOF handling, though, as it makes lots of things easier; but I think there are still some bugs here.

I think that's fine. It works for me.
(Feel free to close this issue.)


feat: initial WIP API

:tada: This PR is included in version 1.0.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Specifying the install folder

to omit the license.txt

This solves #5105, thanks.

This solves #5105, thanks.


RqGreedy

We need to create new request decorator RqGreedy to consume the entire body and keep it in memory.

@rultor release, tag is 0.9.8

@rultor release, tag is 0.9.8

@yegor256 OK, I will release it now. Please check the progress here

@rultor release, tag is 0.9.8

@yegor256 Done! FYI, the full log is here (took me 13min)


FR: Create link to the drafts and authors.

^

Just a link to each proposal’s repo would be okay, IMHO. The author info can be viewed over there anyway.

Yeah that's sounds good, will have to write a tiny script to scrape them all 🎯


Cleanup Cask::Caskroom::casks

This PR uses the new /api/cask-source.json endpoint to make loading casks using the API must faster. This is super noticeable in brew outdated when you have casks installed. Now, there's only one file to download that only needs to update whenever there's a new version available.
This PR depends on https://github.com/Homebrew/formulae.brew.sh/pull/654

Review period will end on 2022-06-20 at 20:59:03 UTC.

Okay, I've removed the API part of this PR since, for now at least, we're going to do this a different way. However, I left the Cask::Caskroom::casks changes since I think those still make sense. However, I still would like to get a second opinion on these changes before merging.

Review period ended.


kernel/os: Fix issue that causes WDOG reset reason to be lost

In the default irq handler, hal_watchdog_tickle() was called before doing a core dump but on Dialog da1469x this causes the reset reason   to be lost, and reboot log was recording the reset reason as HAL_RESET_SOFT instead of HAL_RESET_WDOG.
The issue is fixed by calling hal_watchdog_disable() instead of hal_watchdog_tickle() before doing a core dump.
This PR also adds hal_watchdog_disable() to the HAL API for all MCUs (for now it is implemented only for Dialog da1469x and CMAC).

I think this is based off of apache/master. Maybe best to cherry-pick your commit on master-steam.

I think this is based off of apache/master. Maybe best to cherry-pick your commit on master-steam.

I accidentally used the wrong branch. I'll close this and reopen a PR with the correct branch.


Remove MongoDB

I think that this starter should be made simpler without including MongoDb upfront and have a generator.
As a starter I am looking for guidance on how to setup Node+Express+Typescrit but not Mongo.
More important are things like linter and how to install typedefintions and maybe connect to an external API.

Thanks Oscar, different people are coming looking for different things - Given that there's a focus on building a node API here, I think conforming to the MEAN stack makes a lot of sense for this template.

As a starter template for people coming new to the language you should make it simpler and more accessible, maybe by using an embedded mongo so that people new should not go about also setup mongo.

I think Microsoft should provide more starter projects for TypeScript. I'd love to find an official template for simple TS library or a CLI application.

I'd recommend looking at tsdx  for that - https://github.com/palmerhq/tsdx

Yes, please remove MongoDB. Starter project should be like template for new project.

If you check branch "noDatabase" of this template MongoDB is removed.

I agree, it's not a great "starter" when it forces you to use a database, this boilerplate has got very bloated from what it used to be.

Can the starter move toward feature flags and modules - that would allow the features to grow separate from but inclusive to the starter.

The complexity of maintaining the mongo db integration might be one of the reasons holding back the maintenance of this project. Currently TypeScript-Node-Starter is falling way behind in upgrading the packages in package.json. See: https://github.com/microsoft/TypeScript-Node-Starter/issues/305

Maybe at least, just replace MongoDB with MySQL;
No one did outlaw developing accounting App with Node.js ;-)
Like your fork: https://github.com/akitoeki/TypeScript-Express-MySQL-Starter


Eijebong can't ssh in to build machines

Troubleshooting:

Was he previously able to SSH in, between when his key was added and when this bug was filed? If so, when did the problem start?
Is he using the SSH key added at https://github.com/servo/saltfs/blob/master/admin/files/ssh/eijebong.pub?
Is he ssh-ing as root or Administrator at the host?
Does the problem persist after the time of this comment?

cc https://github.com/servo/saltfs/pull/836

It occurs to me that I only highstated master, not the rest of the build machines, and we never tested sshing to servo-master1.

Well anyways we have a new key that we know will work, and I'm highstating the relevant hosts now. Good catch on noticing that though!


[FEATURE REQ] Add a TryGetSecret method

Library name
Azure.Security.KeyVault.Secrets
Please describe the feature.
Currently, to recover secrets, there are only methods that return an error if it is not possible. (GetSecret, GetSecretAsync...).
However, this ends up generating an unwanted error. It would be nice to have TryGetSecret and TryGetSecretAsync. Which would return a bool if it managed to recover the secret (returning the value with out).
All the problem start here:
private Response SendRequest(Request request, CancellationToken cancellationToken)
{
    Response response = _pipeline.SendRequest(request, cancellationToken);

    switch (response.Status)
    {
        case 200:
        case 201:
        case 202:
        case 204:
            return response;
        default:
            throw Diagnostics.CreateRequestFailedException(response);
    }
}

It would be another one like:
private bool TrySendRequest(Request request, CancellationToken cancellationToken, out Response response)
{
    Response response = _pipeline.SendRequest(request, cancellationToken);

    switch (response.Status)
    {
        case 200:
        case 201:
        case 202:
        case 204:
            return true;
        default:
            return false;
    }
}

With TrySendRequest it will be possible to build all the others Try'methods.

Thank you for your feedback.  Tagging and routing to the team member best able to assist.

Duplicate of #25125


Doc: Review workflow for new users

New users need a good on-boarding experience.  Opening an issue in support of that.
A couple scenarios for validation/enhancement:
1 - A user is familiar with using protobufs, clones, builds, runs hello world example, and starts crafting their own protobufs in tonic.
2 - A user is looking for a client/server architecture and is un-familar with with the stack.
3 - A user familiar with tokio/tower but new to grpc.

👍 love this. I'm not sure though how to approach this? Would it make sense to provide multiple guides?

Multiple guides would be confusing.
We can log individual issues in doc or group them in one.
So, 20+ - like:
"Tonic-build Readme should not  highlight version number in red  "https://github.com/hyperium/tonic/tree/master/tonic-build"

As a new user with (a little bit) of experience with Rust and gRPC, I had some trouble getting an example running without cloning this repo. I tried following along with the HelloWorld example on the README, but there weren't any commands specifying how to run. The Cargo.toml example didn't include the [[bin]] for client or server.
Personally I believe the on-boarding experience could be improved, I'm happy to make contributions when I can.

@RetWolf hey! So we have an in progress guide #21, would you be able to check it out to see if that would have improved your experience? This is 100% something I want to work on :)

@LucioFranco I believe that tutorial would have improved my experience, and would be a good in-depth dive into some of the advanced features of the library and ecosystem. Would you be interested in a PR which includes a simple tutorial to take new users from scratch to a running HelloWorld server+client? I think it would be beneficial to have a tutorial that just shows the basics first, and then maybe have an advanced tutorial help illustrate the full capabilities of the library.

@RetWolf I would absolutely love that! I think that is a great idea! And thank you for the feedback!

This has been done.

@LucioFranco I just had a bad experience in getting started with tonic, the hello world example didn't mention about out_dir, I was looking for generated files for hours, then after checking issues I found #62 which mentioned about out_dir.

@xsoheilalizadeh if I may ask what was the reason to need to look at the generated code?


Added Text Quick Replies

Hello! I added text quick replies to my version. I have tested it and it works for my situation. I believe there may be some modifications to make it cleaner.
But basically it takes in a list of replies (which the user presses) in response to a text message. There is an optional payload list for the developer and if the developer decides to not use a payload, then the payload is simply the reply.

@davidchua

Can I rework this feature?

Hello, Instead of making an API for this purpose alone I decided to make an API that would allow users manually add their payload themselves.
Eradicating issues that may arise with making the API satisfy everyone's individual use case.
You can check it out here (https://github.com/davidchua/pymessenger/pull/85)


Canary doesn't load

https://main.nft-gallery-5ci.pages.dev/

just middle of reporting this issue it started working 👀
super strange cloudflare pages, strange.

ok, doesn't load on, investigating
https://canary.kodadot.xyz

last working build

https://81d711bb.nft-gallery-5ci.pages.dev/
https://github.com/kodadot/nft-gallery/commit/247c096ca9d2da949419632e891b082d1313be81

lol beta builds well - https://1d45364a.nft-gallery-5ci.pages.dev/

Seems Cloudflare has incositent builds and it's not first time 👀
All builds has ✅  and did not worked 😅

Working so closing


FAQ Entry suggestion: wire up re-com model atoms with your re-frame handlers

Handler-induced App DB state changes don't update my re-com atom models, help!
Question
Problem: You're using the excellent re-com widgets and have opted for having an interactive component (such as a slider) and wisely chose to have its state backed by an atom. You are wondering how to update said atom from your handlers. So you ask yourself: how to do it?
Answer
Keep calm and try to take over the world one line of clojurescript at a time.
Example: Think about a media player using md-icon-buttons. There's a slider when a song is playing. If you hit fast forward, or skip to beginning, you want the slider to update. You chose an atom as the slider model so that playback code etc. doesn't need to worry about the view, as long as the atom is updated.
;; First, reflect and notice your view wants to tell re-frame that it needs help.
;; Secondly, you wisely grouped your view-related control messages in a way so that they
;; wrap easily (i.e., can be serviced by a single handler).
(re-frame/register-handler
  :player-controls
  (fn player-controls-handler [db [_ control & args ]]
   ; Then, combine these things:
   ; (1) handle sync requests
   ; (e) establish db-comparer to update synced models
   ; (pi) use it
   ; we begin with (e) :
    (let [; state setup for watching paths in db to signal updates to atoms functionality
          now-values (into {} (map (fn path-to-value [[path models]] [path (get-in db path)]) (get-in db [:plr :synced]))) ; get current values
          signaling (fn [new-db]                                              ; fn to perform signaling to atoms if necessary
                      (doseq [[path models] (get-in new-db [:plr :synced])]   ; foreach [path => [model, model, ...]] to
                        (let [new-value (get-in new-db path)]                 ; get new value
                          (when (not= new-value (get-in now-values path))     ; compare to old, if different
                            (doseq [model models]                             ; walk through models to ..
                              (reset! model new-value)))))                    ; set them to the new value
                      new-db)                                                 ; return new db so we can wrap our handlers below
          ]

 (condp = control ; dispatch :player-control events
        ; (1) handle sync storage
        ; just stuff it into the App DB. We don't need other state storage.
        :needs-sync (let [[model path] args
                          current-syncs (get-in db [:plr :synced])
                          subscribed (if (get-in current-syncs [path])
                                       (update-in current-syncs [path] conj model)
                                       (assoc-in current-syncs [path] [model]))
                          ]
                      (assoc-in db [:plr :synced] subscribed))
        ; handle real player controls
        ; use (pi) the db compare and model updater (signaling)
        :skip-previous (signaling (db-adjusting-impl skip-prev-computation))
        :replay-30 (signaling (db-adjusting-impl replay-30-computation))
        :replay-10 (signaling (db-adjusting-impl replay-10-computation))
        :replay-5 (signaling (db-adjusting-impl replay-5-computation))
        :fast-rewind (signaling (db-adjusting-impl fast-rewind-computation))
        :fast-forward (signaling (db-adjusting-impl fast-forward-computation))
        :forward-5 (signaling (db-adjusting-impl forward-5-computation))
        :forward-10 (signaling (db-adjusting-impl forward-10-computation))
        :forward-30 (signaling (db-adjusting-impl forward-30-computation))
        :skip-next (signaling (db-adjusting-impl skip-next-computation))))))

In the view you'd then use
(re-frame/dispatch-sync [:player-controls :needs-sync model-atom [:path :into :db]])

(sync so the atom gets initialized with the value from the DB right away)
Your "model" (i.e. the implementing handler) would store the real naked value for the use inside the model-atom (i.e., for use by the view / re-com widget) inside the app-db under the path the view component expects to find it ([:path :into :db])
(in db-adjusting-impl, for example)
(defn db-adjusting-impl [db callback]
  (update-in db [:path :into :db] callback))

Note that this could probably be wrapped in a middleware for event handlers that looks for a 2nd key :needs-sync in there; does the (signaling) setup as above and then benefit? Anyways, what do you think of the solution, does it fit well into the re-frame way of thinking (feels a bit cheaty I admit, but I've used a subscription for a re-com slider data model before and it's no fun)?

Now I'm aware of the mantra, don't wire in state, but let react redraw your UI upon user interaction and make it look like it's actually updating state destructively..  But this is motivated from using an interactive component which controls data being displayed and, naturally, its own display, the latter of which you preferrably want to redraw "one cycle earlier" than the DOM of the view the component generates. Say you have a slider that controls selection of one of .. 20k values. When you're rushing through the length of the slider, you want it to update with higher frequency than the view. This is sorta achieved already by creating the view by dispatching (not -sync) with re-frame and having it defer the generation of the view until the next cycle.
I had the impression that by backing such a slider with a reagent/atom instead of using the value from a subscription, the updates were running more smoothly with violent entry value changes, which is why I came up with the crutch above.

Any updates or should it be closed?

I've read this issue a couple of times now and I don't really understand what is required. @danielcompton marked it with a "docs" tag at one point, so perhaps he understood and thought better docs was all that was needed?
I’m currently spring cleaning issues, and this one appears to be very old, and has atrophied without a clear path forward, including what better docs might be necessary,  so I'm going to close it.


Add actionMaxHeight

So when a list row is too high can control the appearance of the swipe actions

lol


Water Purifier crafting

General information:
Project issue is for:
Dev profile water filters on BE 3.8.0
Expected result:
an increased production speed of purified water.
Actual result:
the filters last for 40 seconds but the water still takes 4 hours to craft
How to reproduce:

use either fir or non fir waterfilters to craft purified water

Attachments

LogOutput.log (8 KiB)
server-2024-02-02.log.gz (160 KiB)
2024-02-03[00-06]_1.2, 0.8, -3.4_0.0, 0.4, 0.0, 0.9 (0).png (1054 KiB)

Originally written by josiahswims

fixed and tested with normal and dev profile with https://dev.sp-tarkov.com/SPT-AKI/Server/commit/27927dd456302dcc210e87d261347fcbe1e830f7

Originally written by CWX


为什么指定gpu只能在0,1卡，换成2,3卡就卡住了？

Describe the bug
Please provide a clear and concise description of what the bug is. If applicable, add screenshots to help explain your problem, especially for visualization related problems.

。。。


Bug fix : kaggle API credential import failed in text classification with tf-hub on kaggle notebook

In the function get_kaggle_credentials when we were writing to the token_file, uploaded['kaggle.json'] returned byte code. In the original notebook, we didn't open the file in binary mode so we didn't write the credentials from the uploaded kaggle.json file to the destination file and the import was showing error that it couldn't find the username in the token_file.
So we just had to add open(token_file,"wb") to open the file in binary mode. After the fix the notebook works as expected. Here's a copy notebook with the mini fix in action.
https://colab.research.google.com/drive/1qTiQydX0xvdwD17I0ZtJOCAHXPwPesTs
Fixed code :
import os

# Upload the API token.
def get_kaggle_credentials():
  token_dir = os.path.join(os.path.expanduser("~"),".kaggle")
  token_file = os.path.join(token_dir, "kaggle.json")
 .......
  uploaded = files.upload()
  with open(token_file, "wb") as f:
     f.write(uploaded["kaggle.json"])
  os.chmod(token_file, 600)

get_kaggle_credentials()
# Note: Only import kaggle after adding the credentials.
import kaggle

I signed it!

I am not sure if reading this correctly, but does the commit move the indentation left by 1 space? ?>Could you please confirm and if yes, move it back, so that we can get a readable diff?

I only changed one line, but removed the jupyter checkpoints when committing. I'm not sure why the model diff is that large. I opened the jupyter notebook in windows, could this be the issue?
This is the forked versions notebook, in github and in my local machine the rendering is the same as before  :
https://github.com/TahsinMayeesha/hub/blob/master/examples/colab/text_classification_with_tf_hub_on_kaggle.ipynb

@vbardiovskyg I reverted the previous commit and ended up only modifying one line, can you please check? I've not been able to solve where the real issue was though that made such a large diff. I think it was because I didn't removed kernel outputs before committing.

Thanks for the change, I added two more comments that would make the colab a bit cleaner and easier to use, since you are already working on improving it.

I'll get to it.

Thanks for the fixes, but now the indentation is moved to the left again. Is that your environment doing that?

Thanks for the fixes, but now the indentation is moved to the left again. Is that your environment doing that?

In the first commit after I deleted the installation cell the other cells shifted up and created a large diff, but the second one seemed okay. It's probably my environment, any idea what I should do to fix it? I've set git core.autocrlf to true as advised here. https://help.github.com/en/articles/dealing-with-line-endings#global-settings-for-line-endings

Not sure what you are using for editing, but this is what I would do:

To change the colab, open the colab in colab.research.com.
Make my edits.
Download the file to local machine and replace the raw file in the local git branch on my machine.
Check for any unintended diffs with "git diff origin"

I'm using jupyter notebook with anaconda.

Can you please remove the last two cells that were added?

Can you please remove the last two cells that were added?

The one's with confusion matrix and the prediction submission? Those were in the original file though.

Submission cell was there as text. Now it is there as text and then again as code and then there is a new code cell. Or at least that's what "view file" shows me.

Submission cell was there as text. Now it is there as text and then again as code and then there is a new code cell. Or at least that's what "view file" shows me.

Oh yeah, sorry, removing those.

Looks good now, thanks for the change!

Looks good now, thanks for the change!

thanks, can we merge it now? Also thanks for the fix about the indentation issue.

Merged into master in a79a81d6cff7aada1f642978e022aadad35fd8aa.


Corrected win32 bug that resulted in corrupted docx files

Force writing back of the string using binary mode to prevent docx corruption.

Great! thanks :)


MRG: Faster raw plotting with decim

This should speed up our raw plotting when low-passing is done.
The same thing can be done with Epochs once this is tested / works.

cc @jaeilepp

Done

thx @Eric89GXL
@jaeilepp it will be great if you can do this with Epochs.plot now


Mailserver behind HAProxy

Subject

[ ] I would like to contribute to the project (code, documentation, advocacy, integration, ...)
[ ] I would like some help for integrating this container with another service (rainloop, PostFWD, ...)
[X] I would like to configure a not documented mail server use case
[ ] I would like some feedback concerning a use case
[X] I have questions about TLS/SSL/STARTTLS/OpenSSL
[ ] Other

Description
In my Setup is a HAProxy before my Docker-Swarm-Cluster. I want to integrate the mailserver, but dont wont to expose the Ports directly from the Swarm-Nodes. Also my HAProxy takes care of the SSL-Certificates. So my Idea is following:
HAProxy (TCP-Ports 993 and 465, with SSL-Offloading) -> Swarm-Node (TCP-Ports 143 and 587).
Is this possible?
My configs are following:
HAProxy
# Floating IP. SMTP
listen lb_smtp_465
        bind xxx:465 ssl crt /media/shared/ssl/
        mode tcp

        timeout client 30000

        # use unencrypted port 587. haproxy make ssl
        server email_l0004 <IP_ADDRESS>:587 check

# Floating IP. IMAP
listen lb_imap_993
        bind xxx:993 ssl crt /media/shared/ssl/
        mode tcp

        timeout client 30000

        # use unencrypted port 143. haproxy make ssl
        server email_l0004 <IP_ADDRESS>:143 check

Docker:
Env-File:
ENABLE_SPAMASSASSIN=1
ENABLE_CLAMAV=1
ENABLE_POSTGREY=1
ONE_DIR=1
OVERRIDE_HOSTNAME=mail.xxx
OVERRIDE_DOMAINNAME=mail.xxx
POSTMASTER_ADDRESS=admin@xxx
SSL_TYPE=empty

Compose:
  mail:
    image: tvial/docker-mailserver:latest
    logging:
      driver: loki
      options:
        loki-url: "https://xxxx/loki/api/v1/push"
    ports:
      # unencrpyted esmtp
      - target: 587
        published: 587
        protocol: tcp
        mode: host
      # unencrpyted imap
      - target: 143
        published: 143
        protocol: tcp
        mode: host
    volumes:
      - /media/shared/docker/mailserver/maildata:/var/mail
      - /media/shared/docker/mailserver/mailstate:/var/mail-state
      - /media/shared/docker/mailserver/config:/tmp/docker-mailserver
    env_file: /media/shared/configs/swarm/mailserver/docker-mailserver.env
    networks:
      - default
    deploy:
      replicas: 1
      placement:
        constraints:
          - node.labels.mail == 1

Thanks for helping!

It will be odd as I think 587 will insist on STARTTLS and the client has already connected with TLS on port 465. I think it makes more sense to let haproxy connect to the encrypted ports. It will be a little bit slower but if you don't want to configure proper TLS in the mail server you can make haproxy trust the self-signed certs.

Thanks for the tip, i will try it.

It works now. Here are my configs:
HAProxy
# Floating IP. EMAIL
listen lb_smtp_465
        bind xxx:465
        mode tcp
        option tcplog

        server email_l0004 <IP_ADDRESS>:465 send-proxy

# Floating IP. SMTP 25
listen lb_smtp_25
        bind xxx:25
        mode tcp
        option tcplog

        server email_l0004 <IP_ADDRESS>:25 send-proxy

# Floating IP Email IMAP
listen lb_imap_993
        bind xxx:993
        mode tcp
        option tcplog

        server email_l0004 <IP_ADDRESS>:10993 send-proxy-v2

Docker-Compose:
services:
  mail:
    image: tvial/docker-mailserver:latest
    logging:
      driver: loki
    ports:
      - target: 25
        published: 25
        protocol: tcp
        mode: host
      - target: 465
        published: 465
        protocol: tcp
        mode: host
      - target: 10993
        published: 10993
        protocol: tcp
        mode: host
    volumes:
      - /media/shared/docker/mailserver/maildata:/var/mail
      - /media/shared/docker/mailserver/mailstate:/var/mail-state
      - /media/shared/docker/mailserver/config:/tmp/docker-mailserver
      - /media/shared/configs/swarm/mailserver/config/dovecot-haproxy.conf:/etc/dovecot/conf.d/haproxy.conf
      - /media/shared/configs/swarm/mailserver/certs/fullchain.pem:/etc/letsencrypt/live/mail.fuchs-informatik.de/fullchain.pem
      - /media/shared/configs/swarm/mailserver/certs/privkey.pem:/etc/letsencrypt/live/mail.fuchs-informatik.de/privkey.pem
    env_file: /media/shared/configs/swarm/mailserver/docker-mailserver.env
    networks:
      - default
    deploy:
      replicas: 1
      placement:
        constraints:
          - node.labels.mail == 1

Env-File:
ENABLE_SPAMASSASSIN=1
SPAMASSASSIN_SPAM_TO_INBOX=1
ENABLE_CLAMAV=1
ENABLE_POSTGREY=1
ONE_DIR=1
OVERRIDE_HOSTNAME=mail.fuchs-informatik.de
<EMAIL_ADDRESS>SSL_TYPE=letsencrypt

Custom Dovecot:
haproxy_timeout = 5 secs
haproxy_trusted_networks = <IP_ADDRESS> <IP_ADDRESS>
service imap-login {
  inet_listener imaps {
    haproxy = yes
    ssl = yes
    port = 10993
  }
}

Postfix-main.cf
postscreen_upstream_proxy_protocol = haproxy
postfix-master.cf
#https://github.com/tomav/docker-mailserver/wiki/Using-in-Kubernetes
submission/inet/smtpd_upstream_proxy_protocol=haproxy
smtps/inet/smtpd_upstream_proxy_protocol=haproxy


Unable to import Many-to-one LSTM Keras model

Issue Description
Importing an LSTM model using Keras (Functional API) v2.3.1 with Tensorflow v2.1.0. I am using the configuration return_sequences=False for my LSTM layer. I am importing the model using:
ComputationGraph graph = KerasModelImport.importKerasModelAndWeights(model,true);
I get the following stack trace:
https://gist.github.com/YusufuShehu/19cf57ccc908ccd69e6969d9e471cfc4
I have seen in previous issues that this may have been resolved. Also in 1.0.0-alpha, it is explicitly said this bug is fixed.
How can I fix this issue?
Version Information

Deeplearning4j 1.0.0-beta6
Platform information OSX

Additional Information
POM: https://gist.github.com/YusufuShehu/24cf252b5dde5049223ccb979af2b932

Closing since we support tf.keras now. Open a new issue if something similar comes up.


[MAID-2835] chore/ci: update scripts to Rust stable 1.26.2

r? @canndrew
(maidsafe_highfive has picked a reviewer for you, use r? to override)


Move to published version of Limbdark

Remove Limbdark.jl submodule from repository
Add the published version of Limbdark.jl as dependency
Fix some misc. imports.

Documentation CI only fails on the 'Pull Request' side...


added docubro

Hello @ai-collection thanks for the great repo. I am adding one app I have been working on to the chatbots sections 😄 (my twitter handle is @kanekotic)

Thanks! Looks awesome!


Apply correct floor map image

Issue

close #688

Overview (Required)

Continue from #617
Applies the correct floor map image to the map screen.
Removes the bottom app bar as a result of the discussion at https://github.com/DroidKaigi/conference-app-2022/issues/177#issuecomment-1254882945.

Links

Figma

Screenshot

Before
After

Thank you for addressing high priority task!


Add summaries for Jobs.

Add a summary for the job to make it easier to understand.
Besides, as for CombatRole, do you think it's a better idea to make it a general role?

Thank you!

Besides, as for CombatRole, do you think it's a better idea to make it a general role?

That enum is widely used so it's better to just stay as it is or a lot of things will break


Add vcpkg installation instructions

sfml  is available as a port in vcpkg, a C++ library manager that simplifies installation for sfml and other project dependencies. Documenting the install process here will help users get started by providing a single set of commands to build sfml, ready to be included in their projects.
We also test whether our library ports build in various configurations (dynamic, static) on various platforms (OSX, Linux, Windows: x86, x64) to keep a wide coverage for users.
I'm a maintainer for vcpkg, and here is what the port script looks like We try to keep the library maintained as close as possible to the original library.
I try to add vcpkg installation instructions but I couldn't find the related docs in GitHub except for on https://www.sfml-dev.org/tutorials/2.5/ page.
Could you please help add the following contents to this port?
Installing and building sfml via vcpkg
You can download and install sfml using the vcpkg dependency manager:
 git clone https://github.com/Microsoft/vcpkg.git
 cd vcpkg
 ./bootstrap-vcpkg.sh
 ./vcpkg integrate install
 vcpkg install sfml

The sfml port in vcpkg is kept up to date by Microsoft team members and community contributors. If the version is out of date, please create an issue or pull request on the vcpkg repository.
Thanks.

Similar as I mentioned on the SFML-Website repository recently.

My plan so far was to have a new setup tutorial that shows different options with different package managers (vcpkg, conan, conda, etc).

I think it's best to move this to the existing SFML-Website issue. Also feel free to provide a PR on said repository, but keep in mind that it shouldn't just be specific to the vcpkg package manager. 🙂

Thanks for your update and suggestion.


Transform to ES5 before publishing to npm

If I install the dep from npm it still has ES6 syntax, causing webpack to fail as it expects all node_modules to be vanilla JS because you usually want to exclude those from being transformed by the 6to5-loader
{ test: /(\.js|\.jsx)$/, loaders: ['6to5-loader', 'jsx-loader?harmony'], exclude: /node_modules/ }

What do you think? Is there another way to do it?

yeah, I need to spend some time making the repo friendlier, I just need a pre-publish hook

done, v0.1.2

:+1: