Hyperlinked sources as generated by the Nix toolchain prepend ../ in absolute paths

Sample bit of bad source from the Persistent Database.Persist.TH hyperlinked docs generated by haddock 2.25.1:
Exp -> Stmt
<a href="../file:///nix/store/3bwbsy0llxxn1pixx3ll02alln56ivxy-ghc-9.0.2-doc/share/doc/ghc/html/libraries/template-haskell-<IP_ADDRESS>/src" class="">NoBindS

It's also the case in other packages such as aeson linking to functions in packages included with ghc. I don't know/remember if it affects links to packages sourced from hackage.
I am guessing that the following code, or code near it, is the cause of the leading ../:
https://github.com/haskell/haddock/blob/bc0f2d6c1bfd331a9426fa9a92288444178267b1/haddock-api/src/Haddock/Backends/Hyperlinker/Renderer.hs#L265-L270
However, setting up a development environment such that I can test it with the Nix builder is running into some bugs in nixpkgs, so I can't proceed any further on figuring this out myself.

Exact repro with aeson:
$ nix-build '<nixpkgs>' -A haskell.packages.ghc922.aeson.doc
/nix/store/nwk37d36j9zjkalxs58qfli9cfa9jvd5-aeson-<IP_ADDRESS>-doc

then go to file:///nix/store/nwk37d36j9zjkalxs58qfli9cfa9jvd5-aeson-<IP_ADDRESS>-doc/share/doc/aeson-<IP_ADDRESS>/html/src/Data.Aeson.Text.html in a browser and TB.singleton is an example of a bad link.

@lf- Hi! I don't personally use Nix so I'm not really sure how to approach this.
We could probably have a heuristic that determines whether or not to insert the ../ if the path starts with file://.
What do you think of that?

That was what I was thinking as well. Detect if it's absolute and go from there. I'm not sure who gives us the file:// URLs (or indeed if we are given them at all; might be some Nix hack), but it's easy enough to detect them and not do the prepend. I have now figured out the setup to test a proposed patch so I might write one.

@lf- Very well. Ping me if you can't find the time, I'll handle it. :)


help

When i put this : buildbattle create name game-lobby game-world 30 6 24 300 30 10 10 10
it’s says - too many arguments given - why?

As the command says there's an extra argument being passed, remove the last number (10). The read me has been updated

Can you give me your discord please i want private plugin?

Doge.#8819


HasRoleAndPermissionContract conflicting with AuthorizableContract

There is a new AuthorizableContract in Laravel 5.1.11 which defines such method as can() that already defined in your HasRoleAndPermissionContract.
So what's the next?
I suggest to rename can() to any other name and publish it as v2.2
Thanks!

Check the PRs.

The merge is not approved yet!

You could always fork mine.

Is it a good option if I use composer?

In Composer add:
"repositories": [
{
"type": "vcs",
"url": "https://github.com/christopherburton/roles"
}
],
and
"bican/roles": "dev-master"


Add xxhash digests to phobos library

Add XXHash digests to phobos library
This patch is motivated by the need to have a much faster alternative to the slow MD5 or SHAx cryptographic digests.
XXHash by itself is no cryptographic hash, but good enough to create suitable checksums and is used e.g. with ZSTD compression.
The patch adds the four digest variants of the XXHash project (see github.com:Cyan4973/xxHash.git) ranging
from 32 to 128 bits bits digests. Both variants for the 64 bit digest (XXH and XXH3) are implemented.
The C sources are ported to D and currently only implements the 'scalar' mode of operation. The further optimisations (SIMD)
are added later. So this ported XXHash digests are probably slower than the original C sources. There is also an experimental
version using the embedded C sources with optimisations, but initial reviewers rejected the idea of embedded more C sources
into Phobos, and argued for porting the C code to D.
The digests results were compared against the outputs of the xxhsum commandline utility manually and match the outputs
of the command line utility.
There are unittests for all variants of XXHash (taken from MD5 sources and digest values were updated accordingly).
The digests can be used with the template API:

XXH_32 hash0;
hash0.start();
hash0.put(cast(ubyte) 0);
auto result = hash0.finish();

XXH_64 hash1;
hash1.start();
hash1.put(cast(ubyte) 0);
auto result = hash1.finish();

XXH3_64 hash2;
hash2.start();
hash2.put(cast(ubyte) 0);
auto result = hash2.finish();

XXH3_128 hash3;
hash3.start();
hash3.put(cast(ubyte) 0);
auto result = hash3.finish();

as well as with the OOP versions:

auto xxh0 = new XXH32Digest();
ubyte[] hash0 = xxh0.digest("abc");

auto xxh1 = new XXH64Digest();
ubyte[] hash1 = xxh1.digest("abc");

auto xxh1 = new XXH3_64Digest();
ubyte[] hash2 = xxh2.digest("abc");

auto xxh2 = new XXH128Digest();
ubyte[] hash3 = xxh3.digest("abc");

There are some extra functions in the ported code (secrets, seeds), which are not yet
implemented publically. These functions will be added later.

Benchmarks:
https://gitlab.vahanus.net/dlang/hashbench.git
$ dub run --compiler=dmd-beta --
Performing "debug" build using dmd-beta for x86_64.
hashbench ~master: building configuration "application"...
Running pre-build commands...
Linking...
Running hashbench
A benchmark utility for the phobos digests.

Build is a0026c2

Time Limit per test is 180
Phobos Digest Test 'test_md5.test_md5' (compiled on May 24 2022)
Average 147.586716 MB/s
Phobos Digest Test 'test_xxh32.test_xxh32' (compiled on May 24 2022)
Average 961.077881 MB/s
Phobos Digest Test 'test_xxh64.test_xxh64' (compiled on May 24 2022)
Average 1938.343140 MB/s
Phobos Digest Test 'test_xxh3_64.test_xxh3_64' (compiled on May 24 2022)
Average 1084.588257 MB/s
Phobos Digest Test 'test_xxh3_128.test_xxh3_128' (compiled on May 24 2022)
Average 1052.687256 MB/s
Phobos Digest Test 'test_murmur32.test_mm32' (compiled on May 24 2022)
Average 334.169739 MB/s
Phobos Digest Test 'test_murmur128.test_mm128' (compiled on May 24 2022)
Average 774.752014 MB/s
Total test duration: 28 secs, 388 ms, 258 μs, and 9 hnsecs

Optimized
$ dub run --compiler=dmd-beta -b=release --
Performing "release" build using dmd-beta for x86_64.
hashbench 0.0.0: building configuration "application"...
Running pre-build commands...
Linking...
Running hashbench
A benchmark utility for the phobos digests.

Build is v0.0.0-0-gd5526bf

Time Limit per test is 180
Phobos Digest Test 'test_md5.test_md5' (compiled on May 24 2022)
Average 162.910431 MB/s
Phobos Digest Test 'test_xxh32.test_xxh32' (compiled on May 24 2022)
Average 945.801086 MB/s
Phobos Digest Test 'test_xxh64.test_xxh64' (compiled on May 24 2022)
Average 1801.930542 MB/s
Phobos Digest Test 'test_xxh3_64.test_xxh3_64' (compiled on May 24 2022)
Average 1074.387695 MB/s
Phobos Digest Test 'test_xxh3_128.test_xxh3_128' (compiled on May 24 2022)
Average 1072.683472 MB/s
Phobos Digest Test 'test_murmur32.test_mm32' (compiled on May 24 2022)
Average 4091.976562 MB/s
Phobos Digest Test 'test_murmur128.test_mm128' (compiled on May 24 2022)
Average 5495.587402 MB/s
Total test duration: 20 secs, 239 ms, 25 μs, and 1 hnsec

Reference benchmark from XXH C Implementation:
Note: XXH3 uses vector code
$ xxhsum -b
xxhsum 0.8.1 by Yann Collet
compiled as 64-bit x86_64 autoVec little endian with GCC 11.2.0
Sample of 100 KB...
 1#XXH32                         :     102400 ->    93288 it/s ( 9110.2 MB/s)
 3#XXH64                         :     102400 ->   135630 it/s (13245.2 MB/s)
 5#XXH3_64b                      :     102400 ->   594488 it/s (58055.5 MB/s)
11#XXH128                        :     102400 ->   591542 it/s (57767.8 MB/s)

Obviously the D variant of XXH does NOT optimize well at the moment.  Especially the XXH3 variants could be much faster using vector commands
For comparition the same benchmarks with embeeded XXH  C sources into Phobos:
Note: Vector Code disabled because of problems on Darwin! XXH3 is scalar code.
$ dub run --compiler=dmd-beta -b release --
Performing "release" build using dmd-beta for x86_64.
hashbench 0.0.0: target for configuration "application" is up to date.
To force a rebuild of up-to-date targets, run again with --force.
Running hashbench
A benchmark utility for the phobos digests.

Build is v0.0.0-0-gd5526bf

Time Limit per test is 180
Phobos Digest Test 'test_md5.test_md5' (compiled on May 25 2022)
Average 159.477325 MB/s
Phobos Digest Test 'test_xxh32.test_xxh32' (compiled on May 25 2022)
Average 8726.523438 MB/s
Phobos Digest Test 'test_xxh64.test_xxh64' (compiled on May 25 2022)
Average 17062.607422 MB/s
Phobos Digest Test 'test_xxh3_64.test_xxh3_64' (compiled on May 25 2022)
Average 18957.285156 MB/s
Phobos Digest Test 'test_xxh3_128.test_xxh3_128' (compiled on May 25 2022)
Average 18937.341797 MB/s
Phobos Digest Test 'test_murmur32.test_mm32' (compiled on May 25 2022)
Average 4002.023682 MB/s
Phobos Digest Test 'test_murmur128.test_mm128' (compiled on May 25 2022)
Average 5361.663574 MB/s
Total test duration: 14 secs, 740 ms, and 589 μs

This patch is motivated by the need to have a much faster alternative to the slow MD5 or SHAx cryptographic digests. XXHash by itself is no cryptographic hash, but good enough to create suitable checksums

For the record, we already have murmurhash which was also designed with these goals.

@CyberShadow XXHash seems to be slightly faster than Murmur. At least that is the stated on https://github.com/Cyan4973/xxHash/README.md. There is also a SSE2 variant, which is much faster. So it won't hurt to have XXHash available in phobos.

True, but is "slightly faster" a sufficient reason to add it and commit to supporting it in the language's standard library? New hash functions are being invented constantly, so it seems very likely that the next hash function (which in turn will be slightly faster or better in some other way than xxhash) will inevitably appear and gain popularity.
One way we've approached questions such as these in the past is to first have the functionality published as a Dub package. If the Dub package becomes notably popular and its addition to the standard library is seen as worthwhile, then it is moved here.
Another way we could approach this is to measure the feature's popularity by its availability in other programming languages and their standard libraries, as this also indicates how likely D users will expect that the feature will be available in D when moving from another language.

"slight faster" means 2.5 to 5 times faster than Murmur. XXHash is included in ZSTD, which itself gains popularity for being fast and efficient. We replaced MD5 with XXHash at work, because the cryptographic properties of MD5 are not needed (and are also already compromissed). We did some benchmarks with the alternatives and it turned out to out-perform all those alternatives on all tested architectures (x86_64, arm32, arm64/aarch64). And honestly - nobody at work even mentioned Murmur as some alternative to MD5. So it can't be that popular. But the are xxhash modules for go, node, rust and python. Therefore I would like to have it with D as well.
I already use this code for our local tools. Nevertheless it is a nice exercise to contribute this code and fix all these issues dicovered by the CI pipelines here.

But the are xxhash modules for go, node, rust and python. Therefore I would like to have it with D as well.

Alright, but why not publish this as a Dub package and go straight to submitting this to the standard library?
Actually, I see that someone already made a Dub package five years ago:
https://code.dlang.org/packages/xxhash
It doesn't seem to integrate with std.digest but it does implement the algorithm.

Yes, I know, and the existing Dub xxhash package implements the old old 32 bit algorithm. Meanwhile, there are two new 64 bit modes variants, and a 128bit variant. The new variants also support a secret and seed parameter. There is also special assembly code for maximum performance and SSE2 support. My goal is to add these additional features as well, so taht everything provided by the current xxhash library 0.8.1 is also directly available in D.
As I can't see a good reason, why a maintained C library should be rewritten in D I opted for the D wrapper approach. The wrapper are directly derived from the sources in std.digest.* .
As soon as I got all pipelines and checks from PR working, I will add the remaining features for XXHash to the wrapper code.
Making a stand-alone dub package is a little bit more complicated, because I have to reinvent the wheel again to compile the C sources for many different platforms. Applying the code directly to phobos solved a lot of these problems, which is the main reason, why I did it that way.

This patch is motivated by the need to have a much faster alternative to the slow MD5 or SHAx cryptographic digests. XXHash by itself is no cryptographic hash, but good enough to create suitable checksums

For the record, we already have murmurhash which was also designed with these goals.

MurmurHash is very different from xxHash. xxHash is a new iteration of non-cryptographic hashes with very interesting results, in favour of a replacement for MurmurHash on 32-bit and 64-bit low cuts. AFAIK, we use a MurmurHash3 implementation for TypeInfo.toHash() ? We should really consider changing it to a faster algorithm. xxHash is greatly faster and still maintains very good quality, for both small and large data, hence suitable for zstd compression. Sliced xxh3 variants (xxh3 64-bit sliced to represent a 32-bit hash) can be considered as they provide better throughput in some systems.
That said, I think we should consider this addition and possibly discuss further on adoption for druntime hashOf implementation: https://github.com/dlang/druntime/blob/master/src/core/internal/hash.d . I'm not sure if this is something even considerable since it will be kind of a breaking change, from a deterministic/reproducibility perspective.

@ljmf00 Thanks for your thoughts. We had similiar discussions and considerations at work. XXHash is amazingly fast, but still reliable enough to checksum data. For stuff like toHash(), I think this should be black box for the user. The should assume that a good hash algo is in use, but nothing else. If you need to rely on the hash, you must implement your own toHash() function, I think.
@CyberShadow I'm aware of the maintainance burden of having C files bundles with phobos. On the other hand I would maintain them in case of inclusion, on the other hand we can participate from future improvements and bugfixes in the C codebase from upstream. At the moment I use the C files as provided from upstream without any change, yet.
Currently there is some issue on darwin targets with the inline assembly and Xcode, but this shouldn't need big fixes. Unfortunately I do not have any Mac computer or Xcode, so I can only check the build pipelines for this project, and guess/google possible solutions.

That should be fine, and we've done this before. The hash as well as ordering of objects in an AA is implementation defined. The hash/order is already different on different architectures.

Ok, makes sense.
Regarding to including the C headers/source, I wouldn't include the whole thing. I'm not sure how good is the vectorization passes to transform something like this https://llvm.org/doxygen/xxhash_8cpp_source.html to efficient SSE code.
How hard would be to translate this to D?
From my understanding by reading some source code, it seems that a lot of code is macros to support loads of variants of xxhash, loads of variants of C and loads of systems/platforms we don't currently support.
There is also a lot of utility code to generically support SIMD/intrinsic ops, and we already have most of it.
Hopefully with our __simd and __vector API we can significantly simplify this, although I'm not very deep into that topic to evaluate the effort.

@ljmf00 I think, it shouldn't be too hard to create a D port of the C sources. With all the unittests already implemented and checksums compared against the reference C code and the commandline xxhsum tool, it should be possible to detect regressions.
The XXHash implementations shouldn't change at all, as they are released and used to verify data streams in ZSTD and for other tools. Maybe new algorithms are added later. But for the existing C implemenation changes to the algorithm are impossible, because that would break anything depending on it.
So I'm going to replace the C sources with some hand-crafted D code.

A further reason not to include another C lib in Phobos is that distro package maintainers don't like that duplication; they have their own zlib and libxxhash packages. E.g., the Debian packages exclude the zlib sources from Phobos AFAIK (or at least used to do that).

A further reason not to include another C lib in Phobos is that distro package maintainers don't like that duplication; they have their own zlib and libxxhash packages. E.g., the Debian packages exclude the zlib sources from Phobos AFAIK (or at least used to do that).

Agree. I never understood the reason behind that, honestly. We should use pkg-config or similar stuff to manage those dependencies.

We should use pkg-config or similar stuff to manage those dependencies.

This is a good option on Linux but is not generally available on other platforms that D aims to support.

So porting the routines to D seems to be the best option, as it solves the problems with embedding C sources and get it working on all platforms.
On the other hand, the C sources are highly optimized. I got the XXH32 and XXH64 already ported. There are still some architecture speed optimizations, which might be worthy to be ported as well.
At the moment I' working on porting the newer XXH3 variants, which also support vector units. I will first port the plain C versions, and then I need to think on how to include _simd or whatever to have enable high speed support for them.

Latest problem with XXH3 variants: They needs 128bit arthmetics. With current C compilers this is no problem, as they already have 128 bit code available and builtin.
In D this is still WIP - current code only works with dmd-beta . The types cent/ucent are not implemented, and std.int128 seems to have problems casts from Int128 to ulong.
So porting the XXH3 code to D is tricky at least. Including the C sources toke 3min and seems to work for all targets except of Darwin.

Ok, ported the C code to D. And Unittests still pass ;-) The result is still pretty much C-ish source code, which needs further cleanups and refactoring to match D coding style.
The current state of this PR is retained as branch 'add_xxhash_digest_C_version' in my repo fork.
I will rebase and cleanup the commit stack of this PR, remove C code and related changes to Makefiles. Then I will refactor the code, until it passes the pipelines.
Thanks for encouraging me to do this tedious porting work... ;-)

I think we should first make all the interfaces private and only export the digest public API and make it public when needed? Also, I've seen a lot of @trusted for unsafe interfaces. I assume you are doing this to track it, right?

First, thanks for the review and comments. It is always fun to see, that people do all that kind of work in their spare time. I would really  like to see that at work. Unfortunately most of my colleagues think, that reviews and documentation is just superfluious non-sense. Not to talk about unittests. It was really helpful to have all these unittests already in place and working, while I adapted the C sources to D.
And I just see:  The pipelines completed succesfully ;-)
I will apply the suggested changes asap and resolve comments above when done.

The next steps are cleanups on documentation and code style. Maybe/Probably also some enhancements to unitests. After that, the PR should be ready to leave draft state.

PR closed as stalled. This can be resurrected for Phobos 3. And we would really appreciate it if the author was willing to do so as this is something we are specifically interested in getting into Phobos 3.


Client security, Core

The recovery mechanism needs to be adjusted, since now it is no longer possible to brute-force the OTP.
The UI needs to be adapted to accommodate for the (optional) second OTP. Later we might add a function on smart contract to allow replacing the root, so the user can seamlessly transition a single OTP wallet to double OTP. For now we can just let the user decide upfront and ask them to create a new wallet if they want double OTP.
Some minor frontend logic needs to be updated to use the new hasher (argon2) with appropriate randomness (e.g. 16-17 bits). Later we can optimize the speed by parallelizing it (so we gain 1-3 more bits of randomness). For now we can just use a slightly lower randomness parameter to make it fast.
The sha256 hasher is already fast enough to support ~20 bits of randomness. Based on previous benchmark (see /benchmark and /legacy/client folders), double SHA256 can be done in-browser in ~1.5 second using a single thread on mid-tier iMac 2014, and ~1.2 second on a 2018 MacBook Pro, single-threaded.
It should also be noted that the implementation relies on a customized Argon2 that made it more efficient for computing hashes in batch: https://github.com/polymorpher/argon2-browser. Note that there is still a lot of room for improvement in the customized version. For example, right now each hash computation still triggers a full initialization and destruction sequence in the underlying C code, which involves a large number of malloc and free. They can be improved by doing malloc and free only once for the entire batch. The javascript code could also parallelize the workload and obtain at least 2-4x speed boost for today's typical hardware. A deeper dive into the C code may also allow us to remove salt and align each input to a single 32-byte word, and optimize the code further for 32-byte blocks of input. With these improvements, it can be expected that the randomness bits can be improved to ~20 with argon2, i.e. close to ~1M as originally proposed in Client Security.
Other than these low hanging fruits, we can identify further bottleneck by comprehensively profiling and benchmarking the C code.

updated with some comments regarding argon2 implementation

All items are done except argon2 speed optimization. I will create separate issues to document that (as already analyzed above)

Yes, I also made a similar conclusion in https://github.com/polymorpher/one-wallet/issues/67 for different reasons


Sync eng/common directory with azure-sdk-tools for PR 1515

Sync eng/common directory with azure-sdk-tools for PR https://github.com/Azure/azure-sdk-tools/pull/1515  See eng/common workflow

/azp run cpp - core - ci

/check-enforcer evaluate


Add support for GLTF KHR_texture_basisu extension

Describe the bug
Following discussion https://github.com/f3d-app/f3d/issues/1705, here is a dedicated thread for adding support for GLTF KHR_texture_basisu extension - which can be referenced in https://github.com/f3d-app/f3d/issues/608?
GLTF meshes with draco + KTX2 compression (KHR_texture_basisu extension with etc1s compression) are not rendering in f3d while they render in donmccurdy gltf-viewer or viewer.needle.tools
Using the verbose flag, importing such a mesh yields the below error glTF extension KHR_texture_basisu is required in this model, but not supported by this loader. Aborting for my draco+ktx2 compressed meshes.
Found a reader for "mesh-5.0.1-mini.1.etc1s+draco.glb" : "GLTFDraco"
Loading 3D scene: mesh-mini.1.etc1s+draco.glb

ERROR: In vtkGLTFDocumentLoaderInternals.cxx, line 1339
vtkF3DGLTFDocumentLoader (00000105DDD1FC50): glTF extension KHR_texture_basisu is required in this model, but not supported by this loader. Aborting

ERROR: In vtkGLTFImporter.cxx, line 395
vtkF3DGLTFImporter (00000105D1B386D0): Error loading model metadata

ERROR: In vtkGLTFImporter.cxx, line 837
vtkF3DGLTFImporter (00000105D1B386D0): The GLTF model is nullptr, aborting.

To Reproduce
Steps to reproduce the behavior:

Open a mesh file with KTX2 texture compression eg  zips: AnisotropyBarnLamp.zip and StainedGlassLamp.zip which come from the KhronosGroup/glTF-Sample-Assets repo AnisotropyBarnLamp and AnisotropyBarnLamp  -

above error occurs and mesh does not render

Expected behavior
Visible mesh+viewport grid.
System Information:

OS: Windows 11
GPU and GPU driver: Nvidia RTX A1000

F3D Information

F3D - A fast and minimalist 3D viewer
Version: 2.5.0.
Build date: 2024-07-01 21:21:53.
Build system: Windows 64-bits.
Compiler: MSVC 19.40.33811.0.
External rendering module: ON.
Raytracing module: OFF.
VTK version: 9.3.0-3457-gecf3646d64 (date: 20240620).
Copyright (C) 2019-2021 Kitware SAS.
Copyright (C) 2021-2024 Michael Migliore, Mathieu Westphal.
License BSD-3-Clause.
By Michael Migliore, Mathieu Westphal and Joachim Pouderoux.

Additional context
Original discussion here https://github.com/f3d-app/f3d/issues/1705

Added in https://github.com/f3d-app/f3d/issues/608


hot&cool data strategy

Is your feature request related to a problem? Please describe.
after a long time, we got a lot of old date in pulsar, but we just need search in a small range of data sometime.
Describe the solution you'd like
if there were some oldest data unused and need delete, we can use some tag like timestamp or others what help us to choose the data we'll remove. or we can use some way to manage the unused date, sometimes they may affect the performance and speed of presto. just like elasticsearch we can close some index when we think some date are out of the range。
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.

@kinbod Apache Pulsar supports size-based and time-based data retention, does this works for you?

data retention

size&time based date retention will truncate the data, sometimes I need expand the search scope witch will includ some epired data, but I won't get it back agine, doesn't it ??


Fix exports

This PR fixes the exports so that downstream packages have access to zenoh include dirs and libraries.

This looks ok, but I think we still need the FastRTPS/FastCDR exports since the typesupport package uses FastCDR to do it's serialisation.
Any missed exports with that regard may be masked by the fact that FastCDR is separately sourced in the default ROS underlay.

I will have to defer to @gbiggs to confirm though, I'm unsure if there have been any major changes to this package.


Interactive Tutorial - Configuring a Java Microservice

The tutorial claims there is a "finished" directory in Step 1:

You will notice there is a 'finish' directory. This contains the finished code for this tutorial for reference.

After doing a ls there is no such folder
$ ls inventory  kubernetes.yaml  pom.xml  system

I just realized the "finish" directory was one directory up.
I think the tutorial booted me into the wrong directory on startup. It looks like its not doing it anymore.


Add an IRC channel to the README

It would be nice to have a forum for discussion / spitballing / etc. outside of the issue-tracking progress.
I welcome feedback including but not limited to:

"It's the 21st century; we use Slack here."
"Why not this other (network|name|.*)?"
"No, let's track discussions in the issue tracker; drop this PR."

Good idea! I haven't used IRC for ages (it's a damn shame). While I'm aware of the issues when using Slack (and IRC for that matter) for open source projects, I'm mostly in the Gophers Slack so I'd cast my vote to create a channel over there.

Slack SG- thanks!


Correct number of registers used in satd8x8

I probably should have held out on the previous patch but eh.
I suspect this will fix the bug.

I'm already building it. Will report back.
On Mon, Sep 2, 2019, 9:28 AM Luca Barbato<EMAIL_ADDRESS>wrote:

@lu-zero commented on this pull request.
CC: @moisesmcardona https://github.com/moisesmcardona and @jamrial
https://github.com/jamrial
Hopefully we won't need a third patch :)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/xiph/rav1e/pull/1624?email_source=notifications&email_token=AD4R72W2J4U2HS7LVVMKWWTQHUIHNA5CNFSM4IS5OK22YY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOCDMAY2Q#pullrequestreview-282594410,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AD4R72RRYJDQQL2U2MPRCA3QHUIHNANCNFSM4IS5OK2Q
.

Yes, this PR fixes the problem on Windows.

Coverage remained the same at 71.071% when pulling d334312f73678af9d4dc4974534d33765be284b2 on KyleSiefring:fix_reg_num_satd_asm2 into 42edde3a39d03352a1ed9c392c121568ddba6b85 on xiph:master.


fix: FluentNumberField ParseErrorMessage is showing when I enter a valid int value second time

🐛 Bug Report
I was testing FluentNumberField and ParseErrorMessage is still showing when i passed good int value.
Entering valid int: (ok)

Empty string passed: (ok - ParsingErrorMessage is shown)

Entering valid int second time: (wrong behaviour - ParsingErrorMessage should be hidden now since i entered a valid int value)

On the other hand, FluentCheckbox works fine :)
Updated https://github.com/FritzTheCat9/Blazor.FluentUI.BugWithValidation repo with FluentNumberField bug reproduced.

Can be related to: https://github.com/microsoft/fluentui-blazor/issues/1345

Yes, it is a duplicate. Closing this one.


Missing compile error for unknown name in for await loop with deconstruction

TypeScript Version:  3.4.0-dev.20190207

Search Terms:
for await
async
AsyncIterableIterator
AsyncIterable
Code
async function bar(){
    for await (const {} of imNotExisting){
        console.log("!");
    }
}

bar().catch(() => {})

Expected behavior:
TS2304 Error - Cannot find name "imNotExisting"
Actual behavior:

Related Issues:
Most likely same issue as #29796

Has nothing to do with for await, for any for of loop if the for variable is an empty binding pattern, the for expression will not get checked. So this is also not reported as an error:

function bar2(){
    for (const { } of  foo+bar){ // any expression here will not get checked
        console.log("!");
    }
}

function bar2(){
    for (const [] of foo){
        console.log("!");
    }
}

This is due to the fact that the for expression is checked only as part of checking the variable declaration. If the variable declaration is an empty binding list no need arises to check the expression an so any type errors go unreported.
This behavior is not present if we use a binding list directly:

function bar2(){
    for ({ } of foo+bar){ // error as expected
        console.log("!");
    }
}

function bar2(){
    for ([] of foo){ error as expected
        console.log("!");
    }
}

Definitely a duplicate of #29796 - both are symptoms of us failing to check a node


Delete manifests/m/matchmycolorLLC/Colibri/<IP_ADDRESS>47 directory

[x] Have you signed the Contributor License Agreement?
[x] Have you checked that there aren't other open pull requests for the same manifest update/change?

[x] Does your manifest conform to the 1.4 schema?

Note: <path> is the name of the directory containing the manifest you're submitting.

Microsoft Reviewers: Open in CodeFlow

We want to remove the matchmycolorLLC.Colibri package and keep the matchmycolor.Colibri package


MDC-102 Java - Android Studio warning for textAppearance xml resource marked as private

As shown in the image, I'm getting a warning that the resource 'android:textAppearance="?attr/textAppearanceHeadline6" is marked private in com.android.support:design-widget. To fix this copy the resource into your own project instead.

This is a bug with the public attrs exposed by the library and will be fixed in the next release.


[FLOC-3988] Logs for timeouts

Makes it so that we get logs for tests that time out.
Relies on switching the branch we use for testtools. Rather than clusterhq-fork, which was becoming a bit of an unnavigable nightmare, we're using optional-twisted-logging, which is a clone of the branch that's up for review at testing-cabal/testtools#172.
The hack is a bit gross. I'll try to get something nicer upstream.

:heavy_check_mark: Looks good to me, thanks for caring for failure cases. Merge when green.

:heavy_check_mark: still looks good.
That's rather an obscure bug, and a shame that it's a bit of a "more magic" line of
code for us now.


Make CIFAR10 use Preprocessor classes instead of hardcoded options like 'gcn' etc.

How can I help fixing this issue?
Is it still open?

Pylearn2 don't have developer anymore. There is other framework on top of
Theano like Lasagne and Keras.
Lasagne happilly accept contributor if you want to contribute to open
source software.
On Wed, Aug 9, 2017 at 1:34 PM Bruno Santos<EMAIL_ADDRESS>wrote:

How can I help fixing this issue?
Is it still open?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/lisa-lab/pylearn2/issues/199#issuecomment-321326337,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AALC-1_bSAWcgdfOE1z5aUpUBj8ZXn1rks5sWe2bgaJpZM4AhHW2
.


LCR: need text to clarify for user that outbound routing applies when you have > 1 carrier

Currently the panel looks like this

Below "Outbound call routing" and above the filter, I would like to have some secondary text that says
"Outbound call routing is used to select a carrier when there are multiple carriers available"

also needed in SP and account user view


Add a restart option on the file menu

🚀 Feature
Add a restart method to the main application and add it to the corresponding menu.
Motivation
Some configuration options will need a restart so we need to provide a a way to restart
Pitch
N.A.
Alternatives
N.A.
Additional context
This is part of the configuration/settings work.

+1 to this functionality, thanks for making an issue to track!!


PWN-7606 - fixes for coingecko

Jira Ticket
https://p2pvalidator.atlassian.net/browse/PWN-7606
Description of Work
PWN-7606 - fixes for coingecko use single for TokenPricesRemoteRepository and use common PriceCacheRepository.kt to use same logic under the hood

Let's include this ticket in relearse @kabramovp2p


Change NJSA API to allow POSTing of either JSON or CSV data

POSTing of CSV data works. Need to also support JSON.


Added Hover to Views Menu in Web UI

Added a css hover state to the views menu in the subnav.
@bgrant0607 highlighted the issue in a comment on https://github.com/GoogleCloudPlatform/kubernetes/issues/7122
cc/ @jackgr @lavalamp

@bgrant0607, assigning this to you since you've already started reviewing

@jackgr please review

@jackgr @bgrant0607, updated and ready for review

:+1:

Please rebase it thanks!

@dchen1107 rebasing now

@dchen1107 I've rebased and it's ready for merge

@dchen1107 I see you just merged the breadcrumb fix, rebasing again

@dchen1107 rebased and ready for merge


Allow scheduler options import from configuration file

This is a possible implementation of #400. For a start, I have decided to go for as little extra code as possible and have added a config_scheduler_options variable that is set by a cluster-specific nested scheduler_options entry (as was suggested by @lesteve above).
However, in terms of consistency/design choices, I am not entirely sure about the scheduler_options entry being fully optional. The advantage is probably, that everybody who doesn't need this feature won't have to extend their already existing user-specific configuration files. The disadvantage is certainly, that configurable options are now inconsistently handled. If I see it correctly, every parameter that could be set from a configuration file is currently required to exist as an entry and I think it would be user-friendly to follow this logic also for the scheduler options (which means, however, extending jobqueue.yaml by even more redundant code lines, which I am a bit hesitant to do).
A general way out could be to implement configurable options not as currently done by
cores = dask.config.get("jobqueue.%s.cores" % self.config_name)

which throws a key error and terminates execution if an entry does not exist, but by
cores = dask.config.get("jobqueue.%s" % config_name).get('cores')

which returns None if an entry is not existing. If I haven’t overseen anything, the overall behaviour of the code would not change, because a required configuration entry cores: null is also simply translated into cores = None. Implementing configurable options like this would save lots of code lines and allow to set up very minimalistic configuration files.
On the other hand, it would certainly get less clear what is actually configurable. Maybe keeping it inconsistent, but properly documenting it, is the way to go… or keeping it minimalistic and properly documenting the available options?
Either ways, input is greatly appreciated...

Thanks also for the helpful entry points on testing! I have come up with two scenarios that might be useful: One is checking that parameters provided in the config are actually used (to specify the scheduler options), the other checks if parameters manually passed completely overwrite those from the config.
(In the earlier version I also had tests that checked for the default behaviour, as well as passing the host options. However, I think that is already covered in the existing tests and does not really add value here, so I deleted them. Of course, the remaining tests should be moved into test_jobqueue_core.py, but I did not do that for now.)
Overall, I am not entirely sure if my generic_cluster_conf approach is good (thinking long-term here). It was the shortest implementation I could think of, but each time an option is added to one of the cluster types, it would also have to be added in that generic_cluster_conf variable. (I was also thinking about instead adding a scheduler_options test in each of the cluster type collections, to keep things together, but that felt like writing a lot of redundant code...)

you could add an empty entry in jobqueue.yaml. I guess adding scheduler_options: would be enough.

Good idea, that would at least indicate that a per-file configuration of the scheduler_options is possible. Should I add this in addition to having these parameters fully optional?

whether we should put an empty scheduler_options: section for all the schedulers in jobqueue.yaml. Up for debate.

I think, there is more pro than contra here, so I have implemented it now. (In the config file, I've also took the freedom to move the extra: [] entries from the resource manager into the Dask worker sections for each cluster type. This mis-categorization had bothered me already some time ago, and just attracted my attention again. If you think this is more than a minor fix and should be a separate PR, please tell me, and I will undo that.)

whether there should be a test to read from a file with a non-trivial scheduler_options in the config file. This is to make sure this works. I think it should but having a test would be better because I am not 100% confident

I have started to implemented this, but then I thought that this is actually a topic of general relevance. If I see it correctly, all the config file options are currently tested only by manually defining a dictionary and adding it to the global dask.config pile, never is reading from a file involved. It might be good to have tests on more than just the scheduler_options, which might, however, better be tackled in a separate PR?

Thanks for repairing the CI, seems to have worked now!
(I hope, that simply merging these changes was the way to go.)

@kathoef sorry I am quite busy with other things, right now ... can you remote the "Draft" status of this PR (not sure how to do this I have to admit).
I started using github before this Draft status existed, what is the advantage out of curiosity ? I have always seen things like WIP in title that worked well enough ...
I'll try to review this PR before next Monday, don't hesitate to ping me if I don't do that !

@kathoef sorry I am quite busy with other things, right now ... can you remote the "Draft" status of this PR (not sure how to do this I have to admit).

Thanks for taking the time to leave a quick note! Yes, I can remove the draft status. (I have a "ready to review" button just above the "All checks have passed" part, maybe only I can see this?)

I started using github before this Draft status existed, what is the advantage out of curiosity ? I have always seen things like WIP in title that worked well enough ...

That's a very good question. I am relatively new to collaborative code work and to me this seemed like the clean way to go (when I opened this PR, I was sure that the code wasn't ready to be merged). Maybe it's actually a formal mechanism to ensure an agreement between developers and reviewers about when to merge? If a reviewer can't change the PR status, then this would be my interpretation. (In addition to that, unfortunately, I have absolutely no idea about how Github interprets this WIP title syntax. That's probably also why I have chosen the draft PR feature, it felt less like "doing it wrong".)

I'll try to review this PR before next Monday, don't hesitate to ping me if I don't do that !

No urgency, and yes I will, thank you!

BTW I forgot to review your PR before Monday as I promised, you should have pinged me ;-)

Yes, sorry... I had some medical intervention on Tuesday last week, and I guess this made several things slip off my table already on Monday... thanks for taking care.

Looks like the CI also failed because I was too sloppy... I have now restored the empty dictionary that allows the scheduler-options entry to be fully optional in the configurations (as scheduler-options are missing for the single cluster class configuration tests, these had failed).
I originally planned to move the tests into test_jobqueue_core.py. However, I have come to think that it might be a good idea to keep them separate (that's up for debate, however!), so I have tried to chose a more useful and less specific file name.
As the CI now has passed, could you have another look, @lesteve?

Sorry for taking such a long time to merge this one :-S. I don't have that much time to look at Dask-Jobqueue these days unfortunately ...
FYI I pushed a few tweaks:

changelog entry
move the tests back to test_jobqueue_core.py. In my mind they are a catch-all for tests that should work for all cluster classes. I agree it may need to be split at one point in the future but we'll cross that bridge when we get there
Also, I have an ongoing PR to make common tests like this one easier to write in #353. Leaving the tests in test_jobqueue_core.py makes it more likely that I manage to remember to take them into acccount.

When will this patch be in a release?

Not sure maybe in one or two weeks if I get the chance to do a release by then, but there is no guarantee about this unfortunately.
In the meantime two work-arounds :

you can use scheduler_options parameter i.e. not through the config_file
you can install the dask-jobqueue development version (for example pip install git+https://github.com/dask/dask-jobqueue or update your requirement.txt or environment.yml in a similar fashion)

Not sure maybe in one or two weeks if I get the chance to do a release by then, but there is no guarantee about this unfortunately.

@lesteve, what are the pending tasks/PRs that need to be addressed prior the next release? I'm happy to help out

@lesteve, what are the pending tasks/PRs that need to be addressed prior the next release? I'm happy to help out

Thanks a lot for your help! I had a quick look at the open issues and I think I would need to figure out what to do about #196. I am leaning towards providing a work-around at the moment rather than changing the dask-jobqueue code so this would not be a blocker.
Feel free to have a quick look at the list of issues to see if I have missed something!


Secrets defined against the generic backend should be rotating instead of renewable

In https://github.com/spring-projects/spring-vault/pull/95 I implemented the logic for automatic rotation of generic secrets. As per the discussion on https://github.com/spring-projects/spring-vault/issue/68, generic secrets can be rotated, but they cannot be renewed.
At the moment, Spring Cloud Vault treats all leased secrets as renewable, so it doesn't handle rotation of generic secrets.

I'm working on a PR to fix this

Opened #111

Thanks for your PR. We have a similar story in #90.
Generic secrets might be a different use case because the generic secret backend is intended more for custom properties that do not relate to properties of integrations (AWS, Databases, Messaging) in the first place (although you can add properties like spring.datasource.username).
This change makes sense when properties are accessed through Environment or used with @RefreshScope.

This change makes sense when properties are accessed through Environment or used with @RefreshScope

Yeah I think querying the properties from the Environment (or an autowired VaultPropertySource) is probably the right approach.
Here's what I did for my test app (using a build which includes spring-projects/spring-vault#95, spring-projects/spring-vault#97, and #111) . It works quite nicely, and there's no action required to get the new values, aside from actually writing them to vault Vault (which can be done completely outside the Java application).
@RestController
@RequestMapping(path = "/hello-world")
public class HelloWorldController implements InitializingBean {

	@Autowired
	private Environment environment;

	private RelaxedPropertyResolver propertyResolver;

	@Override
	public void afterPropertiesSet() throws Exception {

		Assert.notNull(environment, "Environment must be set");
		propertyResolver = new RelaxedPropertyResolver(environment, "data.");
	}

	@GetMapping(path = "/message")
	public String value(){
		return propertyResolver.getProperty("hello-world.message", "null\n");
	}
}

With this setup, you just do vault write secret/hello-world-app ttl=1m hello-world.message=whatever to change it, and in about a minute or so (depending on what ttl you had on the previous value), the controller will start returning the new value.

Added comments to your PR #111.


Card

[x] I want to be able to insert a new card
[x] I want to be able to edit a card
[x] I want to be able to delete a card

done with last commit


Pipeline editor webpack config isn't being used

While trying to add scss to the pipeline editor extension, I found that webpack wasn't picking up changes to the config and didn't recognize new custom loaders. For JL 3, looks like you can override the JL webpack config for prebuilt extensions (https://jupyterlab.readthedocs.io/en/latest/developer/extension_dev.html?highlight=webpack#custom-webpack-config-for-federated-extensions), but Elyra extensions aren't prebuilt at the moment.

@jasongrout Thoughts?

The core misunderstanding here, I think, is that JupyterLab uses its own webpack configuration when building JupyterLab and incorporating extensions. It ignores any webpack configuration in the extension when building core JupyterLab.
There are two basic ways to proceed with something like scss files in a jlab extension:

Compile the scss files into css files in a separate step before publishing your extension. Essentially we do this already with typescript in most extensions - all typescript is compiled to js before the extension is published, and the resulting js is what is published and used by jlab.
A hack that some people have found useful is to depend on the webpack scss loader, then use the webpack import syntax that invokes the loader, by hardcoding the import as import 'style!css!scss!my-file.scss'; or something similar - see the webpack documentation for the ! syntax for loaders. Basically, this works around jlab not giving a webpack configuration for scss files by using the webpack syntax for invoking a loader directly.

For prebuilt extensions, webpack is used in the extension publication process (i.e., a separate webpack build is done for each prebuilt extension), so it is not as important that a single webpack config serve all extensions simultaneously. For that, you have more flexibility to customize a webpack config for a particular extension (without messing up other extensions). That's why we made it possible to customize the webpack config for prebuilt extensions.

@jasongrout Thank you for clarifying and for the ideas! I'm trying the inline loader and it seems to be working. Hopefully we can move over to prebuild soon.


[bug] lsp hover content  error

Bug Report
Please answer these questions before submitting your issue. Thanks!
1. Minimal reproduce step (Required)
schema with param and base

2. What did you expect to see? (Required)
main
---
schema Data1[n: str](Data):
---
Attrbutes:
name: str

3. What did you see instead (Required)
4. What is your KCL components version? (Required)

Hey @He1pa, I'd love to work on this. Could you please assign it to me?


[2019-06-11 04:42:43.19] The request for path /v1.0/sandbox/dev/apps?SchemaUpdateMode=synchronize failed with code InternalServerError. Reason: ForceHandleTrackingEvent failed to acquire a lock

Hi,
I am facing the below issue, while trying to publish in visual code. I am facing this error only after publishing directly through Upload Extension in sandbox.
Now I have to publish through visual code, Please provide any solution to fix this.
[2019-06-11 04:42:43.19] The request for path /v1.0/sandbox/dev/apps?SchemaUpdateMode=synchronize failed with code InternalServerError. Reason: ForceHandleTrackingEvent failed to acquire a lock

I am facing the same issue but trying to download symbols

Same issue here. Can't download symbols and cant pusblish too.

It also takes a lot of time befor getting this error

Same issue here.

Try to change app and platform version from 14 to 13. It works for me but It has no sense.

I have the same issue downloading symbols from my sandbox. Takes a long time for the error.

Hi all,
We are aware of this issue, and are working to get a hotfix deployed to production as soon as possible. Unfortunately, we do not have any workarounds for this issue. Thanks for your patience.
In the future, please contact support for issues impacting production.
Thanks,
Thaddeus

Hi all,
We are in the process of rolling out the hotfix now. When it will be available depends on your region, but we expect to complete the rollout across all regions within 24 hours.
Thanks,
Thaddeus

I have the same issue downloading symbols from my sandbox.

having the same error when trying to publish to sandbox or download symbols
I am using V19


Update my_shlex to Python 3.6 version

Current coverage is 77.79% (diff: 25.64%)

Merging #184 into master will decrease coverage by 1.56%

@@             master       #184   diff @@
==========================================
  Files             5          5
  Lines           809        833    +24
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
+ Hits            642        648     +6
- Misses          167        185    +18
  Partials          0          0

Powered by Codecov. Last update 7840e5b...202df0e

@kislyuk Are you happy with removing this from the coverage report? Most of the code has nothing to do with us.

That's fine by me, yes.


Runway pull

According to pilots' reports (but you might check with your own source) the 208 requires very little correction to stay straight on the runway. But, in MSFS, it's a constant fight to keep it from going in the ditch.
So, I did finally find a fix for for it, and you might want to integrate it into your mod:
https://www.avsim.com/forums/topic/585641-fix-for-plane-pulling-excessively-to-one-side/

Thanks for the feedback, I'm aware of how to change this effect on the plane but since the pilot who is giving me feedback hasn't complained about that I didn't make any changes, but I'll check with him again.


Error building with Angular 12

Reproduction link
https://github.com/NG-ZORRO/ng-zorro-antd
Steps to reproduce

create new project
add ng-zorro-antd
build project

What is expected?
Successful compilation
What is actually happening?
Broken build

Environment
Info

ng-zorro-antd
11.4.1

Browser
Chrome

Following error occurs
Error: node_modules/resize-observer-polyfill/src/index.d.ts:19:18 - error TS2717: Subsequent property declarations must have the same type.  Property 'contentRect' must be of type 'DOMRectReadOnly', but here has type 'DOMRectReadOnly'.

19         readonly contentRect: DOMRectReadOnly;
                    ~~~~~~~~~~~

  node_modules/typescript/lib/lib.dom.d.ts:12696:14
    12696     readonly contentRect: DOMRectReadOnly;
                       ~~~~~~~~~~~
    'contentRect' was also declared here.
```<!-- generated by ng-zorro-issue-helper. DO NOT REMOVE -->

Having the same issue - I believe it's related to the updated TypeScript when you upgrade Angular - but it is ng-zorro that is dependant upon the broken resize-observer-polyfill nonetheless

Can have a try to add "skipLibCheck" in ts-config.json ?
https://www.typescriptlang.org/tsconfig#skipLibCheck

@vthinkxie this works, thank you - but of course isn't a long term solution

Would be nice if you guys could switch to another resize-observer-polyfill that's maintained.

mark

Can have a try to add "skipLibCheck" in tsconfig.json ?
https://www.typescriptlang.org/tsconfig#skipLibCheck

works for me too

@jveko Yeah, but it shouldn't be needed anymore with v12. 🙄

Sry, how do I implement this fix? How is the tsconfig file to be modified?


Check prefix more carefully

Fixes #96.

@michaelzoidl bump )

Any chance to have this merged soon ?

something?

This going to be merged at all? I will fork and release under a different scope.

@GoPro16 I think we should properly handle the prefix being provided as "@/" in the config instead. If you could send a PR for that, that'd be very much appreciated.


How to add existing users firestore?

Hello, im new in flutter, can anyone help to adding existing users to this widget?

Add to the initial value of the widget. The chips got attribute call initial value. You can add list of data there.


refactoring of MolStandardize validation module

What does this implement/fix? Explain your changes.
This PR implements a refactoring of the MolStandardize validation classes. The changes are mainly related to the reimplementation of MolVSValidation as a composite of ValidationMethod and the consequent harmonization of the API originally provided by MolVSValidations and ValidationMethod.
The new implementation should support a better usability of the validation criteria migrated from MolVS (which are this way easier to use directly) without a very significant impact on the existing client code.
The implementation of the python wrappers related to these classes was also streamlined in the process.

@greglandrum Thanks, I applied the suggested fix and reduced ValidationErrorInfo to an alias for std::string (I can quickly revert this commit if it's not the solution you had in mind). Please let me know in case the additional paragraph in the release notes required further adjustments.

@greglandrum Thanks, I applied the suggested fix and reduced ValidationErrorInfo to an alias for std::string (I can quickly revert this commit if it's not the solution you had in mind). Please let me know in case the additional paragraph in the release notes required further adjustments.

Thanks @rvianello !

thank you @greglandrum


[UBS Admin. Orders. Order details. API] The bonuses could be added to the Client without checking the overpayment presence by method POST

Environment:
Windows 10 Home (Version 22H2)
Chrome version 108.0.5359.71, Firefox version 109.0
MacOS version 12.6.1 (21G217)
Chromе version 107.0.5304.110
Reproducible: always
Build found: 04/02/2023
Preconditions

Go to the Swagger
Authorize with JWT(API key - bearer)

Steps to reproduce

Go to 'Management Order Controller'
Click on the 'POST'- method with path /ubs/management/return-overpayment
Fill up all needed items in JSON for order with  Cancel status and overpayment presence
Execute POST method one time - response code 200 OK
Execute it again - response code 200 OK too

Actual result
The bonuses could be added to the Client without checking the overpayment presence by method POST
Expected result
The bonuses could be added to the Client by checking the overpayment presence by method POST. In case when Client has already gotten his/her bonuses and overpayment was returned to his/her account response on the POST method might be 400 Bad Request
User story and test case links
E.g.: "User story #2900"
Labels to be added
"Bug", Priority ("pri: "), Severity ("severity:"), Type ("UI, "Functional"), "API" (for back-end bugs).

This endpoint was removed in the pull request.


gulp-eslint v4 cannot process more than 48 files

when there are more than 48 files, gulp-eslint v4 will always return success, can not report any issue.
gulpfile.js:
const gulp = require('gulp');
const debug = require('gulp-debug');
const eslint = require('gulp-eslint');

gulp.task('lint.server', () => {
  gulp.src([
    'app/**/*.js',
    'pm2conf.js',
    'apps.config.js',
    '!app/web/public/**/*.js',
  ])
    .pipe(debug()) // the number of files is correct
    .pipe(eslint(SERVER_LINT_RULES))
    .pipe(debug()) // the number of files is correct
    .pipe(eslint.format())
    .pipe(eslint.failAfterError());
});

Almost the duplicate of https://github.com/adametry/gulp-eslint/issues/36
Answer: https://github.com/adametry/gulp-eslint/issues/36#issuecomment-109324959:

Make sure to return the lint stream in the gulp task

@shinnn thanks for the info.
It was working in v3 and breaks since v4, is this expected?

breaks since v4

It cannot be said broken. You've just misused this plugin.

It was working in v3

If the no-return way has ben worked in your project, it's an accident.
For exmaple,
'use strict';

const {writeFileSync} = require('fs');

const gulp = require('gulp'); // v3.9.1
const gulpEslint = require('gulp-eslint'); // v3.0.1, not v4.x

gulp.task('default', () => {
  return gulp.src('**/*.js')
  .pipe(gulpEslint({
    parserOptions: {
      ecmaVersion: 6
    },
    rules: {
      'max-lines': ['error', 0] // should invalidate this gulpfile
    }
  }))
  .pipe(gulpEslint.format())
  .pipe(gulpEslint.failAfterError());
});

[20:10:07] Using gulpfile ~/example/gulpfile.js
[20:10:07] Starting 'default'...
[20:10:07] Finished 'default' after 22 ms

The above default task cannot even process a single gulpfile.js file. If you return the gulp.src stream inside the default task, it results:
[20:12:02] Using gulpfile ~/github/sssssssss/gulpfile.js
[20:12:02] Starting 'default'...
[20:12:04]
/Users/shinnn/github/sssssssss/gulpfile.js
  1:1  error  File must be at most 0 lines long. It's 21 lines long  max-lines

✖ 1 problem (1 error, 0 warnings)

[20:12:04] 'default' errored after 1.19 s
[20:12:04] ESLintError in plugin 'gulp-eslint'
Message:
    Failed with 1 error

The gulp.src('**/*.js') in your example will include dozens of files in node_modules/, which will trigger the case that I am reporting.
Changing it to gulp.src('*.js') or gulp.src(['**/*.js', '!node_modules/**']) (with or without return) will make it work in my test.

which will trigger the case that I am reporting.

Cool. This proves what I said in https://github.com/adametry/gulp-eslint/issues/209#issuecomment-334726572.

From e-mail,

"Further support questions should be directed to Stack Overflow.", not necessary to be such arrogant.

How shameless he is...


feat(svc): create Run method to encapsulate most of whats in func main

Please read CONTRIBUTING.md for additional information on contributing to this repository!

What this PR does / why we need it
This PR extracts most of the main function provided by stencil-golang into a
function clients can call instead.
QSS runs a number of peripheral services-- CDC, Ingest, Polaroid, SmartWorker,
etc., each of which need to set up their own main function. To do this, they
basically copy whats in stencil-golang. Wouldn't it be better if we could use a
library function instead? I think it would be, since it eases the burden when
it comes time to update any service-wide behavior.
Of course, we'll still want stencil to provide the kubernetes objects, e.g.
trace.yaml for example, and my hope is we'll stencil in depending on this
method instead of just doing what it does currently inline.

Jira ID
[XX-XX]

Notes for your reviewers

Shouldn't templates/cmd/main.go.tpl also be changed in this PR?

I had thought not, I'd like to merge it, use it some test services, and then circle back.

hit an issue with https://github.com/search?q=org%3Agetoutreach+stencil.AddToModuleHook+"github.com%2Fgetoutreach%2Fstencil-golang"+"serviceActivities"&type=code


 Update manually,
npm ERR! git or move it out of the way first.

rm -rf node_modules/react-native-safe-area-view/.git/
Solved For Me

@ramiasg Thanks - that only works for a single npm install, though. I have to redo it every time a new package is installed

@ramiasg It's fixed in this commit https://github.com/react-native-community/react-native-safe-area-view/commit/1f8d3897144fd6512e42c49a2be6f4a95c101515


Deployments fail due to disconnect from build and our s3 Could not read cloudformation template at path

How did you install the Amplify CLI?
yarn
If applicable, what version of Node.js are you using?
20.6.1
Amplify CLI Version
10.8.1
What operating system are you using?
Mac
Did you make any manual changes to the cloud resources managed by Amplify? Please describe the changes made.
No manual changes made
Describe the bug
⚠ - If this issue doesn't belong to amplify-cli repo but instead a more appropriate repo, please let me know

We have amplify ci/cd running
Three backed environments: dev, staging, and prod
Two hosting environments: staging, prod
We also have a testing env and hosting env

After merging a safe PR to our staging environment we began seeing this set of errors:
2023-12-12T18:12:33.533Z [WARNING]: - Building resource storage/adamariebucket
2023-12-12T18:12:33.736Z [INFO]: Could not read cloudformation template at path: /codebuild/output/src76562180/src/adamarie/amplify/backend/api/adamarie/build/cloudformation-template.json

and
2023-12-12T18:13:10.755Z [INFO]: 🛑 The following resources failed to deploy:
2023-12-12T18:13:10.758Z [INFO]: Resource Name: apiadamarie (AWS::CloudFormation::Stack)
                                 Event Type: update
                                 Reason: Parameters: [CreateAPIKey] do not exist in the template
                                 URL: https://console.aws.amazon.com/cloudformation/home?region=us-east-2#/stacks/arn%3Aaws%3Acloudformation%3Aus-east-2%3A886020249653%3Astack%2Famplify-adamarie-staging-151754%2F6c4cb130-6df3-11ee-ab72-029c65e1ea0d/events
2023-12-12T18:13:10.759Z [INFO]:
2023-12-12T18:13:10.762Z [WARNING]: ✖ There was an error initializing your environment.
2023-12-12T18:13:10.764Z [INFO]: 🛑 Resource is not in the state stackUpdateComplete
2023-12-12T18:13:10.764Z [INFO]: Name: apiadamarie (AWS::CloudFormation::Stack), Event Type: update, Reason: Parameters: [CreateAPIKey] do not exist in the template, IsCustomResource: false
2023-12-12T18:13:10.765Z [INFO]:
2023-12-12T18:13:10.765Z [INFO]: Learn more at: https://docs.amplify.aws/cli/project/troubleshooting/
2023-12-12T18:13:10.844Z [INFO]:
2023-12-12T18:13:10.844Z [INFO]: Session Identifier: 65b7ff69-33a9-4ba8-9dba-d1637d638556
2023-12-12T18:13:10.875Z [ERROR]: !!! Build failed

We absolutely know that the resource exists on S3 - however, it's last update was from our previous deployment on 12/8
We confirmed a similar error on our testing environment which has no changes within the last 3 weeks
This looks like a disconnect from Amplify

Expected behavior
That our github merge successfully builds and deploys via amplify
Reproduction steps

Create a new dev branch
Make some change (in our case it was a test file update)
Create PR on GH pointing at our staging branch (which is connected to our staging hosting environment on Amplify)
Merge
Watch build on amplify
Build fails due to disconnect with cloudformation-template.json

Project Identifier
No response
Log output

# Put your logs below this line

Additional information
No response
Before submitting, please confirm:

[X] I have done my best to include a minimal, self-contained set of instructions for consistently reproducing the issue.
[X] I have removed any sensitive information from my code snippets and submission.

No change in backend code, just a front-end change since our last deployment 2 weeks ago, but now we see this backend error: Parameters: [CreateAPIKey] do not exist in the template. No idea what's the problem. It's blocking our prod deployment now.

Hey @priyapower, thank you for reaching out.
Could you provide us the Project Identifier by running amplify diagnose --send-report or if one was created on the hosting build.
In the latest commit were there any changes to the backend files?
Were there any updates to the API key on the GraphQL API recently?

@ykethan

Project Identifier: b7bcff2cf46c4c1b95b5ae1faa4bd648
In the latest commit were there any changes to the backend files? The PR that merged updated a test file, that was it
Were there any updates to the API key on the GraphQL API recently? Nope

Hey @priyapower, thank you for this information. The Amplify team is currently diving deeper into the issue.


Dataviews fetch from data provider when present

Closes #1068.
@fdansv can you please take a look?
cc: @javisantana

:es:

All looks good to me, agree that we need to talk about improving the generators.


TMC429_IDX_XLATCHED -> TMC429_IDX_XLATCHED(motor)?

https://github.com/trinamic/TMC-API/blob/fd6a5378b2157bf115b8126c9183364b899fa27f/tmc/ic/TMC429/TMC429.c#L379
Shouldn't this be TMC429_IDX_XLATCHED(motor) ?
The define in TMC429_Register.h is::	#define TMC429_IDX_XLATCHED(motor)          (0x1C|TMC429_MOTOR(motor))
So it takes a parameter.

Thank you for your feedback. It has been updated.


Kube_apiserver_bind_address auto-configures wrong API access endpoint for all-in-one deployments

BUG REPORT
HA docs describe external and local LB as mutual exclusive and impose masters and nodes running on separate nodes.
When using all-in-one (a master is running workloads) and kube_apiserver_bind_address set up,
kube_apiserver_endpoint auto eval fails to detect its value. It puts <IP_ADDRESS>, while there is nothing listens there, and local nginx LB is not configured for masters.
As a fix for loadbalancer_apiserver_localhost=False, we need to switch the endpoint to use kube_apiserver_bind_address instead of <IP_ADDRESS>.
And for  the loadbalancer_apiserver_localhost=True case, we prolly need to deploy nginx on masters as well?
Environment:

Cloud provider or hardware configuration: n/a

OS (printf "$(uname -srm)\n$(cat /etc/os-release)\n"): n/a

Version of Ansible (ansible --version): n/a

Kubespray version (commit) (git rev-parse --short HEAD): 2c6255d
Network plugin used: n/a
Copy of your inventory file:
apiserver_loadbalancer_domain_name: <External LB's FQDN>
access_ip : <VIP matching that FQDN>
loadbalancer_apiserver.address: "{{ access_ip}}"
loadbalancer_apiserver_localhost: false
kube_apiserver_bind_address: <private IP>

Command used to invoke ansible: as usual

Masters have always pointed to localhost for apiserver. What is the bug? We have an AIO case in CI working.

@mattymo - we're trying to deploy with an external LB (haproxy) and VIP (manged via keepalived), & when you specify loadbalancer_apiserver_localhost: false the generated /etc/kubernetes/*kubeconfig.yaml files all point to localhost, which doesn't seem to work unless you don't set kube_apiserver_bind_address (so the API listens on <IP_ADDRESS>) - we want to set this so haproxy and the kube API can listen on the same port, because that fits the current TripleO loadbalancer implementation better.

Note it's possible we're doing something wrong, but here's what I'm trying:
(undercloud) [stack@undercloud kubespray]$ cat global_vars.yml
kubeconfig_localhost: true
artifacts_dir: '/home/stack/tripleo-VFDQm5-config/kubespray/artifacts'
ignore_assert_errors: False
kubelet_fail_swap_on: True
apiserver_loadbalancer_domain_name: overcloud.internalapi.localdomain
loadbalancer_apiserver_localhost: false
FIXME is this needed, and why doesn't setting loadbalancer_apiserver have the same effect?
access_ip: <IP_ADDRESS>
loadbalancer_apiserver:
address: <IP_ADDRESS>
port: 6443
(undercloud) [stack@undercloud kubespray]$ cat inventory.yml
kube-master:
hosts:
overcloud-controller-0:
ansible_user: heat-admin
ansible_host: <IP_ADDRESS>
ansible_become: true
ip: <IP_ADDRESS>
kube_apiserver_bind_address: <IP_ADDRESS>
kube-node:
hosts:
overcloud-controller-0:
ansible_user: heat-admin
ansible_host: <IP_ADDRESS>
ansible_become: true
ip: <IP_ADDRESS>
etcd:
children:
kube-master: {}
k8s-cluster:
children:
kube-master: {}
kube-node: {}
You can see the VIP and local bind IP via netstat:
[root@overcloud-controller-0 ~]# netstat -taupen | grep 6443
tcp        0      0 <IP_ADDRESS>:6443      <IP_ADDRESS>:*               LISTEN      0          149231     697/hyperkube
tcp        0      0 <IP_ADDRESS>:6443      <IP_ADDRESS>:38108     SYN_RECV    0          0          -
tcp        0      0 <IP_ADDRESS>:6443      <IP_ADDRESS>:*               LISTEN      0          49884      15597/haproxy
tcp        0      0 <IP_ADDRESS>:6443      <IP_ADDRESS>:37494     ESTABLISHED 0          149237     697/hyperkube
tcp        0      0 <IP_ADDRESS>:37494     <IP_ADDRESS>:6443      ESTABLISHED 0          149233     697/hyperkube
haproxy config like this:
global
daemon
group  haproxy
log  /dev/log local0
maxconn  20480
pidfile  /var/run/haproxy.pid
ssl-default-bind-ciphers  !SSLv2:kEECDH:kRSA:kEDH:kPSK:+3DES:!aNULL:!eNULL:!MD5:!EXP:!RC4:!SEED:!IDEA:!DES
ssl-default-bind-options  no-sslv3
stats  socket /var/lib/haproxy/stats mode 600 level user
stats  timeout 2m
user  haproxy
defaults
log  global
maxconn  4096
mode  tcp
retries  3
timeout  http-request 10s
timeout  queue 2m
timeout  connect 10s
timeout  client 2m
timeout  server 2m
timeout  check 10s
listen haproxy.stats
bind <IP_ADDRESS>:1993 transparent
mode http
stats enable
stats uri /
stats auth admin:4VHdwgUjbmBwtY2YfYzv3NJrX
listen kubernetes-master
bind <IP_ADDRESS>:6443 transparent
balance roundrobin
server overcloud-controller-0.internalapi.localdomain <IP_ADDRESS>:6443 check fall 5 inter 2000 rise 2
This fails like http://paste.openstack.org/show/628651/ because the API isn't accessible to kubeadm I think, any pointers appreciated :)

@mattymo

Masters have always pointed to localhost for apiserver. What is the bug? We have an AIO case in CI working.

With a custom kube_apiserver_bind_address value, there is nothing listens on the master's localhost API port, AFAICT. There is no more a bind for <IP_ADDRESS>/0 and there is no nginx deployed then is_kube_master

Yes as mentioned by @bogdando the issue is we don't want the API to listen to all interfaces, so I guess we need to either configure it to listen to kube_apiserver_bind_address and localhost, confgure haproxy to listen on the vip and localhost, or configure the kubeconfig files to point at the VIP.
Configuring everything to point at the VIP would be most consistent with how we handle the OpenStack services, but I'm not clear if that would be acceptable for the k8s masters, not yet tried it.


Stuck during initialisation

I'm submitting a ...
[x] bug report
[ ] feature request
[ ] question about the decisions made in the repository
[ ] question about how to use this project

Summary

installer is stuck in Locating project files. as shown in the image

Other information (e.g. detailed explanation, stack traces, related issues, suggestions how to fix, links for us to have context, eg. StackOverflow, personal fork, etc.)

using npm 7.0.3, npx 7.0.8, macos 11.1

Thank you so much for your bug report. 🙏 I will look into this and get
back to you as soon as possible.
On Sun, 3 Jan 2021 at 20:21, Simon Bachmann<EMAIL_ADDRESS>wrote:

I'm submitting a ...
[x] bug report
[ ] feature request
[ ] question about the decisions made in the repository
[ ] question about how to use this project
Summary
installer is stuck in Locating project files. as shown in the image
[image: Screenshot 2021-01-03 at 21 19 54]
https://user-images.githubusercontent.com/15369592/103487984-76d0ce00-4e09-11eb-89ca-7f34788b92a5.png

Other information (e.g. detailed explanation, stack traces,
related issues, suggestions how to fix, links for us to have context, eg.
StackOverflow, personal fork, etc.)

using npm 7.0.3, npx 7.0.8, macos 11.1
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/cawfree/create-react-native-dapp/issues/2, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AB4OFHOZ2SFCGVG6R6OMTTDSYDGTLANCNFSM4VSEUEAQ
.

Thank you so much for your bug report. 🙏 I will look into this and get
back to you as soon as possible.
On Sun, 3 Jan 2021 at 20:21, Simon Bachmann<EMAIL_ADDRESS>wrote:

I'm submitting a ...
[x] bug report
[ ] feature request
[ ] question about the decisions made in the repository
[ ] question about how to use this project
Summary
installer is stuck in Locating project files. as shown in the image
[image: Screenshot 2021-01-03 at 21 19 54]
https://user-images.githubusercontent.com/15369592/103487984-76d0ce00-4e09-11eb-89ca-7f34788b92a5.png

Other information (e.g. detailed explanation, stack traces,
related issues, suggestions how to fix, links for us to have context, eg.
StackOverflow, personal fork, etc.)

using npm 7.0.3, npx 7.0.8, macos 11.1
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/cawfree/create-react-native-dapp/issues/2, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AB4OFHOZ2SFCGVG6R6OMTTDSYDGTLANCNFSM4VSEUEAQ
.

Can I just check that you're able to run npx create-react-native-app with no error?

Can I just check that you're able to run npx create-react-native-app with no error?

This looks like the fix. :)

Fixed using nvm (node version manager) and switching to node version 12

This looks like the fix. :)

Fixed using nvm (node version manager) and switching to node version 12


Adding string.startswith() and string.endswith()

@skiars Are you ok to add:

string.startswith(hay:string, needle:string [, case_insensitive:bool]) -> bool
string.endswith(hay:string, needle:string [, case_insensitive:bool]) -> bool

After writing some decent amount of code, it is quite common to have to check if a string starts or ends with a specific value. The current way to do it are not straightforward:
startswith (case sensitive):
def startswith(hay, needle)
    import string
    return string.find(hay, needle) == 0
end

endswith is not as straightforward to implement, and both lack case-insensitive check which would be useful for file extensions.

This is very necessary.


Can't win edax level 1

Didn't dive a lot into details, but following README, I've ran othello-zero v117 against edax level 1, and othello-zero lost miserably.. It didn't even capture one corner.
  A B C D E F G H
1 ●─●─●─●─●─●─●─●
2 ●─●─●─●─●─●─●─●
3 ●─●─●─●─●─●─●─●
4 ●─●─●─●─○─○─○─○
5 ●─○─●─●─●─●─●─○
6 ●─●─●─●─●─●─●─●
7 ●─●─●─●─●─●─●─●
8 ●─●─●─●─●─●─●─●

Same with level 2.
It did however win level 0, and somehow level 3, but not level 1, 2 and 4+.
Considering these facts, I'm unfortunately not quite sure about "othello-zero is close to Edax Lv.5" statement.
I also wonder, if you have been checking othello-zero vs edax on numerous various openings, not just the default one.

●Black is othello
○White is Edax

The newer othello version is not always stronger than older one (This is the biggest difference between AlphaGo Zero and AlphaZero). In fact, V067 is much stronger than V117. I will upload all checkpoints from V001 to V117, if you need them.

"Is stronger" doesn't mean "Win always", but "Win mostly". But for some reason, you can only get exactly the same game when othello's and Edax's level is same.  I make a new commit, which enable the ''randomness" feature of Edax. So you can get different games every time, and compare othello and Edax more fairly.

Thank you for trying this old and abandoned project. I make it just for fun, not for academic purposes. Some conclusions may be too hasty, But I believe the main algorithm works.

Best.

●Black is othello
○White is Edax
Sorry, I forgot to say that on my black terminal the colors are inverted, so I have inverted them in your code, otherwise black looked white and vice versa in my terminal and made brain damages to me.
So edax is ● here (and it looks white in my terminal). And it is being run on level 1 here.

In fact, V067 is much stronger than V117.
Ok, I'll try to check it out.

Thank you for trying this old and abandoned project. I make it just for fun, not for academic purposes. Some conclusions may be too hasty, But I believe the main algorithm works.
Thank you for a nice and easy getting started into alpha zero. I'm just a bit disappointed that it's a lot weaker than I wished it would have been. Especially after the fact that edax descends to levels 21-23 in no time...

New commit which enable the ''randomness" feature of Edax is online. New release containing all checkpoints is online.

I can make PR into your repo with those improvements if you believe this is worthy.

Of course. Thank you so much.

I'm just a bit disappointed that it's a lot weaker than I wished it would have been.

I totally agree with you. I don't think othello-zero V117 or V067 is a invincible beast. Instead, othello-zero is a little baby. Alpha Zero trains itself to play Chess with over 40 million self-play games. For othello-zero, the number is only 0.2 million(V117). 200 times larger. It will take me about five years to complete the whole training, on my personal computer.
If I have enough computing power, I want to change some config, and rewrite part of train-loop code. Make othello-zero’s algorithm more robust. V117 should have been stronger than V067.


[CHANGELOG] Update the content of the changelog following recent code changes (since 3.5.0)

Merged


dunit.toolkit.assert* functions not @nogc

I'm writing a library which needs to have @safe @nogc pure nothrow API. To ensure this, I annotate my unittests with those attributes, however this currently means that I can't use dunit.toolkit in those unittests.

One possible way to do this may be to pre-allocate an array of records for each unittest. Inside the assert* functions the code will then fill the corresponding record for the current unittest. After the test runner finishes it will iterate through the elements of the array and perform string formating as needed.
A different strategy is to use ref-counted objects, but that seems even more involved for the scope of this project, considering that currently phobos provides little support for this style of memory management.
A third option is to use fibers or ranges to separate the code that needs to allocate memory from code that just checks the assert* functions parameters.

To clarify about my idea to use fibers - instead of throwing DUnitAssertError, you can fiber.yield() directly to the code that is supposed to catch the exception


obsolete podocyte foot process (UBERON term)

For some reason the UBERON term 'podocyte foot process' UBERON:0004355 is showing as 'obsolete podocyte foot process' when displayed in OLS see https://www.ebi.ac.uk/ols/ontologies/mp/terms?iri=http%3A%2F%2Fpurl.obolibrary.org%2Fobo%2FUBERON_0004355
Checking the MP-edit.owl file and the UBERON file in OLS (https://www.ebi.ac.uk/ols/ontologies/doid/terms?iri=http%3A%2F%2Fpurl.obolibrary.org%2Fobo%2FUBERON_0004355) this doesn't appear to be an obsolete term so I'm not sure what is happening here.
This UBERON term is used in 3 MP terms (MP:0008059, MP:0008139, MP:0008138)

It is indeed obsolete in uberon, replaced by GO:0098846 ! podocyte foot
The reason it doesn't show in MP is probably because the import module needs to be refreshed. @drseb @balhoff we should meet sometime and discuss the best strategy for keeping this synchronized.
btw, there is a new command in robot, once the import module is refreshed you can do
robot repair -i mp-edit.owl -o mp-edit-repaired.owl

this will use replaced by (but not consider) to update. I'd be careful with this at first as it's a new command and hasn't been used much in the wild yet!

Can you suggest a Skype in January?

Sounds good to me. I was also wondering if there was a way to move a term into an import file if it was accidentally saved saved in the MP file? I've noticed a few of these and would like to move them into the correct place and was wondering if there was a way to do this other than deleting and re-adding the term.

Given that this involves only 3 MP terms I just fixed the definitions to use the GO term


[CLI-229] Fix for self.method.remote calling FunctionBindParams in containers

Note This only fixes the special case of un-parameterized classes calling stuff on self when they could simply use the class servicer function as is done when using the class locally.
To fix the general case, we'd need to add a way to hydrate parameter-bound instances of classes ("instance service functions") using the container args or similar.
The root cause of the problem was that when used in side containers, the class isn't hydrated at import time when the "self" is created (unlike when it's used in an active app locally). This means that when the Cls is instantiated (in get_user_class_instance) it doesn't trigger the short-circuit logic in _bind_parameters which prevents FunctionBindParams for parameter-less functions. This simple patch moves that short-circuit logic into the _load function instead.

@prbot approve


Following this tutorial in Visual Studio 2019 on Windows

Hi,
you say "The steps provided are specific to Visual Studio for Mac, but the structure works in Visual Studio 2017 as well."
However, Step 2 of Stage 2 requires
"From the New Project window, choose Shared Project (from within Multiplatform > Library) and then click Next"
What is the equivalent of the C# Shared Project  in Multiplatform | Library in Visual Studio 2019?
Under C#, All Platforms, Library there is no shared library.
Please can you include explicit instructions for Visual Studio 2019?
Thank you.

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

ID: e40fbe03-a099-3b24-4654-162103003d6a
Version Independent ID: 01e8c667-ed94-7054-758d-2399e879714a
Content: Use C/C++ libraries with Xamarin - Xamarin
Content Source: docs/cross-platform/cpp/index.md
Product: xamarin
Technology: xamarin-crossplatform
GitHub Login: @mikeparker104
Microsoft Alias: miparker

Thanks for submitting an issue and we apologize for the delayed response. The requested updates haven't been made since the creation of the issue, and the timeline for resolution may vary based on resourcing, so the issue is being moved to an internal repo to better track it.


Tilestrata hangs up on vector layer when fed with incorrect coordinates

Hello,
The tilestrata serve hangs when incorrect (out of range) coordinates are requested. Say, the request is: http://<IP_ADDRESS>:8080/vtile/8/17927/10954/t.pbf. The values for x and y are way too high and as a result server outputs:
/home/osmdebian/node/osm-server/node_modules/tilestrata-vtile/backend.js:119
                map.render(new mapnik.VectorTile(z, x, y), options, function(err, image) {
                           ^

TypeError: required parameter x is out of range of possible values based on z value
    at TypeError (native)
    at /home/osmdebian/node/osm-server/node_modules/tilestrata-vtile/backend.js:119:14
    at /home/osmdebian/node/osm-server/node_modules/tilestrata-vtile/node_modules/mapnik-pool/node_modules/generic-pool/lib/generic-pool.js:291:11
    at loaded (/home/osmdebian/node/osm-server/node_modules/tilestrata-vtile/node_modules/mapnik-pool/index.js:27:28)

Sometimes it exits with error and sometimes hangs so severely it can't be killed with SIGTERM, only SIGKILL does the job.
Interestingly, the problem doesn't show up when requesting raster tiles. In that case I end up with message "http://<IP_ADDRESS>:8080/rtile/8/17927/10954/t.png image cannot be shown because it contains errors" (I believe it is correct translation).
In my app I resolved this problem with a request hook:
// lib/inputValidator.js
var rValidator = require('validator');

module.exports = function(options) {
    return {
        name: 'coordChecker',
        reqhook: function(server, tile, req, res, callback) {
            var max = Math.pow(2,tile.z);
            if (rValidator.isAlphanumeric(tile.layer + '') &&
                rValidator.isInt(tile.x + '', {'min': 0, 'max': max, 'allow_leading_zeroes': false}) &&
                rValidator.isInt(tile.y + '', {'min': 0, 'max': max, 'allow_leading_zeroes': false}) &&
                rValidator.isInt(tile.z + '', {'min': 0, 'max': 24, 'allow_leading_zeroes': false})
                ) {
            console.log('Served '+tile.layer+'/'+tile.z+'/'+tile.x+'/'+tile.y);
            callback();
            } else {
                console.log();
                console.log(rValidator.isAlphanumeric(tile.layer + ''));
                console.log(rValidator.isInt(tile.x + '', {'min': 0, 'max': max, 'allow_leading_zeroes': false}));
                console.log(rValidator.isInt(tile.y + '', {'min': 0, 'max': max, 'allow_leading_zeroes': false}));
                console.log(rValidator.isInt(tile.z + '', {'min': 0, 'max': 24, 'allow_leading_zeroes': false}));
            }
        }
    };
};

For validation I use Validator.
This does the job but I really think that end-user shouldn't have the possibility to crash the server in such a way and such protection should be included in the Tilestrata itself. I don't know if it should go to tilestrata or tilestrata-vtile though.

Thanks for the detailed report @forsetius! I think this should be implemented at the tilestrata level. I'll try to get this patched up in the next few days and will let you know. I can't really speak to mapnik throwing / hanging... it shouldn't behave like that. Ideally it'd just return an error to the callback.

Any update on this?


Remove Cask developer scripts.

Moved them back in https://github.com/caskroom/homebrew-cask/pull/23920 as most of them are meant to be run from within the Tap root.

Thanks @reitermarkus!


Default npartitions  for parquet with fastparquet and parquet with pyarrow are incorrect

When reading the same data in 1) csv format 2) parquet format using fastparquet and 3) parquet using pyarrow, the following default npartitions were allocated by dask:
fastparquet version 0.3.2
 dask version 2.2.0
 pyarrow version 0.14.0`

count 15245673
csv partitions: 9
parquet npartitions pyarrow: 1
parquet npartitions fastparquet: 477

The data file contains 2 columns, 15M rows , Approx 540MB on disk in csv format. Parquet file  created by dotnet parquet 3.3.4
The code to reproduce is simply the following:
print(f' fastparquet version {fp.__version__}')
print(f' dask version {dask.__version__}')
print(f' pyarrow version {pyarrow.__version__}')

dfpq = ParquetFile(f_bug_pq)
print(f'count {dfpq.count}')
dddf = dd.read_csv(f_bug_csv)
print(f'csv partitions: {dddf.npartitions}')
for engine in ['pyarrow', 'fastparquet']:
    dddf = dd.read_parquet(f_bug_pq, engine=engine)
    print(f'parquet npartitions {engine}: {dddf.npartitions}')

I can upload input file if required!
thanks

@martindurant, if you are around, would you be able to take a look?

@telferm57 it's unlikely that your exact CSV file is needed to reproduce the problem. Can you provide  minimal example? http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports. Otherwise, it's hard to know where to start looking.

unfortunately minimum example is a file > 64M to provoke the behaviour - file is generated by parquet.dot-net , so I cannot generate it in code.

Unfortunately I cannot get the files compressed below 10MB, which seems to be the limit here

You don't need to share a file (indeed, please don't share a file), but
rather a minimal process to create such a file and generate the error.  You
might want to read through the blogpost linked to above.
On Wed, Aug 21, 2019 at 4:35 AM Malcolm<EMAIL_ADDRESS>wrote:

Unfortunately I cannot get the files compressed below 10MB, which seems to
be the limit here
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/dask/dask/issues/5295?email_source=notifications&email_token=AACKZTDGYQJOQ2QQICFOPV3QFUSB7A5CNFSM4INDZGRKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4ZLUHY#issuecomment-523418143,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AACKZTDF5FMDGUOGWEIASDDQFUSB7ANCNFSM4INDZGRA
.

(unfortunately the process to create the file is happening in c#/.net)
I have been debugging my end ... what seems to be happening is that by default fastparquet is setting the number of partitions to the number of row groups. This has been set very small in the file producing software (32k records per row group) . so for a file with only 2 columns in , this is producing 96 row groups for a 100MB file. I'm not sure what pyarrow does yet.
When I repartition to a more sensible partition size of 64MB , using npartitions = 8, The number of partitions is 8, but the  number of tasks is still 104 ... I'm guessing per row-group ? Ideally I assume we'd like 1 task per partition?

When engine='pyarrow', the number of partitions in the dask dataframe is set to the number of divisions -1 . The number of divisions is the number of parts + 1. In this case, we have one file, so npartitions is set to (1 + 1 -1) = 1, whatever the size of the file. Both pyarrow and fastparquet engines induce undesirable behaviour, it seems to me.

@telferm57 , what do you think the behaviour ought to be? Remember, you can always repartition the dataframe before calling to_parquet.

I think there should be a consistent number of partitions using the same data ... at the moment csv, fastparquet and pyarrow produce different results , with csv the only 'sensible one'
repartitioning - with fastparquet, this still leaves a vast number of tasks in the graph (1800 or so) , which when you attempt to write the file back using to_parquet, results in 1800 v. small files


Add "plus" damage to non-crit damage

A couple of the attacks on this create have "plus 2d6 cold" in the parens that are ignored. Since they're cold, it would be nice if they could be added into the "non crit damage formula" on attacks (also any other energy damage and precision damage if those are found). This info was also excluded from the Attack Notes on the attack details.
Melee 2 claws +22 (2d6+6 plus 2d6 cold), 2 chains +22 (1d8+6)
Ranged 4 icicles +23 (1d8+6/19–20/×3 plus 2d6 cold)

Originally posted by @Lavaeolous in https://github.com/Lavaeolous/PF1-StatBlock-Converter-Module/issues/391#issuecomment-829894779

Added in 3.1.4


Add support for relaxed phylip format

I have tried to read in a relaxed phylip file
phy = "/home/claudi/Downloads/transferaln/d6c90min85.phy"
ph.read_phylip(phy, alphabet='dna')

and received the following error:
ValueError                                Traceback (most recent call last)
<ipython-input-20-a4772c832ebb> in <module>()
      1 phy = "/home/claudi/Downloads/transferaln/d6c90min85.phy"
      2
----> 3 ph.read_phylip(phy, alphabet='dna')

~/SciPy2018/Sprints/phylopandas/phylopandas/seqio/read.py in func(filename, seq_label, alphabet, use_uids, **kwargs)
    133             alphabet=alphabet,
    134             use_uids=use_uids,
--> 135             **kwargs
    136         )
    137     # Update docs

~/SciPy2018/Sprints/phylopandas/phylopandas/seqio/read.py in _read(filename, schema, seq_label, alphabet, use_uids, **kwargs)
     76
     77     # Parse Fasta file.
---> 78     for i, s in enumerate(SeqIO.parse(filename, format=schema, **kwargs)):
     79         data['id'].append(s.id)
     80         data[seq_label].append(str(s.seq))

~/miniconda2/envs/phylopandas/lib/python3.6/site-packages/Bio/SeqIO/__init__.py in parse(handle, format, alphabet)
    635             raise ValueError("Unknown format '%s'" % format)
    636         # This imposes some overhead... wait until we drop Python 2.4 to fix it
--> 637         for r in i:
    638             yield r
    639

~/miniconda2/envs/phylopandas/lib/python3.6/site-packages/Bio/SeqIO/__init__.py in <genexpr>(.0)
    629         elif format in AlignIO._FormatToIterator:
    630             # Use Bio.AlignIO to read in the alignments
--> 631             i = (r for alignment in AlignIO.parse(fp, format,
    632                                                   alphabet=alphabet)
    633                  for r in alignment)

~/miniconda2/envs/phylopandas/lib/python3.6/site-packages/Bio/AlignIO/__init__.py in parse(handle, format, seq_count, alphabet)
    380         # TODO: As of Python 3.3, can write "yield from i" instead. See PEP380.
    381         # For loop imposes some overhead... wait until we drop Python 2.7 to fix it.
--> 382         for a in i:
    383             yield a
    384

~/miniconda2/envs/phylopandas/lib/python3.6/site-packages/Bio/AlignIO/PhylipIO.py in __next__(self)
    269                              id=i, name=i, description=i)
    270                    for (i, s) in zip(ids, seqs))
--> 271         return MultipleSeqAlignment(records, self.alphabet)
    272
    273

~/miniconda2/envs/phylopandas/lib/python3.6/site-packages/Bio/Align/__init__.py in __init__(self, records, alphabet, annotations, column_annotations)
    182         self._records = []
    183         if records:
--> 184             self.extend(records)
    185             if alphabet is None:
    186                 # No alphabet was given, take a consensus alphabet

~/miniconda2/envs/phylopandas/lib/python3.6/site-packages/Bio/Align/__init__.py in extend(self, records)
    543
    544         for rec in records:
--> 545             self._append(rec, expected_length)
    546
    547     def append(self, record):

~/miniconda2/envs/phylopandas/lib/python3.6/site-packages/Bio/Align/__init__.py in _append(self, record, expected_length)
    606             # raise ValueError("New sequence is not of length %i" \
    607             #                 % self.get_alignment_length())
--> 608             raise ValueError("Sequences must all be the same length")
    609
    610         # Using not self.alphabet.contains(record.seq.alphabet) needs fixing

ValueError: Sequences must all be the same length

I have checked the file, and all sequences are the same length. However the names of the samples are longer than 10 characters, making this a relaxed phylip file.
I would like to see relaxed phylip added as a supported fromat. Thank You.

Thank you @ClaudiaPaetzold!
I totally agree! We need a relaxed phylip format. Would you like to work on that? I can help you with the PR. If not, I don't mind adding it myself.


TypeScript type declaration file

If you want I can write a TypeScript type declaration file for this package so that TS developers can utilise the type-checking feature of the language as they use this package. Let me know if you are interested.

@geopic, Please add. I appreciate your contribution.

I'll get started on it now then.


Training failed

Hello! Can you please help how I can fix this error?
Epoch 1: : 0batch [00:00, ?batch/s]

Traceback (most recent call last):
  File "tasks/run.py", line 15, in <module>
    run_task()
  File "tasks/run.py", line 10, in run_task
    task_cls.start()
  File "/home/jovyan/nfs/ai-arseny/DiffSinger/tasks/base_task.py", line 257, in start
    trainer.fit(task)
  File "/home/jovyan/nfs/ai-arseny/DiffSinger/utils/pl_utils.py", line 580, in fit
    self.run_pretrain_routine(model)
  File "/home/jovyan/nfs/ai-arseny/DiffSinger/utils/pl_utils.py", line 673, in run_pretrain_routine
    self.train()
  File "/home/jovyan/nfs/ai-arseny/DiffSinger/utils/pl_utils.py", line 1448, in train
    self.run_training_epoch()
  File "/home/jovyan/nfs/ai-arseny/DiffSinger/utils/pl_utils.py", line 1482, in run_training_epoch
    output = self.run_training_batch(batch, batch_idx)
  File "/home/jovyan/nfs/ai-arseny/DiffSinger/utils/pl_utils.py", line 1604, in run_training_batch
    loss = optimizer_closure()
  File "/home/jovyan/nfs/ai-arseny/DiffSinger/utils/pl_utils.py", line 1569, in optimizer_closure
    output = self.training_forward(
  File "/home/jovyan/nfs/ai-arseny/DiffSinger/utils/pl_utils.py", line 1678, in training_forward
    output = self.model.training_step(*args)
  File "/home/jovyan/nfs/ai-arseny/DiffSinger/tasks/base_task.py", line 128, in training_step
    loss_ret = self._training_step(sample, batch_idx, optimizer_idx)
  File "/home/jovyan/nfs/ai-arseny/DiffSinger/usr/task.py", line 57, in _training_step
    log_outputs = self.run_model(self.model, sample)
  File "/home/jovyan/nfs/ai-arseny/DiffSinger/usr/diffsinger_task.py", line 299, in run_model
    output = model(txt_tokens, mel2ph=mel2ph, spk_embed=spk_embed,
  File "/opt/conda/envs/diffsinger_mooninriver/lib/python3.8/site-packages/torch/nn/modules/module.py", line 722, in _call_impl
    result = self.forward(*input, **kwargs)
  File "/home/jovyan/nfs/ai-arseny/DiffSinger/usr/diff/shallow_diffusion_tts.py", line 236, in forward
    ret = self.fs2(txt_tokens, mel2ph, spk_embed, ref_mels, f0, uv, energy,
  File "/opt/conda/envs/diffsinger_mooninriver/lib/python3.8/site-packages/torch/nn/modules/module.py", line 722, in _call_impl
    result = self.forward(*input, **kwargs)
  File "/home/jovyan/nfs/ai-arseny/DiffSinger/modules/diffsinger_midi/fs2.py", line 63, in forward
    midi_dur_embedding = self.midi_dur_layer(kwargs['midi_dur'][:, :, None])  # [B, T, 1] -> [B, T, H]
  File "/opt/conda/envs/diffsinger_mooninriver/lib/python3.8/site-packages/torch/nn/modules/module.py", line 722, in _call_impl
    result = self.forward(*input, **kwargs)
  File "/opt/conda/envs/diffsinger_mooninriver/lib/python3.8/site-packages/torch/nn/modules/linear.py", line 91, in forward
    return F.linear(input, self.weight, self.bias)
  File "/opt/conda/envs/diffsinger_mooninriver/lib/python3.8/site-packages/torch/nn/functional.py", line 1676, in linear
    output = input.matmul(weight.t())
RuntimeError: CUDA error: CUBLAS_STATUS_EXECUTION_FAILED when calling `cublasSgemm( handle, opa, opb, m, n, k, &alpha, a, lda, b, ldb, &beta, c, ldc)`

Are your CUDA drivers compatible?


WIP: Add 'brute' option for searchsorted

I still want to run some benchmarks before merging this...

Done in #14836


Interaction concept for Toast & Snackbar

Currently the difference between Snackbar, Toast are not really big. We have to create a concept where those elements can be used and how they are implemented.
Design

@clastzoo please define ticket

Might be clever to re-think this ticket after go-live.

moved to https://github.com/baloise/design-system/issues/789