Generalized Resolver

Description of change
This PR introduces a generalized Resolver adapted to handle the new UTXO method and also provides a plug-in system enabling resolution of multiple DID methods.
The main purpose of this new Resolver is to make it more convenient to verify presentations possibly containing credentials issued by issuers of different DID methods.
The Rust API for the new Resolver
This section aims to give a high level(-ish) overview of the user facing aspects of the new Resolver. We therefore try to explain the new/changed methods through concrete examples (some admittedly more realistic than others).
Construction
Let us start with explaining how one constructs a new resolver.
Example: Constructing a resolver that resolves DID documents of type CoreDocument
use identity_resolver::Resolver;
use identity_did::document::CoreDocument;
let mut resolver = Resolver::<CoreDocument>::new();

Example: Constructing a Resolver that is agnostic about DID Document types.
use identity_resolver::Resolver;
let mut resolver: Resolver = Resolver::new();

As the first example illustrates the Resolver is generic over the document type it resolves. The output type is bounded by the ValidatorDocument trait which means that it can be used in the context of Credential and or Presentation validation. What is meant by "agnostic about DID Document types" in the second example will be covered in more detail later, but it is essentially a type erased document that provides great flexibility when validating presentations.
Attaching handlers
A Resolver will only be able to resolve DID documents for methods it has been configured for. In the case of the new UTXO iota method we provide a convenience method which essentially only requires the user to pass a preconfigured Client.
Example: Configuring the resolver to handle the iota method.
 // Configure a client for the Shimmer testnet "rms".
    let node_url = "https://api.testnet.shimmer.network/";
    let client = Client::builder().with_primary_node(node_url, None).unwrap().finish().unwrap();
    // Construct a resolver using the client.
    let mut resolver = Resolver::<StardustDocument>::new();
    resolver.attach_iota_handler(client);

In this example the resolver produces StardustDocuments, but we could have used any other document type as long as it satisfies From<StardustDocument>.
To configure the resolver to handle an arbitrary DID method (including iota) one uses the Resolver::attach_handler method. This method takes an asynchronous function or closure taking an owned DID and returning any document type that can be converted into the output type of the resolver (for example CoreDocument if we have a Resolver<CoreDocument>).
Example: Configuring a resolver to handle the foo method:
use identity_resolver::Resolver;
use identity_did::did::CoreDID;
use identity_did::document::CoreDocument;

async fn resolve_foo(did: CoreDID) -> std::result::Result<CoreDocument, std::io::Error> {
  todo!()
}

let mut resolver: Resolver = Resolver::new();

resolver.attach_handler("foo".to_owned(), resolve_foo);

In this example we used the DID Document type agnostic resolver which we saw could be configured to handle the foo method with using resolve_foo as the handler function. This works because essentially all DID documents (implementing the Document trait) can be converted to the abstract output type.
Attaching a closure is arguably a little more involved, but also more powerful. This unlocks many possibilities for the consumers of the IOTA Identity framework in terms of how a Resolver will ultimately resolve methods they are interested in.
Example: Attaching a customized iota method handler
use identity_resolver::Resolver;
use identity_stardust::StardustDID;
use identity_stardust::StardustDocument;
use identity_stardust::StardustIdentityClientExt;
use iota_client::Client;
use std::sync::Arc;
use std::time::Duration;

// Setup the client
let node_url = "https://api.testnet.shimmer.network/";
let client = Client::builder()
  .with_primary_node(node_url, None)
  .unwrap()
  .finish()
  .unwrap();

// Create an atomic reference counted pointer to the client for cheap cloning.
let client_ptr = Arc::new(client);

// Construct our custom `iota` method resolution handler
let iota_handler = move |did: StardustDID| {
  let client_clone = client_ptr.clone();
  async move {
    let doc_fut = client_clone.resolve_did(&did);
    match tokio::time::timeout(Duration::from_millis(250), doc_fut).await {
      Ok(resolution_result) => resolution_result.map_err(Box::<dyn std::error::Error + Send + Sync + 'static>::from),
      Err(_) => return Err(format!("could not resolve DID: {} within 250ms", did).into()),
    }
  }
};

let mut resolver = Resolver::<StardustDocument>::new();
resolver.attach_handler("iota".to_owned(), iota_handler);

Resolving a DID Document
Resolving a DID is as simple as calling Resolver::resolve. This method takes as input a reference to any implementer of the DID trait and returns the output type of the resolver. When the output type of the resolver is abstract one can also tempt to cast the resolved document into a concrete type by first calling its into_any to (essentially) obtain a Box<dyn Any> which one can then attempt to downcast.
The resolver also comes with convenience methods for resolving the DID Documents of a presentation holder and the issuers of credentials in the given presentation, in a similar fashion to the old resolver.
Verifying a presentation
Similarly to the old resolver this one can also verify presentations. If one wishes to pass in the DID Document of the holder and/or credential issuers to avoid resolving them (if one already happens to possess up to date versions of said documents) then this can be done like before, but they are now required to be of the same type as the output type of the resolver instead of &dyn ValidatorDocument. This is to let users directly pass in documents they have got from Resolver::resolve_presentation_holder and/or Resolver::resolve_presentation_issuers while retaining decent type inference when passing in None.
Errors
All fallible methods on the new Resolver return the same error type identity_resolver::Error which has two essential methods:
error_cause and action. The former of these returns an enum describing the cause of the error, while the latter gives more context regarding exactly what the resolver was trying to do when the error occurred. The latter is mainly useful when verifying presentations as a verifier may want to inform a user about which credential in the presentation they were given that contained an unresolvable issuer DID.
SingleThreadedResolver
The Resolver mentioned so far is actually Send + Sync which means that the handlers must also satisfy these bounds. This is often the case when working in Rust alone, but not the case when taking handlers from a single threaded language. Hence there is also a single threaded version of the resolver aliased SingleThreadedResolver. Most of its API is identical to the standard Resolver, but with less strict requirements on the handlers. The convenience method attach_iota_handler is not implemented for SingleThreadedResolver however. This is not a huge limitation as 1) One can still configure it to handle the iota method with the more general attach_handler method, and 2) The expectation is that the single threaded resolver is not the "go to" resolver for the consumers of the Rust library, but is mainly there for us when building the bindings and anyone else who wants to for instance write third party bindings to single threaded languages or need to work in a single threaded context for other reasons.
The implementation of the single threaded resolver is mostly shared with the standard resolver using generics which will be discussed in more detail later.
The (current) Typescript API for the new Resolver
The Typescript API for the new resolver is in many ways similar to the Rust version, but there are some important differences.
For technical reasons all configuration needs to be done in the constructor in TS/JS. Hence we have a typescript interface:
export type ResolverConfig = {

    /**
     * Client for resolving DIDs of the iota method.
     */
    client?: IStardustIdentityClient,

    /**
     * Handlers for resolving DIDs from arbitrary DID methods.
     *
     * The keys to the map are expected to match the method name and the values are asynchronous functions returning DID documents.
     *
     * Note that if a `client` is given the key "iota" may NOT be present in this map.
     */
    handlers?: Map<string, (did: string) => Promise<StardustDocument | CoreDocument>>
};

which is passed to the constructor of the resolver (currently called MixedResolver, which is a temporary name until we can delete the old Resolver from the bindings).
Note that in JS/TS handlers are functions that take a string representation of a DID and returns either a StardustDocument or a CoreDocument. Users may still validate DIDs before attempting to resolve them by adding logic for this inside their handlers.  The output type StardustDocument | CoreDocument is somewhat less general than the Rust version. We will do our best to make this more general in the close future (see the next section).
It would technically be possible to make the configuration API more similar to how it is in Rust (i.e. having separate methods for attaching general handlers and the iota client as a handler), but this would (to the best of my knowledge) either come at the cost of greater potential for run time panics, or involve loads of additional complexity in the code. The IOTA Identity resolver working group agreed that this is the way to go for now.
How to generalize the Typescript API in the close future
If/when we port a version of the Document trait (or possibly the ValidatorDocument trait) as an interface to TS/JS it should be possible to use the duck-typed interface trick in wasm-bindgen to make the resolver return a document interface on the JS/TS side. We could also possibly introduce a DID interface as well so that handlers could take that as their input argument instead of a string representation.  The exact details of this is beyond the scope of this PR, but I believe there are no/few limitations in the current (Rust) design in terms of making a more general resolver for TS/JS a reality.
Why callback functions?
Earlier versions of the new Resolver had a configuration API that was more similar to the identity_agent::Agent. There was a trait ResolutionHandler<D: DID> which one would implement for one's client and then it would be registered with the resolver. In the end I decided against going with this design for the following reasons:

I could not come up with a good way to represent this in TS (that Rust can reason about). It would probably end up involving something somewhat stringly typed and possibly far from idiomatic for typescript users. Maybe @PhilippGackstatter would know a neat way of doing this though.
When writing tests I discovered that the design interacted worse with type inference than I had hoped.
I found it less convenient to test because of the additional setup it involves. This is admittedly not the best argument, there are some cases where using a configured trait can be more convenient than needing to re-create the same closure time and time again. I don't think this applies to the resolver though as I expect it to be set up only a few places throughout an application/code base.

After figuring out that passing in asynchronous functions/closures from JS/TS would not create a very awkward API on the JS/TS side I briefly looked into to which extent this is supported with bindings generators for other languages we might want to support. From my findings it should also be possible with PyO3 (see the last example in this section from the docs), but there may of course be other languages with less infrastructure for this kind of thing. Even though that might be the case there is (to the best of my knowledge) not much reason to believe that using a parametrized trait in Rust will make things easier.  Hence I decided to proceed with a callback based API using the Command pattern in a somewhat similar fashion to actix-web's URL-dispatch (see also Route::to).
NOTE: The key take away here should NOT be "the configuration API for the Agent is bad", but rather the equivalent for the resolver does not seem to be optimal.
The design in more detail
This is the actual definition of the Resolver:
pub struct Resolver<DOC = AbstractThreadSafeValidatorDocument, CMD = SendSyncCommand<DOC>>
where
  CMD: for<'r> Command<'r, Result<DOC>>,
  DOC: ValidatorDocument,
{
  command_map: HashMap<String, CMD>,
  _required: PhantomData<DOC>,
}

The default parameters makes it possible for users to specify at most the type of document with turbofish when constructing a new resolver. The first first of these parameters specifies the output type of the resolver, i.e. the exact type of document it resolves i.e. CoreDocument, StardustDocument etc. (the default AbstractThreadSafeValidatorDocument will be explained shortly). The second parameter is what enables having a resolver satisfying Send + Sync or not. Note that the Command trait cannot be named outside of the defining crate (which can be seen in the docs generated by cargo doc) hence users will not interact with this second parameter. There is however an exposed type alias which enables users to obtain a resolver with less strict constraints on its handlers:
pub type SingleThreadedResolver<DOC = AbstractValidatorDocument> = Resolver<DOC, SingleThreadedCommand<DOC>>;

The default DOC type AbstractThreadSafeValidatorDocument is a wrapper around Box<dyn ThreadSafeValidatorDocuments "= ValidatorDocument + Send + Sync"> (remove "ThreadSafe" for the single threaded equivalent).  I originally wanted it to be Box<dyn AbstractThreadSafeValidatorDocument> directly, but it needs to both satisfy the From<DOCUMENT: Document> and ValidatorDocument trait bounds which quickly leads to problems with the orphan rules. It is possible to work around this (something I initially did), but it involves introducing one more trait for Credential/Presentation validation which I considered not to be worth it.
Is the ability to opt-in to guaranteed Send + Sync bounds on the Resolver worth the additional complexity?
We have (briefly) discussed whether the complexity that comes with the second parameter CMD on the Resolver is justified given what it provides. Indeed resolving DID documents is typically mostly an IO bound task and executors are fairly good at scheduling this on a single thread.
Here are some arguments I can think of in in favour of not removing the CMD parameter in the Resolver:

The complexity is (essentially) not user facing. In fact the public API would not change if we made it single threaded only (or only Send + Sync for that matter).
Without Send + Sync bounds on the resolver it cannot be attached as a handler to an Agent (see AgentBuilder::attach).
We would probably have to keep the AbstractThreadSafeValidatorDocument struct anyway, because not being able to send validator documents across threads is quite restrictive.

As a counter argument to the second point one could argue that the agent typically expects more specialized handlers (than a resolver capable of resolvijng arbitrary methods), but that might be something for the consumers of the IOTA Identity framework to decide for themselves. I must also admit that I have not thought about if or how the Agent could would work with an AbstractThreadSafeValidatorDocument as a response to a request.
If there are any ideas to support the optionally guaranteed Send + Sync bounds in a simpler way that is of course also appreciated. In this regard I also considered macros and feature-gating, but I don't really think using macros makes things simpler and feature-gating should be additive so I discarded those options.
Tests
The Rust tests don't test SingleThreadedResolver which I expect is fine since most of the logic is shared and it is de-facto tested in the bindings. Note that the tests I wrote for the bindings are probably far from idiomatic JS/TS and would be happy to accept any suggestions for improvement.
Is this really a breaking change?
Possibly not, but the intention is to remove the old resolver in the close future and this will be its replacement. Feel free to change the labels if one desires to do so.
Giving credit where credit is due
I want to thank @cycraig  for creating the task of generalizing the Resolver and getting me started on this topic. I also want to thank the IOTA Identity resolver working group for discussions regarding API design as well @abdulmth for porting CoreDocument to the bindings and @PhilippGackstatter for implementing the attach_iota_handler method on the Resolver.
Links to any relevant issues
Subtask of #908
Type of change
Add an x to the boxes that are relevant to your changes.

[ ] Bug fix (a non-breaking change which fixes an issue)
[ ] Enhancement (a non-breaking change which adds functionality)
[x] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Documentation Fix

How the change has been tested
Describe the tests that you ran to verify your changes.
Make sure to provide instructions for the maintainer as well as any relevant configurations.
Change checklist
Add an x to the boxes that are relevant to your changes.

[x] I have followed the contribution guidelines for this project
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation
[x] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes

but they are now required to be of the same type as the output type of the resolver
Can you elaborate on that? Does this relate to "mixed" method credentials?

but they are now required to be of the same type as the output type of the resolver
Can you elaborate on that? Does this relate to "mixed" method credentials?

Yes, one is restricted to only be allowed to pass in documents of the same type the resolver can resolve. If more generality is needed one can use the PresentationValidator instead. This does not really make the new resolver's validation capabilities less powerful than the old as one can work with an abstract output (the default generic parameter) to work with arbitrary resolved documents.

but they are now required to be of the same type as the output type of the resolver
Can you elaborate on that? Does this relate to "mixed" method credentials?

One is now restricted to only be allowed to pass in documents of the same type the resolver can resolve. If more generality is needed one can use the PresentationValidator instead. This does not really make the new resolver's validation capabilities less powerful than the old as one can work with an abstract output (the default generic parameter) to support arbitrary resolved documents.

So if I would want to verify a Presentation with mixed methods, I would need to initialize the Resolver with a type encompassing all, or would that not be possible?

So if I would want to verify a Presentation with mixed methods, I would need to initialize the Resolver with a type encompassing all, or would that not be possible?

That would definitely be possible and is in fact the easiest way to initialize a resolver. One simply writes:
let mut resolver: Resolver = Resolver::new();


Add group_comment_signals flag to DBC output

Some more DBC output knobs to twiddle :)
Currently, comments are serialised as

Node comment 1
Node 1 message comment 1
Node 1 message comment n
Node comment 2
Node 2 message comment 1

This changes things to be

Node comment 1
Node comment 2
Node 1 message comment 1
Node 1 message comment n
Node 2 message comment 1

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

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

Totals

Change from base Build<PHONE_NUMBER>:
0.004%

Covered Lines:
7079

Relevant Lines:
7531

💛  - Coveralls

what's the point of this? (the result seems to be quite equivalent to me...)

I'm making a dbc formatter - cantools already has a wealth of ways to adjust how DBC files are serialised (signal order, attribute order, enum order, long name cutoffs), this just adds one more thing.

IMO we should strive to remove knobs if they are of limited use, not add new ones. In this particular case, the loaded database should even be identical, so I really don't see the point...

Alright, well, just to be clear: Are the previous knobs going to (eventually) be removed, or is it just a case of not adding new ones?

In the medium term, nothing existing will be removed, and even in the long term I'll only advocate to go after stuff which is has only esthetic effects on the produced output files (which, as far as I can see, is not much).
The reason why I'd like to limit options is that I'd like to keep cantools usable for the 98.5% of people who don't care about such things and forward the remaining people to tools like yours. (We can't possibly maintain this for each and every file format which we support.)

Ok! It's very understandable as a maintenance burden. I'll consider ways to decouple cantools output from my formatting steps.

if you publish your DBC-linter, we can mention it in the cantools README if you want...

Oh, that might be nice! It's very opinionated so far (and potentially even incompatible with some tools due to converting to Unix line endings), so I may have to consider whether to do a full release, or a "this is what is possible" gist that others can extend.

Closing for now, and hopefully I can revisit this later by publishing my formatter. Thanks for your patience explaining your reasoning!

thanks for your patience and understanding. don't let yourself be deterred to contribute in the future by this :)

Good news! I've been able to publish my formatter. Hopefully it explains why I've been asking for all these features :)
https://github.com/mon/dbc_format


dep: target-lexicon: 0.12.3 -> 0.12.12

Largely just additions of new targets and such, as well as support for serde.
I personally am motivated to make this change, as the downstream development we’re doing depends on the target added in 0.12.12.

Thanks! For cargo vet I've send a PR with the audit for this at https://github.com/bytecodealliance/wasmtime/pull/7380 and once that's landed you can rebase this on that and we can merge

Hmph, cargo vet is still failing in the CI, even though locally it works perfectly fine now :confused:

Apologies that's my bad, I opened https://github.com/bytecodealliance/wasmtime/pull/7391 to re-add the vet after I accidentally deleted it.
Note that cargo vet locally is probably automatically re-adding the entry, I think you'll need cargo vet --locked to reproduce the failure on CI


q.contentBlock() assumes _type of block

The _type of a PortableTextBlock does not necessarily have to be block:
https://github.com/portabletext/types/blob/e54eb24f136d8efd51a46c6a190e7c46e79b5380/src/portableText.ts#L24-L26
https://github.com/portabletext/react-portabletext/pull/54#issuecomment-1494724526
The current groqd source validates q.contentBlock() with z.literal("block"):
https://github.com/FormidableLabs/groqd/blob/5e69051c8f78a39780bbc64e50e1eda2d90f8b4a/packages/groqd/src/contentBlock.ts#L28
but maybe it should be z.string() instead.

That sounds reasonable. That should be an easy change, I'll try to get that pushed through.


Adding the paginator changes which were requested

solving #24

Looks good, but still few things aren't resolved:

The elided pages are not shown.

In the above image, we can see that some page numbers from the beginning are shown, then ... is shown and then few page numbers from the end are shown. Note that all these page numbers are clickable.
The mouse hover doesn't get changed to cursor.

Ok that should do all the changes. I also merged all the changes into one commit so it should be all in this one pull request.
Thanks again for pointing out the changes specifically

I will complete them in the morning it is night time here. I really appreciate you bringing these changes to me . Thanks for quick responses

I will complete them in the morning it is night time here. I really appreciate you bringing these changes to me . Thanks for quick responses

Thanks to you for working on these.


[tiff] Fix build on arm64-linux

What does your PR fix?
Fixes #18504. Might help also with other community triplets.

Which triplets are supported/not supported? Have you updated the CI baseline?
all, no

Does your PR follow the maintainer guide?
yes

If you have added/updated a port: Have you run ./vcpkg x-add-version --all and committed the result?
yes

More information:
libm.{so,a} is located in /usr/aarch64-linux-gnu/lib for Ubuntu, but this directory is not in the search list for find_library on arm64-linux. Instead of this patch to port tiff, it might make more sense to adjust vcpkg's toolchain setup in a way that makes the directory part of the search list.

@dg0yt ,Could you please take a look?
config-x64-windows-static-md-out.log

@JonLiu1993 IMO the error is unrelated.
Installing in D:/packages/kf5plotting_x64-windows-static-md/debug. Run D:/buildtrees/kf5plotting/x64-windows-static-md-dbg/prefix.sh to set the environment for KPlotting.
-- Looking for __GLIBC__
-- Looking for __GLIBC__ - not found
CMake Error at D:/installed/x64-windows-static-md/share/ECM/kde-modules/KDEClangFormat.cmake:67 (configure_file):
  No such file or directory
Call Stack (most recent call first):
  D:/installed/x64-windows-static-md/share/ECM/kde-modules/KDEFrameworkCompilerSettings.cmake:79 (include)
  CMakeLists.txt:15 (include)

Needs CI re-run.

/azp run

it might make more sense to adjust vcpkg's toolchain setup in a way that makes the directory part of the search list.

It seems a shame that CMake doesn't already handle this correctly; is the implication really that you can't "simply" build TIFF on Ubuntu arm64? Or is this in the cross-compilation case? (Still unfortunate -- but more understandable that it's less well trodden).

It seems a shame that CMake doesn't already handle this correctly; is the implication really that you can't "simply" build TIFF on Ubuntu arm64? Or is this in the cross-compilation case? (Still unfortunate -- but more understandable that it's less well trodden).

#18504 is specifically about cross compilation, I haven't tried aarch64 directly yet. Considering FindCMath.cmake is a custom find script bundled with libtiff, I don't see how CMake could handle this automatically, but as pointed out in https://github.com/microsoft/vcpkg/pull/18511#issuecomment-863496714 this could potentially also be addressed how the toolchain is set up.

I also used cross compilation. But I don't think it makes a difference. This might be an interplay of different factors:

CMake's find_library not looking into CMAKE_<LANG>_IMPLICIT_LINK_DIRECTORIES.
Tiff having issues with its (new) cmake build system. (I can't even build with the minimum required version of cmake.)
Ubuntu/Debian having a particular file system layout with regard to architectures.
Ubuntu/Debian/Linux packaging still prefering autotools over cmake.

I just tried a native build (actually Docker + QEMU, but that shouldn't matter) via VCPKG_FORCE_SYSTEM_BINARIES=1 ./vcpkg/vcpkg install tiff which worked, so it is a cross compilation issue only (but very relevant to me anyway, as QEMU is slow and space on my real device is severely limited)


"Invalid file magic" with falcon models

This happens every time I try to interact with a falcon model:
❯ ollama run falcon:40b
>>> hi
Error: invalid file magic

Hardware is Apple silicon with 96GB of RAM

What version of ollama are you using? Falcon support was added in 0.0.19. You can check with ollama --version. Make sure the server has also been restarted since the upgrade

I just ran ollama --version and it is 0.0.21. But then I ran ollama run falcon:40b and couldn't reproduce the bug. Probably the error was related to an earlier version of ollama that got updated.

That sounds right, this error message wasn't very good but it usually shows up when trying to run Falcon on an earlier Ollama version that does not support it. Marking this as resolved for now. Let us know if the issue comes back.


Prepare release 7.5.1

Update changelog
Bump version

Codecov Report

Merging #211 (5a3416a) into dev (db90794) will not change coverage.
The diff coverage is n/a.

:exclamation: Current head 5a3416a differs from pull request most recent head 2a5add8. Consider uploading reports for the commit 2a5add8 to get more accurate results

@@           Coverage Diff           @@
##              dev     #211   +/-   ##
=======================================
  Coverage   97.43%   97.43%
=======================================
  Files          63       63
  Lines        1249     1249
=======================================
  Hits         1217     1217
  Misses         32       32

Continue to review full report at Codecov.

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


[#465] Create composer version of WaterfallSkillBotDotNet - Auth scenario

Addresses # 465
Note: This PR depends on # XXX (SW 47) containing the base implementation of the ComposerSkillBotDotNet.
Description
This PR adds the Auth scenario to the ComposerSkillBotDotNet bot.
Detailed Changes

Added the AuthDialog dialog to implement the Auth scenario.

Testing
These images show the WaterfallHosBot connecting with the ComposerSkillBotDotNet and running the auth scenario.

Replaced by PR# 57


Python 3.6

GPflow and GPflowOpt seem to be entirely compatible with 3.6, this adds CI support for this version.

Codecov Report

Merging #23 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master      #23   +/-   ##
=======================================
  Coverage   99.61%   99.61%
=======================================
  Files           7        7
  Lines         523      523
=======================================
  Hits          521      521
  Misses          2        2

Continue to review full report at Codecov.

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


Improve staking E2E tests by adding a second validator

UI Version: 0.8.2
Description:
Currently the test only has one validator which wouldn't show problems that have to do with more then one validator being present.

Plan:

Start a 2nd node
Declare it to be a validator
Stake to 2nd node

how hard is to add a third one ? @faboweb

If we have the 2nd one setup, I think it is easy.

I'd go for 3 then if it's just a copy/paste

why? ^^

Not as straight forward as I though:

The 2nd validator needs to use different ports
We need to add the 2nd validator pubkey to the genesis
We need to declare our 1st node as a persistent_peer in the config.toml (unclear what ID is right now)


[17.09] Fix test run environment

Cherry pick:
❯ git cherry-pick -x -s -Xsubtree="components/engine" fff605c3b3557acf6bf793813d695fba59d7fa21
[fix_test_run_environment dff328c8a6] Fix a bad assumption
 Author: Daniel Nephin<EMAIL_ADDRESS> Date: Wed Sep 6 17:32:56 2017 -0400
 1 file changed, 1 insertion(+), 1 deletion(-)

NOTE: Was clean
Overview:
If the empty variable happens to be sorted to the end of the list then TrimSpace()
would remove it. Instead only strip the single trailing newline.
Signed-off-by: Daniel Nephin<EMAIL_ADDRESS>(cherry picked from commit fff605c3b3557acf6bf793813d695fba59d7fa21)
Signed-off-by: Eli Uriegas<EMAIL_ADDRESS>ping @dnephin @vieux @andrewhsu

Is this a legit failure @johnstep?
00:36:34.303 ----------------------------------------------------------------------
00:36:34.303 FAIL: docker_cli_run_test.go:70: DockerSuite.TestRunLookupGoogleDNS
00:36:34.303
00:36:34.303 docker_cli_run_test.go:75:
00:36:34.303     // nslookup isn't present in Windows busybox. Is built-in. Further,
00:36:34.303     // nslookup isn't present in nanoserver. Hence just use PowerShell...
00:36:34.303     dockerCmd(c, "run", testEnv.MinimalBaseImage(), "powershell", "Resolve-DNSName", "google.com")
00:36:34.303 c:/gopath/src/github.com/docker/docker/vendor/github.com/gotestyourself/gotestyourself/icmd/command.go:61:
00:36:34.303     t.Fatalf("at %s:%d - %s\n", filepath.Base(file), line, err.Error())
00:36:34.304 ... Error: at cli.go:33 -
00:36:34.304 Command:  d:\CI\CI-dff328c8a6\binary\docker.exe run microsoft/windowsservercore powershell Resolve-DNSName google.com
00:36:34.304 ExitCode: 1
00:36:34.304 Error:    exit status 1
00:36:34.304 Stdout:
00:36:34.304 Stderr:   Resolve-DNSName : google.com : DNS server failure
00:36:34.304 At line:1 char:1
00:36:34.304 + Resolve-DNSName google.com
00:36:34.304 + ~~~~~~~~~~~~~~~~~~~~~~~~~~
00:36:34.304     + CategoryInfo          : ResourceUnavailable: (google.com:String) [Resolv
00:36:34.304    e-DnsName], Win32Exception
00:36:34.304     + FullyQualifiedErrorId : RCODE_SERVER_FAILURE,Microsoft.DnsClient.Command
00:36:34.304    s.ResolveDnsName
00:36:34.304
00:36:34.304
00:36:34.304
00:36:34.304 Failures:
00:36:34.304 ExitCode was 1 expected 0
00:36:34.304 Expected no error
00:36:34.304
00:36:34.304
00:36:34.304
00:36:34.304 ----------------------------------------------------------------------

Certainly looks like one, but probably related to the host system. We've recently been seeing DNS issues with several of the Jenkins systems, but every time I go to check one, it's working.

good to merge I guess


Implement BulkConcurrentObservableCollection

Implement BulkConcurrentObservableCollection (reader-first) to make access to FilesAndFolders thread-safe
Add AddRange, InsertRange and RemoveRange for further optimization
Thanks to BulkConcurrentObservableCollection, there's no need of synchronization while accessing to FilesAndFolders anymore

Note: language resource changes are generated by compiler.
Fixes #3166

@hez2010 I'm getting duplicate/unsorted results when navigating to c:\windows\system32 ang hitting "refresh"

@hez2010 I'm getting duplicate/unsorted results when navigating to c:\windows\system32 ang hitting "refresh"

[@hez2010 bonus question: since now you have an "AddRange", "InsertRange", etc, could you use those instead of firing a Collection.Reset in EndBulkOperation? Would solve the "flashing" issue with gridview]

[@hez2010 bonus question: since now you have an "AddRange", "InsertRange", etc, could you use those instead of firing a Collection.Reset in EndBulkOperation? Would solve the "flashing" issue with gridview]

@gave92 Fixed in 017817d

@gave92 Fixed in 017817d

~[@hez2010 bonus question: since now you have an "AddRange", "InsertRange", etc, could you use those instead of firing a Collection.Reset in EndBulkOperation? Would solve the "flashing" issue with gridview]~ Nevermind, I don't think gridview/datagrid supports those?

Unfortunately both GridView and DataGrid don't support those bulk operations, so we have to fire a Reset in EndBulkOperation.

~[@hez2010 bonus question: since now you have an "AddRange", "InsertRange", etc, could you use those instead of firing a Collection.Reset in EndBulkOperation? Would solve the "flashing" issue with gridview]~ Nevermind, I don't think gridview/datagrid supports those?

Unfortunately both GridView and DataGrid don't support those bulk operations, so we have to fire a Reset in EndBulkOperation.

@hez2010 Can you resolve the merge conflicts?

@hez2010 Can you resolve the merge conflicts?

@yaichenbaum Done

@yaichenbaum Done

@hez2010 Thank you!

@hez2010 Thank you!


Cut New Release

Please cut a new release which includes #38 to support TH

Currently in Australia road tripping..maybe @rjalla can?
Sent from TypeApp
On Dec 10, 2016, 08:39, at 08:39, Chris Coffey<EMAIL_ADDRESS>wrote:

Please cut a new release which includes #38 to support TH
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/hdevtools/hdevtools/issues/46

Sorry for the delay, version <IP_ADDRESS> should be available on hackage and soon in stackage snapshots http://hackage.haskell.org/package/hdevtools

Thanks @ch1bo !


Add lowercased and underscored country description as an alias

Fixes #22

On second thought, I think it'd be better to have a way to check tags along with aliases when searching. I'll update this PR.


SoundRecorder Shows Error 802 - Cannot start recording, impacts CoolThink curriculum

Describe the bug
When SoundRecorder is used, it shows Error 802 - Cannot start recording: ENOENT (No such file or directory).
Guess it's a directory issue for Android 10+
Affects

Compiled app shows error and cannot record sounds.

Expected behavior
I expect the SoundRecorder to record sound but error comes up.
Steps to reproduce
Use the SoundRecorder.

Fixed by #2713


How to parse the query string?

Please use the following questions as a guideline to help me answer
your issue/question without further inquiry. Thank you.
Which version of Elastic are you using?
[*] elastic.v7 (for Elasticsearch 7.x)
[ ] elastic.v6 (for Elasticsearch 6.x)
[ ] elastic.v5 (for Elasticsearch 5.x)
[ ] elastic.v3 (for Elasticsearch 2.x)
[ ] elastic.v2 (for Elasticsearch 1.x)
Please describe the expected behavior
For some reason, I need to replace a field in the query string to another field.
q=name:"foo" -> q=name_alias:"foo"
The function elastic.NewQueryStringQuery(q) didn't parse the query string into split fields.
Is there any function can do this?
Please describe the actual behavior
Any steps to reproduce the behavior?
elastic.NewQueryStringQuery(name:"foo")

This library is for interacting with Elasticsearch directly. If you need to modify the query string before sending it to Elasticsearch, you have to do so in your code.
As to the NewQueryStringQuery (and other questions regarding usage), feel free to browse the tests. Here are the tests for NewQueryStringQuery.


[FR] rerecord and make sure we catch non-flaky tests

Makes sure all recordings point to 2023-02-28-preview and that we raise if a test fails due to a non-flaky reason.

API change check
API changes are not detected in this pull request.


Upgrade dependencies versions

Notably a bugfix release of Leaflet.
Demo with this PR: https://gh.dev.bikewm.com/

Thanks!


SDAVAssetExportSession takes a long time

SDAVAssetExportSession compress & export a video taken from photo library （about 300M）takes about 40s，but sysytem AVAssetExportSession takes only 20s..who can help me to find out?
settings:
        QUINT64 bitrate = (naturalSize.width * naturalSize.height * 3);
        NSDictionary *videoSettings = @{
                                        AVVideoCodecKey: AVVideoCodecH264,
                                        AVVideoWidthKey: CZ_NSNumber(naturalSize.width),
                                        AVVideoHeightKey: CZ_NSNumber(naturalSize.height),
                                        AVVideoCompressionPropertiesKey: @
                                            {
                                              AVVideoAverageBitRateKey: @(bitrate)
                                            }
                                        };
        exportSession.videoSettings = videoSettings;

        exportSession.audioSettings = @
        {
            AVFormatIDKey: CZ_NSNumber(kAudioFormatMPEG4AAC),
            AVNumberOfChannelsKey: CZ_NSNumber(1),
            AVSampleRateKey: @(44100),
            AVEncoderBitRateKey:  @(64000),
        };

I have the same problem.
Did you know about it?

I am doing audio M4a recording using SDAVAssetExportSession but it takes a long time to export it same as AVAssetExportSession. I have seen no difference. Can someone point me in right direction ?


Site header link is not responding on clicks

Describe the Bug
Hello, Martin! I'm reaching out this time regarding an issue I've encountered with the SiteTitle component, possibly related to vtbot or my setup, not sure yet. This problem arose after integrating VT into the system.
I've implemented a custom SiteTitle component featuring two links/logos. However, upon testing, I noticed that clicking on the first link doesn't redirect to the main website. The second link/logo functions correctly, directing to the main page of docs.
Upon inspecting the dev console, I encountered the following error: "Uncaught (in promise) TypeError: Cannot read properties of null (reading 'setAttribute')", which points to StarlightConnector.astro.
To provide more context, here's the link to the custom component:
https://github.com/mearashadowfax/ScrewFast/blob/main/src/components/ui/starlight/SiteTitle.astro
The docs link: https://screwfast.uk/welcome-to-docs/
What's the expected result?
When clicking on either of the two links/logos in the SiteTitle component, the user should be redirected to the corresponding URL.
Link to Minimal Reproducible Example
https://github.com/mearashadowfax/ScrewFast/tree/add-starlight-vt
Participation

[ ] I am willing to submit a pull request for this issue.

Hello @mearashadowfax! Thanks for getting in touch and opening the topic.
I'll get back to you when I have news!

@mearashadowfax, your component is fine and completely unrelated to the null access error.
I will directly fix the cause of that error.
I also noticed that Starlight complains about redefined web-components <starlight-toc> and <starlight-menu-button> which is also likely a consequence of view transitions. But I was not yet able to reproduce that one.

Thank you for looking into the issue, @martrapp! As for the other components, I haven't noticed anything specific yet. Starlight was returning a 404 for TableOfContents.astro and MobileTableOfContents, although this existed even before the view transitions, and it seems unrelated.

1.7.2 is out now! Good Luck @mearashadowfax!

As for the other components, ...

I saw on your site that starlight (or your hosting infrastructure) included some web component scripts as inline modules instead of external modules. That leads to re-registration and the errors I saw.

included some web component scripts as inline modules instead of external modules. That leads to re-registration and the errors I saw.

Oh, thank you for pointing this out, I will check why.

should be solved in 1.7.2


Update docs url

Thanks for the pull request @hpinkos!

:heavy_check_mark: Signed CLA found.

Reviewers, don't forget to make sure that:

[ ] Cesium for Unreal Samples works.

Thanks @hpinkos!


Is Random Reproducibility Possible? (Random Seed)

Hi @TomGeorge1234
Is it possible to give a random seed to the Agent and to the Place Cells (or others) in order to have reproducibility of the results when using the same parameters?
Thanks

It's a nice idea. Happy to support it. But, to be clear, is it not a working solution to just set the random seed before initialisation and if not, why not? e.g.:

You are perfectly right, thank you!

great!


Add a template for TailwindCSS

I want to use TailwindCSS instead of SASS, but I really lack of the knowledge to set up the boilerplate. Maybe add another template for setting up Electron + React + TypeScript + Tailwind CSS?

Maintaining too many templates can make maintainers tired, but we will consider replacing scss with TailwindCSS in the future.

For using Tailwind CSS, you can first understand its basic knowledge. It is very simple to replace sass, mainly in automatic updates.

hi @ihsansfd Its quiet simple to add Tailwind, these are the steps I took :
npm install -D tailwindcss
npx tailwindcss init

Create a tailwind.config.js file:
/** @type {import('tailwindcss').Config} */
module.exports = {
  content: ["./src/**/*.{html,js}"],
  theme: {
    extend: {},
  },
  plugins: [],
}

In app.css add the directives:
@tailwind base;
@tailwind components;
@tailwind utilities;

In package.json
    "dev": "vite && pnpm watch-tailwind",
    "watch-tailwind": "npx tailwindcss -i ./src/index.css -o ./dist/output.css --watch",

Install postcss and prefixloader:
npm install -D postcss autoprefixer

Create a postcss.config.js file:
module.exports = { plugins: { tailwindcss: {}, autoprefixer: {}, }, }

Run npm dev, should be able to see tailwind classes taking effect!

hi @ihsansfd Its quiet simple to add Tailwind, these are the steps I took :
npm install -D tailwindcss
npx tailwindcss init

Create a tailwind.config.js file:
/** @type {import('tailwindcss').Config} */
module.exports = {
  content: ["./src/**/*.{html,js}"],
  theme: {
    extend: {},
  },
  plugins: [],
}

In app.css add the directives:
@tailwind base;
@tailwind components;
@tailwind utilities;

In package.json
    "dev": "vite && pnpm watch-tailwind",
    "watch-tailwind": "npx tailwindcss -i ./src/index.css -o ./dist/output.css --watch",

Install postcss and prefixloader:
npm install -D postcss autoprefixer

Create a postcss.config.js file:
module.exports = { plugins: { tailwindcss: {}, autoprefixer: {}, }, }

Run npm dev, should be able to see tailwind classes taking effect!
cc: @RSS1102
Bonus ➡ Adding DaisyUI
npm i -D daisyui@latest

Add to tailwind.config.js
module.exports = {
  //...
    daisyui: {
    themes: ["cyberpunk", "dracula", "light", "...."]
  },
  plugins: [require("daisyui")],
}

In index.html:
<!DOCTYPE html>
<html lang="en" data-theme="cyberpunk">
....

Remove some of the default styling inside of index.css:
:root {
  /* font-family: Inter, system-ui, Avenir, Helvetica, Arial, sans-serif; */
  line-height: 1.5;
  font-weight: 400;

  color-scheme: light dark;
  /* color: rgba(255, 255, 255, 0.87);
  background-color: #242424; */

  font-synthesis: none;
  text-rendering: optimizeLegibility;
  -webkit-font-smoothing: antialiased;
  -moz-osx-font-smoothing: grayscale;
  -webkit-text-size-adjust: 100%;
}

Thanks, it's indeed simple :)

Worked for me as well, except I had to change my tailwind.config.js to the following
/** @type {import('tailwindcss').Config} */
module.exports = {
  content: [
    "./index.html",
    "./src/**/*.{js,ts,jsx,tsx}",
  ],
  theme: {
    extend: {},
  },
  plugins: [],
}

@ihsansfd
Thank you for your guidance.
Sorry, I was busy with work before. I will start this soon.

By the way, what do you think about using unocss.

嗨@ihsansfd添加Tailwind很简单，这些是我采取的步骤：
npm install -D tailwindcss
npx tailwindcss init

创建一个tailwind.config.js文件：
/** @type {import('tailwindcss').Config} */
module.exports = {
  content: ["./src/**/*.{html,js}"],
  theme: {
    extend: {},
  },
  plugins: [],
}

在app.css中添加指令：
@tailwind base;
@tailwind components;
@tailwind utilities;

在package.json中
    "dev": "vite && pnpm watch-tailwind",
    "watch-tailwind": "npx tailwindcss -i ./src/index.css -o ./dist/output.css --watch",

安装postcss和prefixloader：
npm install -D postcss autoprefixer

创建一个postcss.config.js文件：
module.exports = { plugins: { tailwindcss: {}, autoprefixer: {}, }, }

运行npm dev，应该能够看到尾风类正在生效！
抄送：@RSS1102
奖金➡添加DaisyUI
npm i -D daisyui@latest

添加到tailwind.config.js
module.exports = {
  //...
    daisyui: {
    themes: ["cyberpunk", "dracula", "light", "...."]
  },
  plugins: [require("daisyui")],
}

在index.html中：
<!DOCTYPE html>
<html lang="en" data-theme="cyberpunk">
....

删除index.css中的一些默认样式：
:root {
  /* font-family: Inter, system-ui, Avenir, Helvetica, Arial, sans-serif; */
  line-height: 1.5;
  font-weight: 400;

  color-scheme: light dark;
  /* color: rgba(255, 255, 255, 0.87);
  background-color: #242424; */

  font-synthesis: none;
  text-rendering: optimizeLegibility;
  -webkit-font-smoothing: antialiased;
  -moz-osx-font-smoothing: grayscale;
  -webkit-text-size-adjust: 100%;
}

Hello, after I complete the configuration, there will be an error of "module' is not defined" in tailwind.config.js and postcss.config.js. I would like to ask how to solve it. Or what configurations need to be changed to make it normal? Because in this case, it seems that tailwindcss will not fail properly.I would really appreciate it if you could help me.

@hotdongdong Hey! 👋
It looks like @RSS1102 will be integrating Tailwindcss into this repository soon.


Page/food test added with backend and google analytics fully connected

연애유형으로 보는 흑백요리사 음식 테스트 개발 완료

디자인 및 기능 전체 완료
기본 공유하기 기능 + 카톡/트위터/인스타 공유하기
백엔드에 연결하여 사람들의 응답들 기록하기
Google Analytics에 기본적인 정보부터 모든 이벤트와 응답 소요 시간 등 advanced한 통계까지 기록

This pull request includes several changes to enhance the Firebase hosting workflows, update dependencies, add new pages and components, and correct styling issues.
Workflow Updates:

[.github/workflows/firebase-hosting-merge.yml]: Added new environment variables for KAKAO_JAVASCRIPT_KEY and API_DNS.
[.github/workflows/firebase-hosting-pull-request.yml: Added new environment variables for KAKAO_JAVASCRIPT_KEY and API_DNS.

Dependency Updates:

[package.json]: Added axios and html2canvas dependencies.

New Pages and Components:

[src/App.js: Added new pages FoodTest, ResultPage, and SharePage. Updated routing and layout to conditionally hide the Navbar and Footer for specific paths.
[src/components/Navbar.js]: Added a new menu item for the "Food Test" page.
[src/data/resultsData.js: Added a comprehensive dataset for the food test results.

Styling Corrections:

Various files (src/pages/DownloadPage.js, src/pages/FormPage.js, src/pages/LandingPage.js): Corrected casing in styled-components props (e.g., mobileSize to mobilesize).

Sitemap Updates:

public/sitemap.txt, public/sitemap1.xml, public/sitemap2.xml, public/sitemap3.xml: Updated URLs and modified metadata.

I'm genius


Investigate Ninja build system

Ninja is a build system alternative to Make. It's goal is to improve build speed. The latest Serac build takes about 1 minute 30 seconds on Quartz. It might be worth adding the option to build Ninja with CMAKE_GENERATOR=Ninja within the config-build.py script.
$time srun -N1 --exclusive --mpibind=off -Aeng -t10 make -j
...
real    1m36.585s
user    0m0.020s
sys     0m0.015s

Another benefit of Ninja is style. With Ninja, it's possible to run simply ninja style without needing to build all of Serac - saving a lot of time.

I've been using ninja as a generator for serac the entire time I've worked on this project, what do you want to investigate?

I've been using ninja as a generator for serac the entire time I've worked on this project, what do you want to investigate?

I assume something like ./config-build.py --ninja or ./config-build.py -n to enable the Ninja generator.

I've been using ninja as a generator for serac the entire time I've worked on this project, what do you want to investigate?

Investigate might be the wrong word. I think it'd be a convenient thing to add to the config-build script. And something we do in lido is check style and build docs using ninja, so you avoid the build time and it speeds up the CI a bit. The style check job in lido takes well under a minute.

fwiw, style is just a target, so you should be able to just run make style to apply clang-format (without actually building serac) the same way ninja style does.

Oh I see that - thanks.


Rebaseline Parthenon-VIBE on Roci-HBM

After Anthony completes rebaseline of Sparta, rebaseline using same methodology on Roci-HBM

Complete but could use further explanation.

We discussed this today, numbers look reasonable, a few changes needed:

Run 20% memory size with ranks up until we run out of mesh-blocks (56 ranks) then switch to ranks + threads
Move ATS-3 results up top, then CTS, then A100
Rerun A100 numbers

done!


bug: auto-close/rename not working with typescriptreact but works with html

With the default config/setup — auto-close and auto-rename works with html, but not with typescriptreact:
require('nvim-ts-autotag').setup({
  opts = {
    enable_close = true,
    enable_rename = true,
    enable_close_on_slash = false
  },
})

Versions

nvim-ts-autotag cb57b07
nvim v0.10.0
tree-sitter 0.22.6

html ✅
Expected behavior:
Before        Input         After
------------------------------------

    ciwspan<esc>
------------------------------------

Actual behavior:
Before        Input         After
------------------------------------

    ciwspan<esc>
------------------------------------

typescriptreact 🔴
Expected behavior:
Before        Input         After
------------------------------------

    ciwspan<esc>
------------------------------------

Actual behavior:
Before        Input         After
------------------------------------

          🔴

    ciwspan<esc>
   🔴
------------------------------------

I found related issues to the usage with lazy.nvim
Setting lazy = false or event = 'VeryLazy' seems to fix it:
return {
  'https://github.com/windwp/nvim-ts-autotag',
  event = 'VeryLazy',
  opts = {
    opts = {
      enable_close = true,
      enable_rename = true,
      enable_close_on_slash = false,
    },
  },
}

I'll add a PR later today addressing lazy loading for nvim-ts-autotag.
If this was better documented, you'd have never had this problem in the first place.
I'm going to reopen this issue with that in mind and close it via PR -- no need for you to do anything, just for tracking 🙂.


Import into new environment fails

Hey guys,
Yesterday I was putting together a quick POC using the tutorial. And it worked like a charm. So today I went to start adding ng-admin to my sails application. I bower install'd it and then when I added the references to the html page I started getting "cannot get property 'isDefined' of undefined".
Since I haven't added any logic or anything I'm guessing this has something to do with the commits from today. Any thoughts?

ping @jeromemacias is everything rebuilt correctly?

Seems ok for me on my local env for the blog example.

Hey,
I'm still getting a failure when I am just creating a basic sails app. I have uploaded it to github if you could see what is going on I would appreciate it.
https://github.com/nheinbaugh/Ng-Admin-Test
Thanks,
Nick

Based on your layout: https://github.com/nheinbaugh/Ng-Admin-Test/blob/6a296c00b07b43f0e80f991398177e5cac8f1830/views/layout.ejs#L95-L125
You should:

Include /js/build/ng-admin-only.min.js instead of /js/build/ng-admin.min.js
Include /js/build/ng-admin-only.min.js after all other scripts
Include /js/ng-file-upload.js instead of /js/angular-file-upload.js

@nheinbaugh does the answer above solved your issue?


Fixes nodejs engine warning msg during npm install

Do not enforce engine version if there is no real reason

@JSteunou I'd guess there is a real reason, having specific version numbers in there.
What about "node": ">=0.8" and `"npm": ">=1.1"?

Should be better, event if I would be very surprised if anyone still use node 0.8 :D

Make sense to me. Thanks for noticing!


LESQ-1076: Individual download buttons require onboarding

Description
Music year: 1963

Each download button on the download page should navigate un-onboarded users / non-logged in users to onboarding page

ACs:

[ ] Clicking on any download link on the lesson page allows the user to complete the required steps of the sign in journey

Issue(s)
Fixes #LESQ-1076
How to test

Go to https://deploy-preview-2809--oak-web-application.netlify.thenational.academy
Navigate to any lesson page, all download buttons should navigate you to the onboarding journey when not signed in

Screenshots
How it should now look:
https://github.com/user-attachments/assets/7cb88833-4950-4c36-84b9-1eb675f042b9
Checklist

[ ] Added or updated tests where appropriate
[x] Manually tested across browsers / devices
[x] Considered impact on accessibility
[ ] Design sign-off
[ ] Approved by product owner
[ ] Does this PR update a package with a breaking change

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


Dockerfile to build and create final docker image for CI/CD pipeline

It was great to refer to your article for creating docker images for spring boot application.
The article shows it in pieces on how to create a docker image. Can you share how the file docker file looks like that would

Create the docker image through mvn spring-boot:build command
Incorporate layers as shown in step 4.3
Publish the docker image to a docker registry

These are the steps needed in a CI/CD jenkins pipeline for a spring boot project. Pardon me if you already have a separate article that demostrate these steps. Kindly point me to that.
Thanks

Hi @shahamit ,
Thanks for the feedback. Glad you find the articles helpful.
In the 4.3 section we already present the Dockerfile to use with layered jars. For two remaining points, the best way would be to take a look at the documentation. For example here - https://docs.spring.io/spring-boot/docs/2.5.6/maven-plugin/reference/htmlsingle/#build-image - you can see how to attach the build-image goal to the package phase.
Hope this helps.

My bad - I meant the Jenkinsfile that did the 3 steps listed above (not the Dockerfile).


[feat] Code change for compile on windows. Needs to modify php-src.

Thanks for your comments. I've take them and added the compilation documentation.


Positional argument specifications

I may be missing something in the documentation, but there doesn't seem to be a way to specify positional arguments for each commands. For example, one may want to specify in the help that two arguments are accepted only:
NAME:
   foo - Apply foo to argument bar and optionally a baz

USAGE:
   command foo bar [baz]

This seems like a straightforward addition to the library but I wanted to get feedback before dropping a PR. Python's argparse provides a good example of this done well. Such a feature also provides the benefit that arguments can be pre-validated before proceeding with the command.

Work has been started on this over here: #140

Given that this is from last year, I think I'm comfortable closing it 🙂 feel free to re-open / open a new issue / comment in support if there's still interest here!


Divide src/progress.rs into mods

https://github.com/pingcap/raft-rs/issues/125
The original src/progress.rs is divided into src/progress/{mod.rs, infights.rs, progress.rs, progress_set.rs}

Hi @Fullstop000 !
I think this is a step in the right direction. :) In the future we may want to split things up more, and there are certainly other parts of Raft that could have this treatment, but I appreciate you choosing to do this in a bite sized chunk.
Please take a moment to fix the merge conflict if you could.

PTAL @BusyJay

@BusyJay Was your last review a green approved check? :) Can you give another?

Thanks for your contribution!


ci(.github): se correct api docs diff make target names

This PR fixes API docs Make target names and ensures all the GitHub Actions are pinned.
Furthermore, it updates the URL of Capsule and Capsule Proxy repositories to HTTPS, from SSH.
Fixes #5

@prometherion already fixed with this PR. Sorry, I had just updated the description without update comment


Automatically add integration key if it exists in PagerDuty service

Is your feature request related to a problem? Please describe.
Currently the PagerDutyCard can be setup with one of two annotations: pagerduty.com/service-id and pagerduty.com/integration-key. The entity processor module only adds the integration key annotation if the service has been mapped through the entity mapping feature recently introduced.
Describe the solution you'd like
I would the entity processor to add the pagerduty.com/integration-key annotation for all entities that are connected to a service that contains a Backstage integration. This way, users could just either specify the service-id in catalog-info.yaml or simply use the new entity mapping page.
Describe alternatives you've considered
Currently the only option is to add the annotation manually or override the mapping in the entity mapping page which will force the integration key to be persisted on the database.

Closing this feature as this was released on version 0.3.0.


Add Android and iOS for CI builds

Current dependencies on/for this PR:

main

PR #179

PR #181   👈

This comment was auto-generated by Graphite.

Codecov Report

Merging #181 (ed428aa) into no_alloc_target (6ed7775) will not change coverage.
The diff coverage is n/a.

@@               Coverage Diff                @@
##           no_alloc_target     #181   +/-   ##
================================================
  Coverage            87.72%   87.72%
================================================
  Files                   41       41
  Lines                 2664     2664
================================================
  Hits                  2337     2337
  Misses                 327      327

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


Switch to the new CoreCLR package for framework

This allows us to consume live corefx framework builds (except the corert specific binaries that are not building yet)

cc @SedarG


DocsArchive-<IP_ADDRESS>Auto archive content

Auto archive content from https://github.com/OPS-E2E-PPE/docs-archive-test-source

Docs Build status updates of commit 850df0a:
:x: Validation status: errors
Please follow instructions here which may help to resolve issue.

File
Status
Preview URL
Details

:x:Error

Details

[Error]

Cannot sync git repo to specified commit because branch Archive_master_2019-11-21-01-04-22 has been deleted or has been force pushed: fatal: couldn't find remote ref refs/heads/Archive_master_2019-11-21-01-04-22

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Change shadow effect on card

Pull Request Checklist

[X] I have added screenshots and videos to show before and after the working of my code.
[X] I have ensured that the screen size is set to 100% while making the video.
[X] I have synced the latest fork with my local repository and resolved any conflicts.
[X] I have mentioned the issue number which I created before making this PR
.(format to mention issue number is : fixes #(1549) )
[X] I understand that if any the above conditions are not met , my PR will not be MERGED .

fixes #1549


Increasing memory consumption

Bug Report
Version
── tonic v0.5.0
│   └── tonic v0.5.0 ()
│   └── tonic-build v0.5.0
└── tonic-build v0.5.0 ()
Platform
Ubuntu 20.04
Description
I'm working on a simple grpc api with bidirectional streaming. Client connects to a server and specify topics he wants to receive at any time(client streaming), server on the other side - sending topic messages to client(server streaming). This API is used by mobile application so we have a lot of interrupted connections.
The problem is that memory constantly growing while receiving new connections and closing old ones. I'm not so good in rust to say without any doubts that problem in my code. Appreciate any help
Here is my shrinked service code:
use std::collections::HashMap;
use std::pin::Pin;
use std::sync::Arc;

use tokio::time::{sleep, Duration};
use futures::{Stream, StreamExt};
use tokio::sync::{mpsc, RwLock};
use tonic::{Request, Response, Status};
use uuid::Uuid;

use trade_feeds::feeds::feeds_server::Feeds;
use trade_feeds::feeds::{
    subscribe_response, Candlestick, CandlestickMessage, SubscribeResponse, SubscribeStreamRequest,
};

#[derive(Debug)]
pub struct Shared {
    pub senders: HashMap<Uuid, mpsc::Sender<SubscribeResponse>>,
}

impl Shared {
    pub fn new() -> Self {
        Shared {
            senders: HashMap::new(),
        }
    }

    async fn broadcast(&self, msg: SubscribeResponse) {
        // To make our logic simple and consistency, we will broadcast to all
        // users which include msg sender.
        // On frontend, sender will send msg and receive its broadcasted msg
        // and then show his msg on frontend page.
        for (name, tx) in &self.senders {
            match tx.send(msg.clone()).await {
                Ok(_) => {}
                Err(_) => {
                    println!("[Broadcast] SendError: to {}, {:?}", name, msg)
                }
            }
        }
    }
}

#[derive(Debug)]
pub struct FeedsService {
    shared: Arc<RwLock<Shared>>,
}

impl FeedsService {
    pub fn new(shared: Arc<RwLock<Shared>>) -> Self {
        FeedsService { shared }
    }
}

#[tonic::async_trait]
impl Feeds for FeedsService {
    type SubscribeStreamStream =
        Pin<Box<dyn Stream<Item = Result<SubscribeResponse, Status>> + Send + Sync + 'static>>;

    async fn subscribe_stream(
        &self,
        request: Request<tonic::Streaming<SubscribeStreamRequest>>,
    ) -> Result<Response<Self::SubscribeStreamStream>, Status> {
        let request_id = Uuid::new_v4();
        let mut stream = request.into_inner();
        let (tx, mut rx) = mpsc::channel(1);
        let (stream_tx, stream_rx) = mpsc::channel(1);

        {
            self.shared.write().await.senders.insert(request_id, tx);
        }
        println!(
            "Current users size {:#?}",
            self.shared.read().await.senders.keys().len()
        );
        async_stream::try_stream! {
            while let Some(message) = stream.next().await {
                // let message = message.unwrap();
                // self.shared.write().await.subscribe(
                //     request_id,
                //     message.owner_id.clone(),
                //     message.subscriptions.clone(),
                //     // one_rx
                // ).await;
            }
        };

        let shared_clone = self.shared.clone();

        // Item is not initialized. It's a first message
        tokio::spawn(async move {
            while let Some(msg) = rx.recv().await {
                match stream_tx.send(Ok(msg)).await {
                    Ok(_) => {}
                    Err(e) => {
                        eprintln!("[Remote] stream tx sending error. Remote {}", e);
                        shared_clone.write().await.senders.remove(&request_id);

                    }
                }
            };
        });

        Ok(Response::new(Box::pin(
            tokio_stream::wrappers::ReceiverStream::new(stream_rx)
        )))
    }
}

pub async fn send_data(shared: Arc<RwLock<Shared>>) {
    loop {
        let message = SubscribeResponse {
            item: Some(subscribe_response::Item::Candlestick(CandlestickMessage {
                pair: "AUD/USD".to_string(),
                timeframe: "1".to_string(),
                candlestick: Some(Candlestick {
                    x: 1,
                    y: vec!["1".to_string()],
                    change_percent: "1".to_string(),
                    daily_highest: "1".to_string(),
                    daily_lowest: "1".to_string(),
                }),
            })),
        };
        shared.read().await.broadcast(message).await;
        sleep(Duration::from_millis(1000)).await;
    }
}

Reproduction example from Discord: https://github.com/cyberbudy/tocio-stream-example
Me, also from Discord:

I've looked into it a bit and I think something is wrong with closing client streams. It seems if you create an infinite client to server stream, which the server consumes in some background task, and then drop the client that created the stream (FeedsClient in this case) the client to server stream doesn't actually end. It only ends when you completely kill the client process with ctrl-c. I find that very odd :thinking:
if you change your example to not use a client stream, so only a server stream, then everything works

I've made a minimal reproduction example for this https://github.com/davidpdrsn/tonic-infinite-client-stream. I would expect the server to print "client disconnected" when calling drop(client), however that doesn't happen until the client process is killed with ctrl-c.
That seems like a bug to me, I would expect the client to end all connections when its dropped. I did some digging but nothing in tonic stood out to me. Could this be something in hyper/h2?

Yeah, the problem was with client streams, that didn't dropped properly.
If everything is ok with @davidpdrsn comment, can close this issue

I'm still wondering if there might be a bug so think we should keep it open until we know for sure.

There has not been much progress here so going to close this issue.


Proxy support

Support to run SimpleJPA behind proxy network, (refer to http://code.google.com/p/simplejpa/issues/detail?id=35 )
This would be useful feature because development work in corporate is usually behind a proxy.
Thank so much in advance!

If you can get this into me as a pull request on github, i'll merge it in.

any improvements on this? will username/password auth be suported? Thanks


Game crashes on start (1.19.2)

https://paste.srnyx.xyz/epirefawep.properties

Looks like the minecraft codebase has changed enough that my mixin is no longer matching the right function.
I've not touched this project since I released it, please feel free to fork it, the code is relatively simple.

Looks like the minecraft codebase has changed enough that my mixin is no longer matching the right function.
I've not touched this project since I released it, please feel free to fork it, the code is relatively simple.

Yeah it's all good now, someone else forked it for me, thank you!


change tabs bug

Web address: https://cn.vuejs.org/v2/guide/components-dynamic-async.html
Keep going up until you can't see.

已经提到了主站，关闭当前issue。


Neos 7

I've tested the plugin with Neos 7. Only had to adjust the migrations.

thanks so much :) <3


Test Branch - Iframes support, Cache fixes, Multiple Instances support

This PR is a test branch that integrated all  the below PRs in review to have one stop test version:

#939: Popups and iframes polled for hash, removes the iframe restriction on acquireTokenSilent
#975: Adds messaging interface to MSAL JS to support loginRedirect() and acquireTokenRedirect() in iframed applications
#980 and #983: Cache cleanup, added support for multiple instances

We plan to share this with a few customers who are gracious to help us with the beta testing and merge the pending changes to dev as the build stabilizes.

Closing this. More changes made later and a new PR is in progress to handle the testing.

Hi @sameerag, been following this fix as it's something we need fairly urgently. Has this been released now? If not do you know when it will be? I noticed you mentioned another PR but can't find anything related.
Also is there any documentation (even in code) somewhere please?
Cheers
Paul


Indexing ractive+routie SPA by search engines bots

Hello!
I develop SPA with Ractive and Routie library for routing. My SPA has a few pages and all it's content contains in index.html. But I have a problem with search engines bots, they are see page like HTML with mustaches, for example:

	{{#each cities}}
		{{this}}
	{{/each}}

And in this case Google search bots can't find other pages of my SPA, because routieJS and RactiveJS not started when bot comes. He see the one big index.html with content of other routieJS pages, but can not find this pages with own content, all URLs like "#rules" link to index.html.
My site avtoritet.club.
Please help!

I've not used routie, but I have had google successfully index single-page sites that are built on page.js and Ractive. Sometimes the google-bot picks up the raw template on the first run through, but it usually gets everything sorted fairly quickly.
Do you have a hard requirement to not use the history api? My best guess that the google-bot is seeing hash links and thinking that it's all meant to be a giant page with anchor navigation.
I will say that last time I checked bind didn't do so well with SPA-style sites, but I've not had any severe problems with google.

they are see page like HTML with mustaches

Of course. Think of bots as browsers that don't have JS. Without JS, Ractive won't run.  And that's what the bot actually sees.
On the other hand, you can do server-side rendering with Ractive. You can run the app in Node and have the top-most component render itself using toHtml and toCss (undocumented, but works the same).
There was a discussion recently about "isomorphic" Ractive, where instances on the client, when bound to the markup of its server-rendered version, would auto-bind itself without throwing away the existing markup. Not sure where the discussion ended up or if it was ever implemented.
Anyways, if you aren't using Node, or if "isomorphic" isn't your thing, you can always put static content on the page for bot consumption which will be thrown away when Ractive runs on the page.

default content

Additionally, so that bots won't parse the template, write your components in either external JS files or as component files and leaving nothing on the page. Also consider having a build phase to compile your app.

Just wanted to note that google is throwing a good bit of weight behind angular and are therefore much more webapp friendly.
Additionally, edge has an option to use progressive enhancement that doesn't blow away the dom that the browser has already rendered (entirely, anyways) when the Ractive instance kicks off. See the enhance option in the edge docs.

I usually use UA sniffing to send server-rendered pages for all common bots, and render client-side for everything else.
Given the support for progressive enhancement in 0.8, it might make sense to simply always send server-rendered pages, but in my experience, due to how it works, Ractive is quite slow for server-side usage.

Here's an interesting blog post from google.
@MartinKolarik:

I usually use UA sniffing to send server-rendered pages for all common bots, and render client-side for everything else.

from above post:

Serving Googlebot different content than a normal user would see is considered cloaking, and would be against our Webmaster Guidelines.

@martypdx it's no different than using phantomjs which is a common practice. Also:

If you pre-render pages, make sure that the content served to Googlebot matches the user's experience, both how it looks and how it interacts.

Pages for bots look exactly same as in any JS enabled browser.

Thanks to all.
But I have a question: if I use server-side rendering, the page still haven't content, it will be looks like:

and Google can not see content.
Only after JS files will be load, query will be send to server and answer with html will be recieve, the page will be render.
And I can set default content correctly, because this default content be the same for main page, /#profile, /#login and any other pages, using JS-routing.
In that case I can understand how server-side render can help me.

Only after JS files will be load, query will be send to server and answer with html will be recieve, the page will be render.

Server-side rendering means you render and send full HTML in the first response, not that you load it later using AJAX.

Do you know what is better?
https://github.com/MartinKolarik/ractive-render
https://github.com/zenflow/ractive-express
Or exist better solution?

I wrote the first one, so that's the one I'm going to recommend :smile:

Thanks)

I am using Ractive + Page.js and I will update details here about google indexing. Until now, everything seems ok.

As promised, here are the details until now:
Google is rendering and indexing all the pages properly. It's important to use a routing library as page.js with history API support, that "intercept" clicks and allow the use of regular "a" links.
This way:

you don't need to use on-tap or on-click to simulate links
normal "a" links are crawled
your SPA can be requested in any URL and link previously provided
links can be shared externally

I am now validating complete SVG-pages and seeing how they will be crawled. For this test, I fixed page.js to work including with SVG links. (here is the PR and here is the fork)


Optional timestamp field of producer.send is undocumented

I've been searching around the doc and even digging in the source files, there is practically no info on how to use the message timestamp field with a producer.
The doc says we can use it :

But that's it. No examples, no details, nothing.
From the source code, it looks like it should be a string field, but I'm wondering if its actually the right type.

Thanks ! A little hint about that in the doc would definitely be helpful.

I'll re-open as a bug report for the documentation.


widget becomes activ with mouseover already instead of clicking it

This issue is the outcome of this Thread at iobroker Forum:
https://forum.iobroker.net/topic/58219/widget-wird-aktiviert-beim-überfahren-mit-mauszeiger?_=1663921986890
As soon as i mouseover the widget becomes aktiv. Tested with Chrome/Firefox
Example Widget:
[{"tpl":"tplHqButton","data":{"g_fixed":true,"g_visibility":false,"g_css_font_text":true,"g_css_background":false,"g_css_shadow_padding":false,"g_css_border":true,"g_gestures":false,"g_signals":false,"g_last_change":false,"visibility-cond":"==","visibility-val":1,"visibility-groups-action":"hide","oid":"hm-rpc.0.MEQ0675904.1.LEVEL","min":"0","max":"","iconName":"/icons-mfd-png/control_centr_arrow_down.png","btIconWidth":"75","offsetAuto":true,"leftOffset":"35","topOffset":"0","timeAsInterval":"true","infoLeftFontSize":"12","infoFontRightSize":"12","infoLeftPaddingLeft":"15","infoLeftPaddingRight":"50","infoRightPaddingRight":"15","signals-cond-0":"==","signals-val-0":true,"signals-icon-0":"/vis/signals/lowbattery.png","signals-icon-size-0":0,"signals-blink-0":false,"signals-horz-0":0,"signals-vert-0":0,"signals-hide-edit-0":false,"signals-cond-1":"==","signals-val-1":true,"signals-icon-1":"/vis/signals/lowbattery.png","signals-icon-size-1":0,"signals-blink-1":false,"signals-horz-1":0,"signals-vert-1":0,"signals-hide-edit-1":false,"signals-cond-2":"==","signals-val-2":true,"signals-icon-2":"/vis/signals/lowbattery.png","signals-icon-size-2":0,"signals-blink-2":false,"signals-horz-2":0,"signals-vert-2":0,"signals-hide-edit-2":false,"lc-type":"last-change","lc-is-interval":true,"lc-is-moment":false,"lc-format":"","lc-position-vert":"top","lc-position-horz":"right","lc-offset-vert":0,"lc-offset-horz":0,"lc-font-size":"12px","lc-font-family":"","lc-font-style":"","lc-bkg-color":"","lc-color":"","lc-border-width":"0","lc-border-style":"","lc-border-color":"","lc-border-radius":10,"lc-zindex":0,"pushButton":true,"oid-working":"hm-rpc.0.MEQ0675904.1.WORKING","descriptionLeft":"Rollladen Arbeitszimmer Vorne.LEVEL","descriptionLeftDisabled":true,"usejQueryStyle":true,"iconOn":"","changeEffect":"","testActive":false,"name":"Rolllade BAD runter"},"style":{"left":"5px","top":"202px","width":"70px","height":"114px","border-width":"1px","border-style":"solid","border-color":"#FFFFFF","border-radius":"2px","z-index":"5"},"widgetSet":"hqwidgets"}]
VIS 1.4.15
HQ Widgets installed: 1.3.0
all other aadpters and JS Controller on latest versions.
please let me know if anything else is needed.

Closed. No feedback at all.


UX: update label from reply to answer on Q&A topics

Before:

After:

Thanks for the review @CvX ❤


Add flag to cache data returned from a vuln check

Data returned from a vuln may contain unknown or personal information. While this may be useful to individuals trying to fix libraries, it's not really appropriate to return that info to unknown parties. Adding a flag to disable this by default.

Dead on the vine. Cleaning up.,


Add cli utils

This pull request changes and adds no functionality. It is purely to improve organization of code by breaking out like functions into a separate module. It also introduces some simple tests to be expanded on as the project grows. I do not have hardware on hand to test that the system runs as expected, but outputs to each function should remain the same and is tested.
Happy to update or add additional testing coverage.

Woh, @rhollen !  Thanks for the PR!  Been a crazy long time man, I think 14 years?
We're more than happy to send you a unit to play with to say thanks.  Will reach out offline.

@Luxonis-Brandon -- it has been a long time! Thanks for the offer, would be fun to actually use the hw :)
@ szabi-luxonis -- please let me know how to best contribute. I haven't been involved much in open source contributions, so please assume ignorance if I am doing anything wrong!

Thanks @rhollen !  Discussing internally it looks great!
I'll test it as well on Mac/Ubuntu/Raspbian with actual DepthAI hardware to make sure there isn't some unforeseen thing here.  Doesn't seem like there would be though.
And we'll get your unit shipped out to you today probably.  :-)

OK finally got around to testing this w/ actual hardware.
Ran on Mac:

with BW1093 w/ python3 test.py and it worked fine.

with BW1098OBC w/ python3 test.py -s metaout previewout depth_sipp,5 -bb -ff -cnn face-detection-retail-0004 and it worked fine.

Going to run it on BW1097 and w/ BW1098 + Ubuntu soon here.

Thanks for the refactor. For the most part seems good, but a couple of thoughts/questions:

One thing that is a bit odd to me is having the argparser info for a script (depth.py) in a totally separate file. I'd expect the arg refs for depthai.py to be in depthai.py. Clean up is good, but I wonder if that is a bit too clean so to speak.

It also seems to make the assumption that the tests and the depth.py file will always have the same args, but I'm not sure that's the case. This is more a design issue/question.

I'm not sure I agree with creating our own print override just to add colors with cli_print but that might just be me being weird.

Having some tests is nice!

Finally tested this on Raspberry Pi and Ubuntu.  All works fine.
Ubuntu:

Thanks for the refactor. For the most part seems good, but a couple of thoughts/questions:
One thing that is a bit odd to me is having the argparser info for a script (depth.py) in a totally separate file. I'd expect the arg refs for depthai.py to be in depthai.py. Clean up is good, but I wonder if that is a bit too clean so to speak.
It also seems to make the assumption that the tests and the depth.py file will always have the same args, but I'm not sure that's the case. This is more a design issue/question.
I'm not sure I agree with creating our own print override just to add colors with cli_print but that might just be me being weird.
Having some tests is nice!

So @philnelson discussed this offline.  I'm a fan of breaking out the CLI functions into their own script so that a user who doesn't care about the CLI interface can see the rest of the code/how-to w/out having to scroll past it all.
So we're good to go w/ that @rhollen

Thanks @philnelson!  -- I'll answer your comments inline

One thing that is a bit odd to me is having the argparser info for a script (depth.py) in a totally separate file. I'd expect the arg refs for depthai.py to be in depthai.py. Clean up is good, but I wonder if that is a bit too clean so to speak.

I think this is a pretty standard architecture, to break up like functions into modules. It helps organize the code as it grows and makes it easier to find what you need. I noticed that the depthai.py module was getting very large and was hard to understand coming from the outside. As this project continues to grow, it will be increasingly harder to contribute.

It also seems to make the assumption that the tests and the depth.py file will always have the same args, but I'm not sure that's the case. This is more a design issue/question.

I had no ability to test this at the time. It was mostly to add some level of testing and anyone / everyone should add more cases to the tests. Hopefully these tests can become a bit more automatic such that testing changes becomes less manual, but this is a very tiny, baby step in that direction.

I'm not sure I agree with creating our own print override just to add colors with cli_print but that might just be me being weird.

It's not an override (I've seen that done, where python built in print() gets overridden -- bad!), it's just adding a function to do the formatting. It is a bit "cute", but I thought it made the code read a bit cleaner. It's also less error prone and less repeated code. I think it's an improvement,  not a required change, but you could say that about the whole pull request!
Thanks for the review!

@rhollen Suggestions from my side.
First, I would rename cli_utils to just cli. It's cleaner and specifies that these are not just utilitary functions (e.x. parse_args is a core functionality I think)
Also, Instead of doing cli_print and passing two arguments, I would provide methods to cli class in a manner similar to logging python module, so we'd have cli.warning("sometext"), and also provide cli.print("sometext", PrintColor.RED) if someone would like to do something custom.
I love the tests, also felt a need for them and it's great that you brought them up @rhollen, thanks!

@rhollen on second thought, I'll just prepare a separate PR with these changes, don't want to hold these up - as they're definitely needed and much appreciated your contribution!

@VanDavv -- thanks for the review! I do like your suggestions. I named it cli_utils to match the calibration_utils naming, but we can rename. Simpler is better.
As for the other change request, I also like it. I went with the function because I thought it fit in better with most the other code I saw and it was the smallest change I could think of. It will be a bit more code to write it as you've suggested, but it is nice to have it look like the logging module. Feel free to update, or I can open up another PR. Please let me know. I do think a separate pull request is better here.

I think the same, let's merge this one. Thanks @rhollen ! Looking forward to work with you on next PRs!


_9base: mark broken for x86_64-darwin

_9base: mark broken for x86_64-darwin
Tracking issue: https://github.com/NixOS/nixpkgs/issues/282641
error: call to undeclared function 'p9mbtowc'
Log: https://hydra.nixos.org/build/246581677/nixlog/1
CC @jk

FYI: I didnt see this as nixpkgs maintainer attributes != github ids
Also there's a maintainer script to query that easily that I find handy

A fix is available in PR 282669


Animating a skeleton that has a BoneAttachment node will crash the editor.

Operating system or device - Godot version:
Windows 10 64bit - Godot 3.0 Alpha 1
Issue description:
If you add a BoneAttachment node to a skeleton and then animate the skeleton in the editor with the AnimationPlayer or the AnimationTreePlayer, the editor will crash. However it seems like running it in-game does not crash the game.
Edit:
I just changed the AnimationPlayer and AnimationTreePlayer process mode to "fixed", and the editor crashing stopped. After switching the process mode back to "idle" it still doesn't crash. I'm not sure if this was just a problem with this demo then.
After deleting the BoneAttachment and adding it again the editor crashing started again. Looks like maybe the BoneAttachment only crashes after it's added for the first time, or something.
Steps to reproduce:
Open the 3D Platformer demo, open the Player scene, add a BoneAttachment to the skeleton, and try to animate the player. The editor will crash. But if you run the game, the game will not crash.

I can reproduce on 76005a8e75d4e63ad0477e11dbc8cc1c86666875 Worth to mention that for me the most certain way of reproducing was to run animation in AnimationTreePlayer.

just fixed this, closing

For the reference, fixed in 2a6cdfa.


Zero copy support

Is there any support for zero copy?
thank you

What exactly you want to "zero copy" ?

What exactly you want to "zero copy" ?

Send  local file

@silence934 there cant be zero copy as it needs to be encrypted.

@silence934不能有零拷贝，因为它需要加密。

ok  ，i know


springfox-swagger2 dependency issue

I used early version of springfox: spring-swaggermvn on my RESTful services which worked well. Now I want to try Swagger2.0 and switch to springfox. However using springfox causes issues to my web service. It throws something like this:
"status": 500,
"error": "Internal Server Error",
"exception": "java.lang.AbstractMethodError",
"message": "com.fasterxml.jackson.databind.JsonSerializer.isEmpty(Ljava/lang/Object;)Z",

I tried to troubleshoot the problem and found out only by adding the springfox dependency in my pom.xml creates this issue. The dependency I added was:
<dependency>
	<groupId>io.springfox</groupId>
	<artifactId>springfox-swagger2</artifactId>
	<version>2.2.2</version>
</dependency>

Could someone help me with this?

Solved, need to use another version of spring-hateoas, changed to version 0.17.0.RELEASE from 0.18.0.RELEASE
<dependency>
            <groupId>org.springframework.hateoas</groupId>
            <artifactId>spring-hateoas</artifactId>
            <version>0.17.0.RELEASE</version>
            <type>jar</type>
</dependency>

and the error is gone.
In case someone has similar issues.


Cannot find package petrel-oss-sdk while installing dependencies

Just skip it. petrel-oss-sdk is an internal package for us to accelerate data loading. And the code will also work without this package.


Missing exception support in Python 2

Opening a file in Python 2
try:
    with open(args.json_covers, "r") as f:
        ...

throws an IOError exception which is not caught because FileNotFoundError is a Python 3 exception. Add that exception to the exception list:
except (FileNotFoundError, IOError):

but FileNotFoundError = IOError. Did you try this?

running this command:
tenprintcover-py eric$ python tenprintcover.py --title=x --author=y --cover=fakedir/cover.png
shows that the existing code works correctly.

In Python 3, FileNotFoundError is a subclass of OSError.
In Python 2, OSError does exist but has no subclass FileNotFoundError, whereas IOError is a “sibling” class of OSError (see here).
Instead of assigning IOError to FileNotFoundError, I propose a proper subclassing like Python 3 implements it, although it’s not a proper implementation of that error class:
_python_version, _, _, _ = sys.version_info
if _python_version == 2:
    class FileNotFoundError(OSError):
        pass

I had not realized that different exceptions (IOError and OSError) are raised in Python 2 and 3. That's ugly. Now I understand why you don't like FileNotFoundError = OSError. That makes all the solutions hacky. I don't have the Py3 experience to know which is least bad, but I was thinking that FileNotFoundError = OSError at least confines the hackiness to Py2.

Starting with Python 3.3, IOError was aliased with OSError (see PEP 3151). If you look at the exception handling examples in the documentation for Python 2 and Python 3 then you can see how Python 2 uses except IOError and Python 3 uses except OSErrorto open() a file.
So perhaps our best chance to work with this difference is the following code:
try:
    with open(args.json_covers, "r") as f:
        ...
except (IOError, OSError):
    print("File error something rather with file: " + args.json_covers)

This is OK with me.
Maybe there is code for a FileNotFound exception that works the way it should. Perhaps in one of the 2/3 compatibility libraries, like compat or six or some other.

The PEP 3151 that I mentioned above cleans up many issues that arose from the inconsistencies around IOError and OSError. I don’t think it’s worth the effort to try to implement a Py3.4+ style FileNotFoundError in the face of such inconsistencies.
I’ve just tested except (OSError, IOError) on Py2.7 and Py3.3/4/5 and it works just fine. Committed fix https://github.com/mgiraldo/tenprintcover-py/commit/7cc2fc19b4cee6928c5e012eed15462ffb1e46b2.


Why is there no mention of SCM_USE_FUNCPACK in this reference?

I think that config should be documented in here

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

ID: 18aa54fd-3aa1-37c5-925c-51a0195b1030
Version Independent ID: 60198016-1ea9-e7ae-b00b-2c665d5ad8ca
Content: App settings reference for Azure Functions
Content Source: articles/azure-functions/functions-app-settings.md
Service: functions
GitHub Login: @tdykstra
Microsoft Alias: tdykstra

@rfigueroa Thanks for the feedback! We are currently investigating and will update you shortly.

@tdykstra can you please review and determine if we should add more context to this doc?

@rfigueroa Thanks for the suggestion -- however, this article is specifically for Azure Functions settings, while SCM_USE_FUNCPACK is not function-app-specific. It's documented on the Kudu wiki.

@tdykstra I agree SCM_USE_FUNCPACK not being function-app-specific, but maybe make the kudu wiki more visible on the Azure function Documentation.
Thanks for the response, I will close this issue

but maybe make the kudu wiki more visible on the Azure function Documentation.

That's a good idea, I'll add a link to the Kudu wiki on that page.


Switch Graphics to submit draw calls as they come.

There is no need to wait for the end of the frame.
cc @bvssvni

Closing this as it seems outdated. We moved towards a CommandBuffer + CommandQueue approach.


Added 'hideLabel' option

In my case, I don't need labels because placeholders are enough for me
Also this doesn't really conflict with anything and I noticed that it was already requested so I don't see why not

Placeholders are not mean to be used as labels; only as example input. It’s a UX antipattern to abuse placeholders for infield labels, and it goes against the standard as well.
This seems related to https://github.com/caolan/forms/issues/94#issuecomment-36194091 - i don’t mind a way to get only the input if there’s a need, but i don’t want to encourage necessary labels to be hidden.

Okay, but this also makes it possible to render the labels separately, like python's wtforms (although the div's still there). The option can be named inputOnly instead of hideLabel if you want.


pac modulebuilder build doesn't generate method summary comments in the EntityOptionSetEnum.cs file

I noticed a minor nit when using pac modulebuilder as below:
pac modelbuilder build --writesettingsTemplateFile --namespace ACME.Entities --serviceContextName ServiceContext --emitfieldsclasses --entitynamesfilter "account;contact" --suppressGeneratedCodeAttribute --outdirectory EntityModel2 --suppressINotifyPattern true
Nit: The method documentation is not generated in the EntityOptionSetEnum file, whereas it's added to on most (all?) other methods in other files.

This has been corrected and will be published as part of the next patch.

This has been Added in PAC CLI 1.21.8


HTMLHint and flake8 doesn't lint when creating or opening a file

Hi @w0rp
Here i recorded the issue https://asciinema.org/a/0n97nbmci590y3o6sek4s50l0
So first i created html file with empty title tag and no errors were displayed
Then i ran htmlhint on this file to show that htmlhint is actually works
After that i created test.js file with some errors and returned back to test.html file and as result ale start to display error.
After that i closed neovim and reopen test.html file and again ale didn't show any error. It start showing them only after i open test.js file and return back to test.html
$ htmlhint -V
0.9.13

$ nvim -v
NVIM v0.1.6-175-g7246750

Thank you

I think BufReadPost fires before the buffer is actually fully read. We might just have to increase the milliseconds delay for running linters when buffers are opened some more.

I noticed the same issue with flake8 for python

I just pushed a commit to increase the delay for linting when a buffer is opened from 100ms to 300ms. Let me know if that fixes your issues.

I tried, but unfortunately the issue still persists.
Also i tried to increase the delay up to 1 second and it didn't help, so i don't think that the problem is in delay.

Hi @w0rp i'm closing this issue because i tried to reproduce it with minimal configuration and everything works fine so i guess there are some problems with my configuration and not with ale
Sorry for bothering with that and thank you for great plugin!

I would be interested to know what configuration caused the issues you experienced, if you can find that out. I could put the information in the FAQ.

Sure, i will inform you when i find out


fix(vue): select and combobox root

I managed to get something like:
export const Select = defineComponent(
  (props: SelectProps<CollectionItem>, { slots, attrs, emit }) => {

but it's worse and infers emits to the return type.
Trying to get generics done isn't working because of any errors about slots, attrs and emit.
My workaround returns what we want, but with one bug - now it is possible to use string along with object (I think users won't make this mistake, the console will show errors). Yeah, so it's working better than earlier

@TylerAPfledderer I've made a workaround to generics for now. It's simple and works better without serious issues.
Tell me if it makes sense to merge

Yeah, that's my reasoning. In addition, if we move to SFC then we'll rewrite these components too.


Broken link to Algodiff module.

The link to Algodiff module on https://www.cl.cam.ac.uk/~lw525/owl/chapter/operator.html is broken.
It leads here https://github.com/owlbarn/owl/blob/main/src/owl/optimise/owl_algodiff_generic.ml i.e. nowhere.

Hi is this the right link to the required module?
https://github.com/owlbarn/owl/blob/ab3aeb97cc25ba5bae125add82b069227ee3af65/src/owl/algodiff/owl_algodiff_primal_ops.ml

Thanks for pointing it out. The mentioned doc is not actively maintained now. The algodiff code is currently positioned at: https://github.com/owlbarn/owl/tree/main/src/base/algodiff .


[Add a Play]: Dice Simulator

What's the Play about?
A dice simulator for RPGs such as DnD, where you decide the dice range, if you add any bonus, or if you have an advantage or disadvantage so that you can play more than one dice at once.
What ReactJS concept will be used to create this play?

Components
useEffect
useState

Record

[X] I have checked the existing issues
[X] I have read the Contributing Guidelines
[X] I want to work on this issue
[x] I am in Hacktoberfest

Code of Conduct

[X] I agree to follow this project's Code of Conduct

@priyankarpal I would like to know if it is possible to reopen this issue. I made a pull request, and I am waiting it to be approved


Build integration test for inventory performance regression

[x] First build manual Test -
Create static data-set - as baseline
Each release we run data-set and eval if we are within +/- 5%-10% of the baseline time.
[ ] Once we have manual test in place we need to automate an integration test

@joecheuk this issue was to cover both the manual and automation. (See tasks above). I have created #3327 to include in the Epic #2906