Check return type of error handler passed to Future.then, like we already do for Future.catchError

Error handlers passed to both Future.catchError and Future.then and intentionally typed too wide, to allow passing both 1- and 2- argument handlers. This unfortunately could lead to run-time type errors when these error handlers are executed.
Analyzer already provides checks for error handlers passed to these (and some other) methods. Unfortunately while the check for catchError checks the return type, the check for then does not. I propose to extend the latter to also cover the return type.
In fact, I don't see why the two couldn't be performed by the same code, as the requirements seem to be the same.
I've tried to unify the two checks in https://dart-review.googlesource.com/c/sdk/+/352362 but it comes with some issues:

the existing check for catchError seems too strict and not fully consistent: if an error handler returns dynamic, it fits everywhere (with stict casts disabled), while if it returns Future<dynamic> the check complains about Future<dynamic> not being assignable to FutureOr<T>. Looking at the actual Future implementation we probably want to unwrap the future type before checking if the return type is assignable. This seems like something that should be fixed.
void is not assignable to Null. This is correct, since void technically can be anything. But results in many annoying cases where Future argument type was inferred to be Null, but the error handler has declared return type void (even though it will be null at runtime). Here I'm undecided. Technically this is correct, but will require lots of cleanup. And the cleanup is not that great, adding explicit type arguments where they could perfectly be inferred. OTOH, this was already done for catchError, so maybe it won't be that bad for then...
both finding code and message are specifically about catchError. What should I do:

keep the code, make the message more generic;
change both code and message to be more generic;
add a new code for then onError handler return type?

cc @srawlins

Looking at the actual Future implementation we probably want to unwrap the future type before checking if the return type is assignable. This seems like something that should be fixed.

This sounds right to me.

But results in many annoying cases where Future argument type was inferred to be Null, but the error handler has declared return type void (even though it will be null at runtime). Here I'm undecided. Technically this is correct, but will require lots of cleanup. And the cleanup is not that great, adding explicit type arguments where they could perfectly be inferred.

Ugh, yeah this is annoying. We could punt on it and leave a TODO. Since already the story is that we don't report enough things; nothing wrong with incrementally reporting one more category, then one more...
Are many Future type arguments inferred to be Null because they are something like Future.delayed or Future.value with no value? I'm hoping we can get some better "constructors" / static methods like Future.void and Completer.completeVoid. Maybe Future.voidDelayed. https://github.com/dart-lang/sdk/issues/53364

both finding code and message are specifically about catchError. What should I do:
add a new code for then onError handler return type?

Yeah I think that would be idiomatic to the rest of analyzer's errors/warnings: if it's not a combinatoric explosion of individual codes, we like to have separate codes with separate text. Unless the change in text is just "catchError" --> "then", in which case we can use interpolation and a single code.

It depends on whether we want type checks of the error handler, or the value it returns.
The most correct check is to check that the onError callback for a .then<R>(...) call has type FutureOr<R> Function(Object) or FutureOr<R> Function(Object, StackTrace)
The context type of Function makes it very hard to infer the necessary return type, even if you want to, so we don't do that.
So we heck that the onError handler at least has type Object? Function(Object) or Object? Function(Object, StackTrace), so we can call it, and delay checks on the result.
Here we can again chose to check for FutureOr<R> or we can check for R or Future<Object?>, and wait for the Future and then check if its value is an R. (If not, the future will complete with a type error.)
I don't remember what we do here, probably check FutureOr<R> because we just try to complete the then call's return future with the returned value, which does that check.
We could change it, but it's not like we want to allow any Future to be returned.
I wish that we could change the type of the onError to FutureOr<R> Function(Object, StackTrace). Same for catchError. That's probably going to be quite breaking, so it's a hard sell.

Ugh, yeah this is annoying. We could punt on it and leave a TODO. Since already the story is that we don't report enough things; nothing wrong with incrementally reporting one more category, then one more...

Well, ideally I'd like to use the same code for catchError and then (maybe others?) and catchError already enforces this, so things like
void handle(dynamic err) {}

future.then((_) {} /* this makes R=Null */).catchError(handler);  // 'void' isn't assignable to 'FutureOr<Null>'

already cause complains. So, sure, we can fix one thing at a time, but unfortunately that prevents us from merging the code that checks catchError and then.

Are many Future type arguments inferred to be Null because they are something like Future.delayed or Future.value with no value? I'm hoping we can get some better "constructors" / static methods like Future.void and Completer.completeVoid. Maybe Future.voidDelayed. #53364

I don't have any representative statistics, but in my experience it was mostly about inline void callbacks, that result in overall inferred type Future<Null>. I think Future.value() is actually Future<dynamic> BTW.

Yeah I think that would be idiomatic to the rest of analyzer's errors/warnings: if it's not a combinatoric explosion of individual codes, we like to have separate codes with separate text. Unless the change in text is just "catchError" --> "then", in which case we can use interpolation and a single code.

Got it, thanks! Yep, probably interpolation would be a good fit here.

@lrhn Yep, we want to check the static type of the handler, and as part of it we want to check it returns FutureOr<R>. I just thought I found two corner cases:

error handler returning Future<dynamic>. Now this complains if expected type is not Future<dynamic>. And I thought this could be relaxed, because the implementation awaits the handler result before trying to cast it to the expected type. But I was wrong, the implementation actually immediately tries to return the result, which implies casting it to FutureOr<R>, so complaining about a handler returning Future<dynamic> is correct and desired. So this is not a corner case after all and the existing behavior is good.
Futures that are logically meant to be Future<void> often get inferred type Future<Null>, so we start barking on void returning handlers, because technically void is not assignable to FutureOr<Null>. This is correct but somewhat annoying behavior.

I wish that we could change the type of the onError to FutureOr Function(Object, StackTrace). Same for catchError. That's probably going to be quite breaking, so it's a hard sell.

I'd love to see that happen, but yeah, it's going to break all 1-argument handlers.


PR:  add and implement features to constellation

Looks good :) We probably need to parameterize the target IP address at some point. Maybe some environmental variables or something.


If I try to use a flag in CLI that is not defined, gets a panic

If try tu run a small minimal app with climax, that doesn't have 't' flag defined, I get a panic:
 # ./stellar-stacy serve -t=3
panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xb code=0x1 addr=0x40 pc=0x4814b6]

goroutine 1 [running]:
github.com/tucnak/climax.parseContext(0xc8200a0410, 0x1, 0x1, 0xc82007e260, 0x1, 0x1, 0x1, 0x0, 0x0)
	/home/foo/go/src/github.com/tucnak/climax/context.go:97 +0x496
github.com/tucnak/climax.Application.Run(0x78c890, 0x6, 0x7c1b80, 0x10, 0x821350, 0x13, 0xc8200ba180, 0x1, 0x1, 0x0, ...)
	/home/foo/go/src/github.com/tucnak/climax/application.go:117 +0xa19
main.main()
	/home/foo/go/src/myserver/myroot/stellar-stacy/main.go:21 +0x173

When launching it with a flag that exists, it works fine. The climax.Command structure I used is the one defined on the main github page.

@lstep My bad, will fix ASAP (once I get to my PC)


fixed escaping of $ chars in JVM_OPTS settings

I was debugging why i still get a connection refused error when trying this command  in the 3-node cluster section of the README:
docker run -i -t poklet/cassandra nodetool -h $(./scripts/ipof.sh cass1) status
I did not solve it yet, but while digging, I noticed something that may not be what you intended.
I'm pretty much a total noob, so please just disregard if I am wrong here.

Good pick up! Thanks!
We're all noobs learning from each other.

Hey, @dj80hd. Did you manage to solve the "Connection refused" problem? I'm experiencing the issue right now and I'm out of guesses for now.
(Docker 1.7.1, Ubuntu 14.40, the container image I've pulled from https://registry.hub.docker.com/u/poklet/cassandra/

@aides I don't quite remember if i got it working.  I eventually started creating my own Cassandra containers.   The first thing I would check is that cassandra is starting up correctly in the container:
% sudo docker run -d --name cass1 poklet/cassandra
% sudo docker logs cass1
I am running Docker 1.7.0-dev, on ubuntu 14.40 and it is showing me some critical errors:
The container seems to run, but I get connection problems even when I try to run cqlsh locally on the cassandra container like this:
% sudo docker exec -it cass1 cqlsh

@dj80hd Thanks for looking into this. I see that cassandra actually works, as I managed to cqlsh into both of running containers(from one more container) and execute queries there. I also see that port 9160(for cqlsh) is opened for remote connections. And 7199 (for JMX) is opened for localhost only.
I also see "LOCAL_JMX=yes" in cassandra-env.sh and that speciously looks like 7199 is closed because of that.
But if 7199 is really closed for remote connections then it is impossible to complete "10 nodes cluster" case from README.md, as nodetool is used to connect to the SEED node.
I wonder if @pokle can chime in to clarify this behavior.

I think I've figured that out.
I've set
LOCAL_JMX=no
and
JVM_OPTS="$JVM_OPTS -Dcom.sun.management.jmxremote.authenticate=false"
After that I've restarted cassandra by killing the PID (not sure its the best way to do so)
and now I can nodetool into that container.
I'm not sure whether the start.sh should be updated or README.md, but anyway this thread might help someone.

@aides Awesome!  Thanks for contributing back.  @pokle has been really cool about pull requests, you might just want to hit him up that way...

Yup send through a pull request


Missing UTIL folder with sample JCLs to compile the programs

Step #4 (Compile the Programs) refers to UTIL folders:

We have however provided some sample JCLs in UTIL folders in git to help you craft the JCL

However, there is no UTIL folder and I do not see a JCL that invokes a COBOL compiler.
Can you provide sample JCLs for building the CARDDEMO?

Thanks for pointing this out.
We have provided sample compile JCLs in the samples folder and have updated the README
Note that these JCLs are only samples. You will still need to speak to your administrator and follow the compile JCL process that is approved in your environment

Thank you. I am installing it to my own ZD&T now so I can do everything :-) I am thinking about automating the build and deployment process using Zowe CLI (https://www.zowe.org/). Would you be interested if I contribute such scripts?

Yes indeed.
Sent from my iPhone. Please excuse abbreviations and typos
On Oct 13, 2022, at 2:41 AM, Petr Plavjaník @.***> wrote:

Thank you. I am installing it to my own ZD&T now so I can do everything :-) I am thinking about automating the build and deployment process using Zowe CLI (https://www.zowe.org/). Would you be interested if I contribute such scripts?
—
Reply to this email directly, view it on GitHubhttps://github.com/aws-samples/aws-mainframe-modernization-carddemo/issues/7#issuecomment-1277169716, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AUPJCI734RXPWCGWRC5MWZDWC64IZANCNFSM6AAAAAARDJXEEQ.
You are receiving this because you modified the open/close state.Message ID: @.***>


Lazy-load some js libraries

WIP on lazy-loading external libraries.

I'll give up on the current PR. The problems are:

Although it's somewhat nice to be able to say withLoadables(['toastify', 'Select']) and such, I feel that there's a level of indirection, specially as there should be some level of inteligence in the component that uses the lazy component. I don't think we can provide a solution for all of the components, how they should behave when the lazy component hasn't been loaded yet.
All tests then need to include a mock. We can automock it, but they still need to beforeAll force the lazy components to load.

It's been a great learning opportunity, but I'll pass for now. I'll try to use this knowledge to further enhance the HTML block, that one is a bit of a pain to lazy-load because of the Prism library.

@tiberiuichim I see the following traceback when creating a page.

TODO on this PR:

fix the HTML block test (the snapshot was wrongly updated)
provide "bundles", a way to preload a set of libraries. Instead of loading the extra libs "on demand" and be faced with empty components, why not preload them when we login, or when faced with the Edit screen?

TODO on this PR:

fix the HTML block test (the snapshot was wrongly updated)
provide "bundles", a way to preload a set of libraries. Instead of loading the extra libs "on demand" and be faced with empty components, why not preload them when we login, or when faced with the Edit screen?

TODO:

add ref forwarding
rename the "withLoadables" to "injectLazyLib"
provide a "preload" hoc/hook pair that can preload some libraries

TODO:

add ref forwarding
rename the "withLoadables" to "injectLazyLib"
provide a "preload" hoc/hook pair that can preload some libraries

Rename to injectLazyLibs

Rename to injectLazyLibs


fix: firefox suggesting unlock passcode on nostr private keys

Describe the changes you have made in this PR
Hints Firefox password manager that the Nostr private keys are not password for the same (no user) that is the unlock password.
Link this PR to an issue [optional]
Fixes #2489
Type of change

fix: Bug fix (non-breaking change which fixes an issue)

How has this been tested?
On Firefox (Linux) I have set up 3 accounts with 3 different nostr private keys, later I opened about:logins and searched for "moz". Firefox didn't replace my unlock passcode, the password for the (no username) user.
Checklist

[x] My code follows the style guidelines of this project and performed a self-review of my own code
[ ] New and existing tests pass locally with my changes
[ ] I checked if I need to make corresponding changes to the documentation (and made those changes if needed)

But you still want to be able to save your nostr key in the password manager, is that right?

But you still want to be able to save your nostr key in the password manager, is that right?

Yes, the password manager will still be able to save the nostr private key of an account as a password, however now it will use the account name as the username, instead of the (no username) user.
In other words: the Firefox password manager will still save your nostr private key as a password if you choose to, and it will not overwrite the existing unlock passcode as it did before.

interesting! great find @fczuardi wow.
it sounds like a bit of a strange FF behavior.
@reneaaron any objections to merge this?
@fczuardi maybe we can add a link to the issue in the comment.

interesting! great find @fczuardi wow.
it sounds like a bit of a strange FF behavior. @reneaaron any objections to merge this? @fczuardi maybe we can add a link to the issue in the comment.

reference to the issue added

hey @fczuardi  thanks for making up the PR. we had a lot of changes in Alby screens the past few days. so I decided to make a new pr. we corrected the autocomplete problem on all the password fields that firefox is causing. closing this in favour of #2595.

Hi @pavanjoshi914,
I remember we tried the autocomplete new-password path and the issue persisted, that's why our approach was the hidden field path. But I can try to reproduce it on my Firefox and your branch tomorrow and let you know if we should reopen the issue or not.
-------- Original Message --------
On Jul 28, 2023, 06:17, Pavan Joshi wrote:

hey @.***(https://github.com/fczuardi) thanks for making up the PR. we had a lot of changes in Alby screens the past few days. so I decided to make a new pr. we corrected the autocomplete problem on all the password fields that firefox is causing. closing this in favour of #2595.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: @.***>

thanks for helping out there! please do test and let me know! on my side. issue is resolved for firefox password manager as well. let me know if issue persist on your side

where did you tried new-password field? on form level or on text field?

Hi @pavanjoshi914 I just confirmed on the master branch (that have your patch) and Firefox+Linux the issue is still reproducible. Entering a Nostr private key on the Nostr Settings and accepting the Firefox prompt to save the password, it will overwrite the saved unlocking passcode (the password with "no username" in the password manager), see screenshots below:

we use new-password on all the fields except unlock field. even if you save nostr private key in pasword manager. it will not autocomplete the field. in the nostr text field. as it will always default to new-password. the current discussion was to just disable autocomplete for all other fields or don't allow any saving feature on other fields. and only accept auto-complete for unlock fields.
if we use the hidden field on nostr private key. it will also disable autocomplete feature. then why to save private key in password manager?
regarding unlock fields, we don't put any restrictions there. probably we can disable autocomplete there as well. cc @rolznz @reneaaron @bumi

The password manager wont autocomplete the nostr private key field, thats correct. But if someone accepts the firefox prompt asking to save the password (by accident or by habit) on the setting page it will overwrite the unlocking password with nostr private key.
Issue https://github.com/getAlby/lightning-browser-extension/issues/2489 was indeed about the other way around (unlocking password getting autocompleted on nostr field) and that is not happening anymore. However, after the fix we now have a new problem: nostr private key getting autocompleted on the unlocking passcode field.
Should we open a new issue then? instead of reopening #2489 ?
@pavanjoshi914 do you see my point? What my screenshots show is something that is not the unlocking passcode being completed on the unlocking passcode field.
The statement below is not true:

if we use the hidden field on nostr private key. it will also disable autocomplete feature.

It wont.

if we use the hidden field on nostr private key. it will also disable autocomplete feature.

if we use the hidden field on nostr private key. it will also disable autocomplete feature.

The password manager wont autocomplete the nostr private key field, that's correct. But if someone accepts the firefox prompt asking to save the password (by accident or by habit) on the settings page it will overwrite the unlocking password with nostr private key.

regarding unlock fields, we don't put any restrictions there. probably we can disable autocomplete there as well


Add README-docker-compose.md and reference it from README.md and dock…

…er-compose.yml

Purpose

Changes

Side effects

Ticket

@icereval CR for me? I think it's all right. Links work, seems like English.

Does this replace README.md? if not you'll want to update the Running the OSF section.

I added it here, above Running the OSF and changed Running the OSF to Running the OSF locally.

I made it more explicit. https://github.com/cwisecarver/osf.io/blob/feature/update-docker-compose-readme/README.md#running-the-osf

Still need to add something about migrations, then I'm gtg.


[AutoDiff] Add missing swift/Basic/Debug.h include.

Needed to use llvm::dbgs() in include/swift/SILOptimizer/Differentiation/AdjointValue.h.

This should fix a master-next CI failure, though I haven't verified locally:

08:52:11 /usr/local/bin/sccache /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++  -DCMARK_STATIC_DEFINE -DGTEST_HAS_RTTI=0 -DSWIFT_ENABLE_RUNTIME_FUNCTION_COUNTERS -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Ilib/SILOptimizer -I/Users/buildnode/jenkins/workspace/oss-swift-incremental-RA-osx-master-next/swift/lib/SILOptimizer -Iinclude -I/Users/buildnode/jenkins/workspace/oss-swift-incremental-RA-osx-master-next/swift/include -I/Users/buildnode/jenkins/workspace/oss-swift-incremental-RA-osx-master-next/llvm-project/llvm/include -I/Users/buildnode/jenkins/workspace/oss-swift-incremental-RA-osx-master-next/buildbot_incremental/llvm-macosx-x86_64/include -I/Users/buildnode/jenkins/workspace/oss-swift-incremental-RA-osx-master-next/llvm-project/clang/include -I/Users/buildnode/jenkins/workspace/oss-swift-incremental-RA-osx-master-next/buildbot_incremental/llvm-macosx-x86_64/tools/clang/include -I/Users/buildnode/jenkins/workspace/oss-swift-incremental-RA-osx-master-next/cmark/src -I/Users/buildnode/jenkins/workspace/oss-swift-incremental-RA-osx-master-next/buildbot_incremental/cmark-macosx-x86_64/src -Wno-unknown-warning-option -Werror=unguarded-availability-new -fno-stack-protector -fPIC -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -Wimplicit-fallthrough -Wcovered-switch-default -Wno-class-memaccess -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wstring-conversion -fdiagnostics-color -Werror=switch -Wdocumentation -Wimplicit-fallthrough -Wunreachable-code -Woverloaded-virtual -DOBJC_OLD_DISPATCH_PROTOTYPES=0 -O3  -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk    -fno-exceptions -fno-rtti -Werror=gnu -UNDEBUG -target x86_64-apple-macosx10.9 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk -arch x86_64 -F/../../../Developer/Library/Frameworks -mmacosx-version-min=10.9 -O2 -g0 -std=c++14 -MD -MT lib/SILOptimizer/CMakeFiles/swiftSILOptimizer.dir/Differentiation/JVPEmitter.cpp.o -MF lib/SILOptimizer/CMakeFiles/swiftSILOptimizer.dir/Differentiation/JVPEmitter.cpp.o.d -o lib/SILOptimizer/CMakeFiles/swiftSILOptimizer.dir/Differentiation/JVPEmitter.cpp.o -c /Users/buildnode/jenkins/workspace/oss-swift-incremental-RA-osx-master-next/swift/lib/SILOptimizer/Differentiation/JVPEmitter.cpp
08:52:11 In file included from /Users/buildnode/jenkins/workspace/oss-swift-incremental-RA-osx-master-next/swift/lib/SILOptimizer/Differentiation/JVPEmitter.cpp:20:
08:52:11 In file included from /Users/buildnode/jenkins/workspace/oss-swift-incremental-RA-osx-master-next/swift/include/swift/SILOptimizer/Differentiation/JVPEmitter.h:21:
08:52:11
/Users/buildnode/jenkins/workspace/oss-swift-incremental-RA-osx-master-next/swift/include/swift/SILOptimizer/Differentiation/AdjointValue.h:168:34: error: no member named 'dbgs' in namespace 'llvm'
08:52:11   SWIFT_DEBUG_DUMP { print(llvm::dbgs()); };
08:52:11                            ~~~~~~^
08:52:11 1 error generated.

@swift-ci Please smoke test

You would need to include llvm/Support/Debug.h. Did not compile for me without it. swift/Basic/Debug.h does not include it.
diff --git a/include/swift/SILOptimizer/Differentiation/AdjointValue.h b/include/swift/SILOptimizer/Differentiation/AdjointVal
ue.h
index 104a3f0bc69..4b316835518 100644
--- a/include/swift/SILOptimizer/Differentiation/AdjointValue.h
+++ b/include/swift/SILOptimizer/Differentiation/AdjointValue.h
@@ -21,6 +21,7 @@
 #include "swift/AST/Decl.h"
 #include "swift/SIL/SILValue.h"
 #include "llvm/ADT/ArrayRef.h"
+#include "llvm/Support/Debug.h"

 namespace swift {
 namespace autodiff {

I have pushed that fix to the repo.


Update hyperlink for java implementation

The old link is broken due to skylark -> starlark rename

Thank you!


Code optimisation topic

some ideas :

I would check if the performance of skdecide are good in simple deterministic problems like the maze we present : indeed the fact that we create objects everytime we call get_next_state() function for example can be inefficient comparing to direct shortest path algorithm using a precomputed graph. some old piece of code was written to analyze that :

https://github.com/airbus/scikit-decide/blob/master/skdecide/hub/solver/graph_explorer/FullSpaceExploration.py : in this class we accomplish a full exploration of the domain in order to build a representation of the domain as a graph (dictionnary of (state,action)->new state. using this new representation of a domain was speeding up by a big factor the resolution using A* for example. We can try to unearth this pieces of code (because they are probably deprecated) and do the analyzis.

Statefull Scheduling performance :
https://github.com/airbus/scikit-decide/blob/master/skdecide/builders/domain/scheduling/scheduling_domains.py
the statefull representation (i.e modelizing the scheduling problems as MDP problems as done in skdecide) is extremely costly.
an analyzis of computation time could be usefull to identify what is the part of the code that could be optimized.
some hints :

hash code, comparaison of state object are rudimentary (https://github.com/airbus/scikit-decide/blob/master/skdecide/builders/domain/scheduling/scheduling_domains_modelling.py)
the scheduling domain are creating new state object that contains a lot of information, and empirically this takes most of the computation time : there is an attribute in SchedulingDomain called "inplace_environment". If this attribute is True, the state passed in the get_next_state functions are changed in place and not copied : this reduces a lot the computation time. However this trick makes impossible the use of some graph based algorithms.

What do you call good or bad performance for the maze? For instance for A*, it last less than 1'', is it not satisfactory? We should probably optimize on cases where too much time is lost rather than on cases where it does not bother anyone.

Here is a notebook which compares A* implementations in networkx and scikit-decide and provides some ideas to improve performance.  All computations have been performed offline, this notebook displays results fast, and explains how you can re-run it locally if you want

Code is in db/benchmarking branch in my fork.


Add list of implementations and example mutex use

The example feels a bit half-hearted but I think it might still be worth having something like this. Very happy to take suggestions to improve the example, or any more implementations we should link.

Thanks! Anything else before a release?

can't think of anything, no.


Show live channels. Start stream with streamlink

Issue :
I am rarely, if ever, interested in joining chats of channels that aren't live. Also, I usually want to watch the stream I'm chatting in.
Solution :
Change list of followed to list of followed that are currently streaming.
Start stream in streamlink when selecting a channel. Stops stream upon opening another stream, or closing twt
I've made the necessary code changes to achieve this, but some things are quite hacky. I can submit a PR we can review and refine together if these are changes you're interested in.

Hello! This sounds like a great idea. Feel free to create the PR whenever, and I'll take a stare at it. Thanks!


Merge PDF

What were you trying to do?
Hallo.
I want to merge serveral PDF to one pdf.
How did you attempt to do it?
async function MergePDF(pdfstring) {
const { PDFDocument } = PDFLib
const pdf = JSON.parse(pdfstring)
var pdfsToMerge = [];

Microsoft.Dynamics.NAV.InvokeExtensibilityMethod("MergePDF_Begin", '');

for (var j = 0; j < pdf.length; j++) {
    var pdf64 = pdf[j].pdf;
    var raw1 = window.atob(pdf64);
    var len1 = raw1.length;
    var pdfBuffer1 = new Uint8Array(new ArrayBuffer(len1));
    for (var i = 0; i < len1; i++) {
      pdfBuffer1[i] = raw1.charCodeAt(i);
    }

    pdfsToMerge[j] = pdfBuffer1;
}

const mergedPdf = await PDFDocument.create();
for (const pdfBytes of pdfsToMerge) {
    const pdf = await PDFDocument.load(pdfBytes);
    const copiedPages = await mergedPdf.copyPages(pdf, pdf.getPageIndices());
    copiedPages.forEach((page) => {
      mergedPdf.addPage(page);
    }
  );
}

// ---

const buf = await mergedPdf.saveAsBase64();
var pdftoNAV = [buf]

Microsoft.Dynamics.NAV.InvokeExtensibilityMethod("DownloadPDF", pdftoNAV);

}
//
The Lines Microsoft.Dynamics.NAV.* are Eevents to Outside Javascript.
The Javascript is called by Microsoft BC 365.
What actually happened?
I test with PDF Dokuments I have on may disk.
Some PDF not Merged.  This PDF -"Part" are Missing in merged PDF
What did you expect to happen?
I want that all PDF Dokuments to merge are Merged in one PDF.
How can we reproduce the issue?

Version
the last of your homepage
What environment are you running pdf-lib in?
Browser
Checklist

[X] My report includes a Short, Self Contained, Correct (Compilable) Example.
[X] I have attached all PDFs, images, and other files needed to run my SSCCE.

Additional Notes

Not sure I understand what you're trying to do with the Microsoft stuff. If you need a method that merges PDFDocument objects, I wrote this one up:
/***

@param frontPDF - a PDFDocument object
@param rearPDF - a PDFDocument object
*/
async function mergeDocuments(frontPDF, rearPDF) {
const copiedPages = await frontPDF.copyPages(rearPDF, [...Array(rearPDF.getPageCount()).keys()]);
copiedPages.forEach((page) => {
frontPDF.addPage(page);
})
}


Checkout address handling

There are a few minor issues around address handling in the checkout that need addressing.  These mainly arise when shipping to two different territories where the address form is different for each one.

It should be possible to edit the list of address book addresses shown.  Eg when shipping within US, only show US addresses
Editing an existing address should use a similar form to the shipping address form.  Eg customisation to the main shipping address form should be reflected on the user address form too.

It should be possible to edit the list of address book addresses shown. Eg when shipping within US, only show US addresses

It can be easily customized in ShippingAddressView.get_available_addresses method which user addresses to display in the current checkout session.

Editing an existing address should use a similar form to the shipping address form. Eg customisation to the main shipping address form should be reflected on the user address form too.

User address and shipping address forms inherit the same base address form, which also requires mandatory address fields to be defined (per OSCAR_REQUIRED_ADDRESS_FIELDS setting). Thus, if both models have the same custom field - we can just add it to the setting. At the same time, forms also allow to specify fields per form, which allows to use fields, specific only for shipping or user address model which also provides enough of flexibility.
Ultimately, both minor issues can be easily addressed by customization, which should be sufficient for now.


chore: update action.yaml

Description
Bind to 7.2.3 directly for a bit so that CI machines that have the faulty 7.2.2 version installed are updated to a working version.
Checklist

[x] Tested manually
[x] Unit tests pass with no errors or warnings
[x] Documentation updated (if applicable)
[ ] Reviewed by at least 1 other contributor

This is not the problem...


[terminal] background not correctly handled in terminal emulator inside vim

vim always set a background color for the terminal emulator inside, and it's not matching the outer terminal's background.

switching to terminal normal mode cause the terminal buffer get the normal background, with the printed texts have the wrong background.

tested with gnome-terminal, terminator and terminology, xterm also have this problem if bg is set to 'light'.

... if bg is set to 'light'.

That's the root cause.  When the background color of the terminal is dark, you are supposed to set  the 'background' option to dark.  This is rather mandatory than optional.  Here is an excerpt from :help 'background':

When set to "dark", Vim will try to use colors that look good on a dark background.  When set to "light", Vim will try to use colors that look good on a light background.  Any other value is illegal.
[emphasis mine]

But set background to dark not get the background match the outside terminal, for example:

Then, you are choosing the background color different from that of the terminal, right?

No, I just used a terminal which default background is not black.

A transparent background example

For comparison, what happens if both gnome-terminal and Vim use their default settings?

with default settings, vim assumes the bg is light, which is posted at very beginning. when set vim bg to dark, the result is in the second post. the last post shows vim terminal emulator cannot handle transparent background.

I was asking because:

The background color varies from picture to picture: While that of the first post is dark gray, that of the second post gets reddish.  That cannot happen only by changing'background' from light to dark.

By default, ctermbg of StatusLineTerm is set to DarkGreen (#006400).  However, the colors shown in the pictures apparently deviate from it to the extent that environment dependency cannot explain it.

So I cannot be certain if you compared one with another appropriately.  Will you clarify them?

The terminal of first post is terminology, gnome-terminal is used in my second post and my third post. only the third has a non-default terminal setting.
It is dark green when bg is set to dark, otherwise it is brighter as shown in the first post and the third post.

IMHO, if an issue is presented that way, people are hardly able to narrow down various relevant factors to ones causing it directly, although visualization is usually helpful for them to understand issues, especially when they can't reproduce them for themselves.
Anyway, FYI, we once got a PR about gnome-terminal last May (Actually, it was about a library it depends on, that is, VTE).  That was #1677, and the pictures presented by the PR author apparently resemble yours.
On his closing the PR (seems like the patch was'n merged), he left the following two notes:

I found an older versions of gnome terminal and do not see the issue, so apparently it's a regression. I will investigate further.  I may also try contacting JuiceSSH's developers to see what they can do.

On the gnome-terminal side, I found that this has been fixed in VTE. Bisecting VTE, I discovered it was only a couple of weeks ago: GNOME/vte@a26a60b

In another issue you've opened, #2076, you say

especially on an older version of gnome-terminal

So, there's a possibility that the issue is rather due to  some recent but older versions of VTE than to Vim.  Did you examine the issue with the latest VTE which seems to have fixed #1677?  It looks to me it's worth a try.  Or, is there someone who knows about consequences about that?

I have already tested with multiple terminal, on both linux and MacOS, with vim 8.0.1050 and 8.0.1092, all have the same problem. So I don't think it's a gnome-terminal specific problem.
To reproduce:

set terminal background to non-black (transparent or image is better)
use default color scheme
open terminal with :term and type echo hello
switch to terminal normal mode with <C-\><C-N>

In terminal buffer, switch to terminal normal mode with <C-\><C-N>

Oh my ..., this is the first time you mention it, isn't this?
I thought you had been talking about what happened with Vim in Terminal-Job mode.  Also, when I noticed the issue, it reminds me of the fact that Vim once had a glitch similar to #1677 (or yours in appearance) within a terminal in that mode, which was fixed in hours or a day.  So, that omission of <C-\><C-N> had been really, really muddling me up.
Anyway, then the behavior can be considered rather intentional with good reasons, and naturally, that is seen with every terminal no matter what it is.
By pressing <C-\><C-N>, Vim switches from Terminal-Job mode to Terminal-Normal mode (:help Terminal-mode).  That mode change can make the user much confused since it almost surely implies that the key bindings are going to drastically change from those commonly found with most terminal applications to those unique to Vim.  Also, Visual mode gets made available.  Leaving the background color of the job's output as-is would be helpful to distinguish it from another, and so on.  One thing and another, it would be very nice if Vim could notify the user of those changes in a clear but not distracting way.
So, what you've been thinking an issue can be considered an attempt to visualize that particular mode change to notify the user of the resulting significant, substantial changes at a single glance.  In fact, if you press a or ito make the mode back to Terminal-Job, then the visualization is gone.
In the case where 'background' is set to light for the dark background color, the resulting visuals can be too distracting.   No wonder if one thinks it an issue.  But again, the right thing to do for that is to correct the 'background' value.
Personally, I don't think the current behavior is wrong; however, mainly from an aesthetic point of view, I can see it natural that some people would argue on that differently.   So, IMHO, answering the questions "Is there any better way than what we have now?  How can we improve it?" is probably the first step for those who think it an issue to address it.

BTW, did you try this?
https://github.com/vim/vim/pull/2067

@mattn
To me?  Yes, I did.  But it appeared to me that redraw got a bit sluggish due to the overload caused by unprecedentedly fast scrolling, e.g., :term make test.  So I didn't think it a big deal for me at that moment.  Also, I know issues like #2067 is inherently difficult for Vim to address...

To me?

To all people in this thread. The libvterm already has a mechanism for specifying the foreground color and background color with arbitrary colors. And the default value is 255 for foreground, 0 for backgound. In the case background=light, those value are swapped. AFAIK, I can't belieave vim become slowly by # 2067. However, there is a possibility that the terminal will do so.

Even with that proposed patch, the issue of this thread remains the same unless a given true color for background happen to coincide with any color of the 256-color palette, or, to be approximated well to any of them to the extent that the differential can't be noticeable to human eyes, doesn't it?
So, if that's true and if that feature is included, the help document should have a note on the relation between colors specified with 24-bits, #rrggbb, and their actual colors resulting from 256-color palette approximation.  Honestly, I'm getting bored of explaining this sort of stuff and will leave it up to someone who is responsible for that or someone who supported our move to GitHub, so that I can do my own work to be done.

@nuko8 I think i mentioned it's terminal normal mode in the first post.
@mattn #2067 does nothing to 256color terminals.

By pressing <C-\><C-N>, Vim switches from Terminal-Job mode to Terminal-Normal mode (:help Terminal-mode). That mode change can make the user much confused since it almost surely implies that the key bindings are going to drastically change from those commonly found with most terminal applications to those unique to Vim. Also, Visual mode gets made available. Leaving the background color of the job's output as-is would be helpful to distinguish it from another, and so on. One thing and another, it would be very nice if Vim could notify the user of those changes in a clear but not distracting way.

I would position this the other way.  Terminal-Job mode is the odd mode here, since it's different than the Vim modes that existed prior to the terminal implementation.  Rather than drawing attention to when a buffer is in Terminal-Job mode, highlight when it is in Terminal-Normal mode.
From that perspective, Vim already has a way to unobtrusively handle this.  It's the 'showmode' option.  This is exactly what Neovim decided to use.  When in a terminal buffer and interacting with the terminal (aka Terminal-Job mode), the user sees -- TERMINAL -- on the last line, just like one would normally see -- INSERT -- when in insert mode for a normal buffer.

Rather than drawing attention to when a buffer is in Terminal-Job mode, highlight when it is in Terminal-Normal mode.

Actually, that's what is already happening.  I meant the reverse. :) Treat Terminal-Normal mode normally (since it behaves the most like Vim) and draw attention to Terminal-Job mode via 'showmode' instead of the jarring color changes currently taking place.

@zhykzhykzhyk if #2067 support 256 color, your issue will be solved?

@nuko8 I think i mentioned it's terminal normal mode in the first post.

Indeed :)
By the way, although @brammool didn't refer to this issue directly, he seemingly gave us a solution to the issue via 238d43b32 and 49a613f84.   They look nice to me.  How about trying them, seeing if the issue is addressed to your satisfaction, and deciding what to do with this thread?  In case you still find an issue with them, I'd suggest opening a new issue dedicated to them to avoid possible confusion.


update to kfserving diagram

update diagram for kubeflow serving + added pointers to sample notebooks

This change is

/lgtm
/approve

@animeshsingh Please add a link to the preview doc in future PRs. This will help make reviewers' lives easier.
Preview: https://deploy-preview-1237--competent-brattain-de2d6d.netlify.com/docs/components/serving/kfserving/

/assign
/lgtm


Tracker fails to load on first run - Lua Exception

From IronMON Discord: "when loading the .lua... Ironmon-Tracker v0.3.0 NLua.Exceptions.LuaScriptException: A,B,Start,Select"
This has been an ongoing issue for many versions of the tracker, including the latest 3.0.0. Several people each day report this issue. In almost all cases it can be resolved by closing everything and reopening a few times.
I'm assuming the tracker has to initiate some files on first load, but might do so in the wrong order and is unable to find the files when you first run it; hence why closing and opening again fixes it. Is this something that can be resolved, or can a more detailed message be included in the error to instruct the user to restart?

Thanks, UTDZac. We can take a look and see if we can repro to find the cause of why it is happening.

@bdjeffyp I have encountered this too. the Lua Console says:

I'll also note here in that i've seen some cases where just closing and re-opening didn't fix the issue for them but sometimes it was something to do with their Settings.ini file. At other times when I asked for the full lua console output it was indeed occurring at the point the tracker was loading files, so it's most likely relating to that as UTDZac says.
One user I remember it wouldn't work unless they provided a folder for ROMS_FOLDER (just leaving it as ROMS_FOLDER= as it is on initial download wasn't working) and another had to include a space after the ROMS_FOLDER= before their folder path for it to work. Both seemingly arbitrary things that happened to fix the issue for them.

@UTDZac, I have done some testing on a different PC, making folders with fresh installs and have been reproing the issue. In many instances, I can avoid the issue altogether if I start BizHawk, immediately close it, reopen it again and start the game and tracker. The tracker loads just fine in that instance. The only difference I can see between a new install and an install that has been opened at least once is the presence of a config.ini file that BizHawk autogenerates after it's first run. Your guess is as good as mine as to why this works... Ultimately, I believe the root issue is not the tracker, but BizHawk not being properly configured until it's first run is completed. I will update the directions to make that recommendation to people.
@Fellshadow, regarding your comment, I am baffled by the whole ROMS_FOLDER thing. It doesn't make a lot of sense what is happening there. At this point, I am beginning to suspect that using INI files is causing more issues than not. Part of the reason I made the settings menu within the tracker is because of all the problems people have been having just editing the damn thing. If I can come up with a good solution for configuring the controller settings within the tracker's settings menu, it may solve all of these problems because then the tracker is formatting the Settings.ini file in a way that would be device agnostic and without potential human error.
@Tapollo, your error looks like something else entirely. Can you make a new issue along with some steps on how you came to get that error?

Okay, I added a "step 0" to the Installation procedure in the README in PR #69 (nice). It clarifies that users who are using BizHawk for the first time must open and close it once before trying to use the tracker. This workaround isn't perfect, but it is a start. I'll work on getting @besteon to approve and merge, since I can't outright merge without a review.
@UTDZac, would you be able to update docs in the Discord to have new BizHawk users open and close the app on their first run before attempting to use the tracker, please?

@Fellshadow, regarding your comment, I am baffled by the whole ROMS_FOLDER thing. It doesn't make a lot of sense what is happening there. At this point, I am beginning to suspect that using INI files is causing more issues than not. Part of the reason I made the settings menu within the tracker is because of all the problems people have been having just editing the damn thing. If I can come up with a good solution for configuring the controller settings within the tracker's settings menu, it may solve all of these problems because then the tracker is formatting the Settings.ini file in a way that would be device agnostic and without potential human error.

I am also just as baffled, though the cases where it only worked when they edited their Settings.ini were very few. If the true culprit is bizhawk's config.ini it could be possible that maybe the config.ini got made somewhere between their fiddling with the Settings.ini? It's tough to say whether they actually closed bizhawk fully when talking about the issue in a discord text channel of course.

Trying again on latest (0.3.5), I can no longer reproduce this issue by removing my config.ini file from Bizhawk. Seems to work fine on versions 0.3.3 and up. I suspect the changes to how we handled the Settings.ini parsing have helped resolve this?

I am able to continue on and play the game normally. The tracker works fine and shows data.

This is great news! I'll go ahead and close this issue as resolved. If people are experiencing any new errors associated with starting the tracker, let's make a new issue. Thanks all for the efforts to make this fix happen!!


SAK-30007 Site tab name doesn't obey the user preferences to display …

…long or short description.

I'm planning on merge this to fix this regression, ASAP, comments?

Looks good

Agree, I was just recovering the code removed previously, but sounds reasonable to add default value in catch block, fixed and ready to merge !!


licensing requirement unclear

The following user-level configuration can only be modified when users have P1 licenses enabled for Viva Insights.
I cannot find any information about P1 licenses. Is this related to a Viva license? There is a Microsoft Entra ID P1 license - but how would that relate to this setting? Please put in the specific name of the license otherwise it is confusing.
It would also help to state if the "user" is the person running the script (admin) or the user accounts which is targeted is meant.

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

ID: d5062d99-7d49-3a2f-7c28-304abf7b940f
Version Independent ID: fa2f2c5a-116f-6870-52dd-fdc691248160
Content: Admin tasks for the Viva Insights app
Content Source: Viva/insights/personal/teams/viva-teams-app-admin-tasks.md
Service: viva
Sub-service: viva-insights
GitHub Login: @zachminers
Microsoft Alias: v-zachminers

Thank you for submitting feedback.
I think the best way forward is if you open a service ticket in your tenant so this can get resolved ASAP. Based on the outcome let me know if it is something that can be called out in the docs.
Please follow this link to contact support for business products:https://docs.microsoft.com/office365/admin/contact-support-for-business-products
Please keep us posted here on the resolution so we can feed whatever information you discover into the content.

Hello. Thank you for submitting this feedback! The content has been updated to address this feedback. You may close this ticket. Thank you.


Add region in "Get object from Ceph RGW" task

Some cloud providers like OpenStack Swift from OVH in EC2 mode need this region parameter to work.
Here is an example of how we're using this small change in our stack :
ansistrano_deploy_via: s3_unarchive
ansistrano_s3_bucket: "some-bucket"
ansistrano_s3_object: "some-object.tar.gz"
ansistrano_s3_rgw: true
ansistrano_s3_aws_access_key: "{{ vaulted_access_key }}"
ansistrano_s3_aws_secret_key: "{{ vaulted_secret_key }}"
ansistrano_s3_url: "https://s3.gra.cloud.ovh.net"
ansistrano_s3_region: gra

I don't have any setup to validate this but your change seems safe so merging it swiftly! Thanks a lot!

Thanks to you for this instant merge ! :zap:

No problem! Sorry the tag is not in Galaxy yet, the folks at Travis decided to start June blocking our pipelines, let's see if they can sort it out or we will move to Github actions (will probably happen soon anyway)

Just checked and the tag is definitely in Galaxy... oh well at least you guys have it, thanks again for your contribution


Internal drag/drop of text silently fails in IE

Do you want to request a feature or report a bug?
a bug
What is the current behavior?
This is a pretty minor issue -

Open the 'rich' example in IE.
Try to select and drag a range of text to move it within the text area. https://github.com/facebook/draft-js/wiki/Manual-Testing#internal
Notice that it fails. Nothing happens, and no errors are thrown in the console.

If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem. You can use this jsfiddle to get started: https://jsfiddle.net/stopachka/m6z0xn4r/.
What is the expected behavior?
It should drag the text. This does work in MS Edge.
Which versions of Draft.js, and which browser / OS are affected by this issue? Did this work in previous versions of Draft.js?
IE 11.576, with the latest master branch of Draft.js.

I've just encountered this issue (or similar) in Slate - https://github.com/ianstormtaylor/slate/issues/927#issuecomment-314894860
Your jsfiddle wasn't working for me in Edge actually, and the issue seems to be with inline elements such as <span> not being valid drop targets.

I'll expand on this issue by pointing out that DraftEditor's handleDrop handler is never fired in IE. That would be a very helpful method when implementing drag and drop for atomic blocks as mentioned in issue #40.


运行可以了，但是会报很多警告

2016-05-04 15:24:31.521 CFCityPickerVC[17697:4651979] Unable to simultaneously satisfy constraints.
Probably at least one of the constraints in the following list is one you don't want.
Try this:
(1) look at each constraint and try to figure out which you don't expect;
(2) find the code that added the unwanted constraint or constraints and fix it.
(Note: If you're seeing NSAutoresizingMaskLayoutConstraints that you don't understand, refer to the documentation for the UIView property translatesAutoresizingMaskIntoConstraints)
(
"<NSAutoresizingMaskLayoutConstraint:0x1545ad770 h=-&- v=-&- CFCityPickerVC.HeaderItemView:0x1545985a0.height == UIView:0x1545903e0.height - 344>",
"<NSLayoutConstraint:0x1546434a0 V:|-(8)-[UILabel:0x1547078e0'\U5f53\U524d\U57ce\U5e02']   (Names: '|':CFCityPickerVC.HeaderItemView:0x1545985a0 )>",
"<NSLayoutConstraint:0x154642cb0 V:[UILabel:0x1547078e0'\U5f53\U524d\U57ce\U5e02']-(15)-[CFCityPickerVC.CFCPContentView:0x154598c20]>",
"<NSLayoutConstraint:0x154637570 V:[CFCityPickerVC.CFCPContentView:0x154598c20]-(15)-|   (Names: '|':CFCityPickerVC.HeaderItemView:0x1545985a0 )>",
"<NSLayoutConstraint:0x154629ee0 V:|-(10)-[CFCityPickerVC.CitySearchBar:0x1545906c0]   (Names: '|':UIView:0x1545903e0 )>",
"<NSLayoutConstraint:0x154631d70 V:[CFCityPickerVC.CitySearchBar:0x1545906c0(36)]>",
"<NSLayoutConstraint:0x154631dc0 V:[CFCityPickerVC.CitySearchBar:0x1545906c0]-(0)-|   (Names: '|':UIView:0x1545903e0 )>"
)
Will attempt to recover by breaking constraint
<NSLayoutConstraint:0x154642cb0 V:[UILabel:0x1547078e0'当前城市']-(15)-[CFCityPickerVC.CFCPContentView:0x154598c20]>
Make a symbolic breakpoint at UIViewAlertForUnsatisfiableConstraints to catch this in the debugger.
The methods in the UIConstraintBasedLayoutDebugging category on UIView listed in <UIKit/UIView.h> may also be helpful.
2016-05-04 15:24:31.523 CFCityPickerVC[17697:4651979] Unable to simultaneously satisfy constraints.
Probably at least one of the constraints in the following list is one you don't want.
Try this:
(1) look at each constraint and try to figure out which you don't expect;
(2) find the code that added the unwanted constraint or constraints and fix it.
(Note: If you're seeing NSAutoresizingMaskLayoutConstraints that you don't understand, refer to the documentation for the UIView property translatesAutoresizingMaskIntoConstraints)
(
"<NSAutoresizingMaskLayoutConstraint:0x1545ad770 h=-&- v=-&- CFCityPickerVC.HeaderItemView:0x1545985a0.height == UIView:0x1545903e0.height - 344>",
"<NSLayoutConstraint:0x154629ee0 V:|-(10)-[CFCityPickerVC.CitySearchBar:0x1545906c0]   (Names: '|':UIView:0x1545903e0 )>",
"<NSLayoutConstraint:0x154631d70 V:[CFCityPickerVC.CitySearchBar:0x1545906c0(36)]>",
"<NSLayoutConstraint:0x154631dc0 V:[CFCityPickerVC.CitySearchBar:0x1545906c0]-(0)-|   (Names: '|':UIView:0x1545903e0 )>"
)
Will attempt to recover by breaking constraint
<NSLayoutConstraint:0x154631dc0 V:[CFCityPickerVC.CitySearchBar:0x1545906c0]-(0)-|   (Names: '|':UIView:0x1545903e0 )>
Make a symbolic breakpoint at UIViewAlertForUnsatisfiableConstraints to catch this in the debugger.
The methods in the UIConstraintBasedLayoutDebugging category on UIView listed in <UIKit/UIView.h> may also be helpful.
2016-05-04 15:24:31.530 CFCityPickerVC[17697:4651979] Unable to simultaneously satisfy constraints.
Probably at least one of the constraints in the following list is one you don't want.
Try this:
(1) look at each constraint and try to figure out which you don't expect;
(2) find the code that added the unwanted constraint or constraints and fix it.
(Note: If you're seeing NSAutoresizingMaskLayoutConstraints that you don't understand, refer to the documentation for the UIView property translatesAutoresizingMaskIntoConstraints)
(
"<NSAutoresizingMaskLayoutConstraint:0x1545ade40 h=-&- v=-&- CFCityPickerVC.HeaderItemView:0x1545985a0.width == UIView:0x1545903e0.width>",
"<NSLayoutConstraint:0x1546434f0 UILabel:0x1547078e0'\U5f53\U524d\U57ce\U5e02'.leading == CFCityPickerVC.CFCPContentView:0x154598c20.leading>",
"<NSLayoutConstraint:0x154642d40 H:|-(18)-[UILabel:0x1547078e0'\U5f53\U524d\U57ce\U5e02']   (Names: '|':CFCityPickerVC.HeaderItemView:0x1545985a0 )>",
"<NSLayoutConstraint:0x154642c60 H:[CFCityPickerVC.CFCPContentView:0x154598c20]-(30)-|   (Names: '|':CFCityPickerVC.HeaderItemView:0x1545985a0 )>",
"<NSLayoutConstraint:0x1545b3890 'UIView-Encapsulated-Layout-Width' H:[UIView:0x1545903e0(0)]>"
)
Will attempt to recover by breaking constraint
<NSLayoutConstraint:0x1546434f0 UILabel:0x1547078e0'当前城市'.leading == CFCityPickerVC.CFCPContentView:0x154598c20.leading>
Make a symbolic breakpoint at UIViewAlertForUnsatisfiableConstraints to catch this in the debugger.
The methods in the UIConstraintBasedLayoutDebugging category on UIView listed in <UIKit/UIView.h> may also be helpful.
2016-05-04 15:24:31.534 CFCityPickerVC[17697:4651979] Unable to simultaneously satisfy constraints.
Probably at least one of the constraints in the following list is one you don't want.
Try this:
(1) look at each constraint and try to figure out which you don't expect;
(2) find the code that added the unwanted constraint or constraints and fix it.
(Note: If you're seeing NSAutoresizingMaskLayoutConstraints that you don't understand, refer to the documentation for the UIView property translatesAutoresizingMaskIntoConstraints)
(
"<NSAutoresizingMaskLayoutConstraint:0x15471fa60 h=-&- v=-&- CFCityPickerVC.HeaderItemView:0x154704520.width == UIView:0x1545903e0.width>",
"<NSLayoutConstraint:0x15470a330 UILabel:0x1547080e0'\U70ed\U95e8\U57ce\U5e02'.leading == CFCityPickerVC.CFCPContentView:0x1547082f0.leading>",
"<NSLayoutConstraint:0x15470a380 H:|-(18)-[UILabel:0x1547080e0'\U70ed\U95e8\U57ce\U5e02']   (Names: '|':CFCityPickerVC.HeaderItemView:0x154704520 )>",
"<NSLayoutConstraint:0x15470a420 H:[CFCityPickerVC.CFCPContentView:0x1547082f0]-(30)-|   (Names: '|':CFCityPickerVC.HeaderItemView:0x154704520 )>",
"<NSLayoutConstraint:0x1545b3890 'UIView-Encapsulated-Layout-Width' H:[UIView:0x1545903e0(0)]>"
)
Will attempt to recover by breaking constraint
<NSLayoutConstraint:0x15470a330 UILabel:0x1547080e0'热门城市'.leading == CFCityPickerVC.CFCPContentView:0x1547082f0.leading>
Make a symbolic breakpoint at UIViewAlertForUnsatisfiableConstraints to catch this in the debugger.
The methods in the UIConstraintBasedLayoutDebugging category on UIView listed in <UIKit/UIView.h> may also be helpful.
2016-05-04 15:24:31.538 CFCityPickerVC[17697:4651979] Unable to simultaneously satisfy constraints.
Probably at least one of the constraints in the following list is one you don't want.
Try this:
(1) look at each constraint and try to figure out which you don't expect;
(2) find the code that added the unwanted constraint or constraints and fix it.
(Note: If you're seeing NSAutoresizingMaskLayoutConstraints that you don't understand, refer to the documentation for the UIView property translatesAutoresizingMaskIntoConstraints)
(
"<NSAutoresizingMaskLayoutConstraint:0x1545b1900 h=-&- v=-&- CFCityPickerVC.HeaderItemView:0x1547085d0.width == UIView:0x1545903e0.width>",
"<NSLayoutConstraint:0x154709850 UILabel:0x154708770'\U5386\U53f2\U9009\U62e9'.leading == CFCityPickerVC.CFCPContentView:0x154708d60.leading>",
"<NSLayoutConstraint:0x1547098a0 H:|-(18)-[UILabel:0x154708770'\U5386\U53f2\U9009\U62e9']   (Names: '|':CFCityPickerVC.HeaderItemView:0x1547085d0 )>",
"<NSLayoutConstraint:0x154709940 H:[CFCityPickerVC.CFCPContentView:0x154708d60]-(30)-|   (Names: '|':CFCityPickerVC.HeaderItemView:0x1547085d0 )>",
"<NSLayoutConstraint:0x1545b3890 'UIView-Encapsulated-Layout-Width' H:[UIView:0x1545903e0(0)]>"
)
Will attempt to recover by breaking constraint
<NSLayoutConstraint:0x154709850 UILabel:0x154708770'历史选择'.leading == CFCityPickerVC.CFCPContentView:0x154708d60.leading>
Make a symbolic breakpoint at UIViewAlertForUnsatisfiableConstraints to catch this in the debugger.
The methods in the UIConstraintBasedLayoutDebugging category on UIView listed in <UIKit/UIView.h> may also be helpful.
2016-05-04 15:24:31.540 CFCityPickerVC[17697:4651979] Unable to simultaneously satisfy constraints.
Probably at least one of the constraints in the following list is one you don't want.
Try this:
(1) look at each constraint and try to figure out which you don't expect;
(2) find the code that added the unwanted constraint or constraints and fix it.
(
"<NSLayoutConstraint:0x15462a040 H:|-(18)-[CFCityPickerVC.CitySearchBar:0x1545906c0]   (Names: '|':UIView:0x1545903e0 )>",
"<NSLayoutConstraint:0x154629ac0 H:[CFCityPickerVC.CitySearchBar:0x1545906c0]-(20)-|   (Names: '|':UIView:0x1545903e0 )>",
"<NSLayoutConstraint:0x1545b3890 'UIView-Encapsulated-Layout-Width' H:[UIView:0x1545903e0(0)]>"
)
Will attempt to recover by breaking constraint
<NSLayoutConstraint:0x154629ac0 H:[CFCityPickerVC.CitySearchBar:0x1545906c0]-(20)-|   (Names: '|':UIView:0x1545903e0 )>
Make a symbolic breakpoint at UIViewAlertForUnsatisfiableConstraints to catch this in the debugger.
The methods in the UIConstraintBasedLayoutDebugging category on UIView listed in <UIKit/UIView.h> may also be helpful.
2016-05-04 15:24:31.545 CFCityPickerVC[17697:4651979] Unable to simultaneously satisfy constraints.
Probably at least one of the constraints in the following list is one you don't want.
Try this:
(1) look at each constraint and try to figure out which you don't expect;
(2) find the code that added the unwanted constraint or constraints and fix it.
(Note: If you're seeing NSAutoresizingMaskLayoutConstraints that you don't understand, refer to the documentation for the UIView property translatesAutoresizingMaskIntoConstraints)
(
"<NSAutoresizingMaskLayoutConstraint:0x15471fa60 h=-&- v=-&- CFCityPickerVC.HeaderItemView:0x154704520.width == UIView:0x1545903e0.width>",
"<NSLayoutConstraint:0x15470a380 H:|-(18)-[UILabel:0x1547080e0'\U70ed\U95e8\U57ce\U5e02']   (Names: '|':CFCityPickerVC.HeaderItemView:0x154704520 )>",
"<NSLayoutConstraint:0x15470a510 H:[UIView:0x154703d40]-(0)-|   (Names: '|':CFCityPickerVC.HeaderItemView:0x154704520 )>",
"<NSLayoutConstraint:0x15470a560 H:[UILabel:0x1547080e0'\U70ed\U95e8\U57ce\U5e02']-(6)-[UIView:0x154703d40]>",
"<NSLayoutConstraint:0x1545b3890 'UIView-Encapsulated-Layout-Width' H:[UIView:0x1545903e0(0)]>"
)
Will attempt to recover by breaking constraint
<NSLayoutConstraint:0x15470a560 H:[UILabel:0x1547080e0'热门城市']-(6)-[UIView:0x154703d40]>
Make a symbolic breakpoint at UIViewAlertForUnsatisfiableConstraints to catch this in the debugger.
The methods in the UIConstraintBasedLayoutDebugging category on UIView listed in <UIKit/UIView.h> may also be helpful.
2016-05-04 15:24:31.546 CFCityPickerVC[17697:4651979] Unable to simultaneously satisfy constraints.
Probably at least one of the constraints in the following list is one you don't want.
Try this:
(1) look at each constraint and try to figure out which you don't expect;
(2) find the code that added the unwanted constraint or constraints and fix it.
(Note: If you're seeing NSAutoresizingMaskLayoutConstraints that you don't understand, refer to the documentation for the UIView property translatesAutoresizingMaskIntoConstraints)
(
"<NSAutoresizingMaskLayoutConstraint:0x1545b1900 h=-&- v=-&- CFCityPickerVC.HeaderItemView:0x1547085d0.width == UIView:0x1545903e0.width>",
"<NSLayoutConstraint:0x1547098a0 H:|-(18)-[UILabel:0x154708770'\U5386\U53f2\U9009\U62e9']   (Names: '|':CFCityPickerVC.HeaderItemView:0x1547085d0 )>",
"<NSLayoutConstraint:0x154709a30 H:[UIView:0x154708ab0]-(0)-|   (Names: '|':CFCityPickerVC.HeaderItemView:0x1547085d0 )>",
"<NSLayoutConstraint:0x154709a80 H:[UILabel:0x154708770'\U5386\U53f2\U9009\U62e9']-(6)-[UIView:0x154708ab0]>",
"<NSLayoutConstraint:0x1545b3890 'UIView-Encapsulated-Layout-Width' H:[UIView:0x1545903e0(0)]>"
)
Will attempt to recover by breaking constraint
<NSLayoutConstraint:0x154709a80 H:[UILabel:0x154708770'历史选择']-(6)-[UIView:0x154708ab0]>
Make a symbolic breakpoint at UIViewAlertForUnsatisfiableConstraints to catch this in the debugger.
The methods in the UIConstraintBasedLayoutDebugging category on UIView listed in <UIKit/UIView.h> may also be helpful.
2016-05-04 15:24:31.548 CFCityPickerVC[17697:4651979] Unable to simultaneously satisfy constraints.
Probably at least one of the constraints in the following list is one you don't want.
Try this:
(1) look at each constraint and try to figure out which you don't expect;
(2) find the code that added the unwanted constraint or constraints and fix it.
(Note: If you're seeing NSAutoresizingMaskLayoutConstraints that you don't understand, refer to the documentation for the UIView property translatesAutoresizingMaskIntoConstraints)
(
"<NSAutoresizingMaskLayoutConstraint:0x1545ade40 h=-&- v=-&- CFCityPickerVC.HeaderItemView:0x1545985a0.width == UIView:0x1545903e0.width>",
"<NSLayoutConstraint:0x154642d40 H:|-(18)-[UILabel:0x1547078e0'\U5f53\U524d\U57ce\U5e02']   (Names: '|':CFCityPickerVC.HeaderItemView:0x1545985a0 )>",
"<NSLayoutConstraint:0x1546375c0 H:[UIView:0x154598980]-(0)-|   (Names: '|':CFCityPickerVC.HeaderItemView:0x1545985a0 )>",
"<NSLayoutConstraint:0x154704e80 H:[UILabel:0x1547078e0'\U5f53\U524d\U57ce\U5e02']-(6)-[UIView:0x154598980]>",
"<NSLayoutConstraint:0x1545b3890 'UIView-Encapsulated-Layout-Width' H:[UIView:0x1545903e0(0)]>"
)
Will attempt to recover by breaking constraint
<NSLayoutConstraint:0x154704e80 H:[UILabel:0x1547078e0'当前城市']-(6)-[UIView:0x154598980]>
Make a symbolic breakpoint at UIViewAlertForUnsatisfiableConstraints to catch this in the debugger.
The methods in the UIConstraintBasedLayoutDebugging category on UIView listed in <UIKit/UIView.h> may also be helpful.

Autolayout约束冲突了吧


Required properties

Codecov Report

Merging #608 into metadata-editor will not change coverage.
The diff coverage is 100%.

@@               Coverage Diff                @@
##           metadata-editor     #608   +/-   ##
================================================
  Coverage            50.15%   50.15%
================================================
  Files                  257      257
  Lines                 6863     6863
================================================
  Hits                  3442     3442
  Misses                3421     3421

Impacted Files
Coverage Δ

src/article/metadata/MultiSelectInput.js
44.11% <ø> (ø)
:arrow_up:

src/article/metadata/EntityDatabase.js
86.11% <ø> (ø)
:arrow_up:

src/article/metadata/EntityLabelsPackage.js
100% <100%> (ø)
:arrow_up:

Continue to review full report at Codecov.

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


Improve chat/play history display to include icons

User face icons for chat messages, album art icons for play history messages.

Also, would be nice to add an update message in chat when the theme changes.

Resolved via #64


Pass custom site

@weotch This is a change I would like to have... let me explain:
Sendbird has the unique case of 1 site with multiple langs. I need to sync to multiple indicies from one site. In a normal project, each lang is set by the CMS_SITE env var in a dedicated netlify site, but not here for sendbird.
My change is allowing you to pass the site variable from cloak config, so IF it exists, it will use that, and then, in my config, it looks something like this:
algolia: {
	sync: [
		{
			name: 'blog',
			indexName: 'prod_en_US_blog',
			fragmentPath: 'queries/fragments/blog.gql',
			section: 'blogs',
			type: 'blog',
			site: 'en_US'
		},
		{
			name: 'blog',
			indexName: 'prod_ko_KR_blog',
			fragmentPath: 'queries/fragments/blog.gql',
			section: 'blogs',
			type: 'blog',
			site: 'ko_KR'
		}
	]
}

Mayne an opportunity to dry that up, but I've tested this with the proposed change, and it synced the correct site entries to the correct index

This is somewhat urgent, as they're trying to get these features live by mid next week. I can explain more about why I need this if you would like.

On suggestion, in your example there, I would change it to be like:
algolia: {
	sync: [
		{
			name: 'blog',
			indexName: `${process.env.APP_ENV || "dev"}_en-US_blog`,
			fragmentPath: 'queries/fragments/blog.gql',
			section: 'blogs',
			type: 'blog',
			site: 'en_US'
		},
		{
			name: 'blog',
			indexName: `${process.env.APP_ENV || "dev"}_ko-KR_blog`,
			fragmentPath: 'queries/fragments/blog.gql',
			section: 'blogs',
			type: 'blog',
			site: 'ko_KR'
		}
	]
}

So you get unique indexes for prod and dev environments.  So you don't accidentally write to the prod Algolia index when working locally, for example.

thanks 👍


OctopOS Prime Team Designs-13

Please add your team designs that you have designed.

Cybersecurity expert octopus


Random material index bug

Fix #231
I sorted result_primitives in extract_primitives before return it

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.Tanguy seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.

Any news about this issue?

@TanguyBr This issue has been fixed in the new importer/exporter, https://github.com/KhronosGroup/glTF-Blender-IO/. I'm still open to merging this PR, if you can sign the CLA, but note that eventually this repository is going to be archived. I would recommend moving to the new version when you can; it is enabled by default in  Blender 2.8.

Closing for now, see comment above. Sorry for the slow reply on this!


Installation: FMILibrary link unavailable

Since jModelica website is down, the FMILibrary link is unavailable for download. I don't know how long it has been down for, but an alternative source is:
https://svn.jmodelica.org/FMILibrary/tags/2.0.2b3/
This is for the specified release in the installation instructions. Download with SVN.

Pull request #2

Hi
i cant open ur pendel.mo. Can you update this model? Im doing a building model. But i dont know how to create inputs and outputs for the FMU. I struggle with this problem. My Buildingmodel doesnt show any parameters if i call it in python.
Can u help me?
Thanks


usm: Enable event monitor if USM needs it

What does this PR do?
If all options other than USM which need the event stream (including network_process.enabled) are explicitly disabled, the event monitor module is not enabled even if USM needs it.  Add the USM event stream configuration as a condition for enabling the event monitor module.
Motivation
Reported as found during manual experimentation during investigation of an incident.
Describe how to test/QA your changes
Automated tests have been updated.
Possible Drawbacks / Trade-offs
Additional Notes

/merge


Luigi Authentication Events

Implemented and created documentation for authentication events:
auth: {
  events: {
    onAuthSuccessful: (settings, authData) => {},
    onAuthError: (settings, err) => {}
    onAuthExpired: (settings) => {},
    onLogout: (settings) => {}
  }
}

Refactored Luigi Core API out to single classes.

onAuthError is not working anymore due to some changes that got merged in. small refactoring upcoming.


Fix incorrect example in assemblies

Fixes #317

I'll make the appropriate PR in optimade-python-tools to get this example fixed in our models, and thus our OpenAPI schema, and thus the OpenAPI schema in this repo...

This must be a leftover from the olden times. It would be great to clean it up from OpenAPI schema.


Update DG to RDKit_minimal_2022.03_1

update DG to RDKit_minimal_2022.03_1
add support for chemical reaction drawing
add support for additional FPs

@ptosco thank you for the update!

Awesome, thank you Paolo!

@ptosco, we've figured out that the alignment through:
mol.normalize_2d_molblock();
mol.straighten_2d_layout();

worked in RDKit_minimal_2021.03_18.wasm, but no longer works in RDKit_minimal_2022.03_1.wasm with:
mol!.normalize_depiction();
mol!.straighten_depiction();

What could be the reason, could you please check?

@dskatov This should be fixed by #562.


DOC: Adding docs contribution guidelines

Reference issue
Fixes #16603
What does this implement/fix?
Expands on the existing guidelines, moving them to a separate doc. Heavily inspired by the NumPy documentation guidelines.

This looks like a good place to explain that docs-only PRs only should get built on CircleCI, and to achieve that the commit message should contain [skip actions][skip azp].


Implement SpinnerPromise

Connects to #39
@jviotti I've left 'stopMessage' being optional intentionally, since the internal Spinner used does not require stop messages as well

The tests are failing due to NodeJS 0.10 not having native promises support. I'm happy with either of the following alternatives:

Drop NodeJS 0.10 from Travis CI and Appveyor CI.
Use Bluebird in the tests.
Add a Promise shim in the tests.

0.10 is ancient nobody should use it anymore :)
On Fri, Oct 14, 2016 at 00:54 Juan Cruz Viotti
<
mailto:Juan Cruz Viotti<EMAIL_ADDRESS>
wrote:

a, pre, code, a:link, body { word-wrap: break-word !important; }
The tests are failing due to NodeJS 0.10 not having native promises support. I'm happy with either of the following alternatives:
Drop NodeJS 0.10 from Travis CI and Appveyor CI.
Use Bluebird in the tests.
Add a
Promise
shim in the tests.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly,
https://github.com/resin-io/resin-cli-visuals/pull/40#issuecomment-253650117
, or
https://github.com/notifications/unsubscribe-auth/AAgGCGxlUpKamrDb9Tjv4sfRh5rE4WTwks5qzqiMgaJpZM4KWFq2
.

Thank you @jviotti @emirotin @Page- , dropped support for node < 0.11 (also added an engines entry in package.json)

I've published this change to npm as part of v1.3.0.


Page reload need just like the module 'react-router/lib/RefreshLocation'

For some reason, I would need the SPA page which was based on<EMAIL_ADDRESS>use HTML5 history API on development, but use page reload on production.
const location = process.env.NODE_ENV === 'production'
  ? RefreshLocation
  : HashLocation;

But I saw<EMAIL_ADDRESS>use 'history/lib/createBrowserHistory', so I assume the code could like that
let isSupported = !options.forceReload || supportsHistory();

https://github.com/rackt/history/blob/master/modules/createBrowserHistory.js#L24
Thanks!

When you use browser history you automatically get full page refreshes in browsers that do not support HTML5 history. Are you saying you want to always force full page refreshes, even if the browser supports HTML5 history?

Yes, I just need this feature.

Why are you using this library at all? Why don't you just use full page refreshes everywhere?

Because the previous project work with<EMAIL_ADDRESS>I want to find a way to upgrade it. But the RefreshLocation is no more exist in  the<EMAIL_ADDRESS>so I was confused on how to solve this problem.

We're not going to support always using full page refreshes. Instead of focusing on refresh behavior, I think it makes sense to focus on URLs. If you want clean URLs, use browser history and full page refreshes will happen automatically in browsers that don't support HTML5 history.

Seems like other people need this as well. Let's follow up in https://github.com/rackt/history/issues/95


Are There Any Character Restrictions For Valid Event Names?

I'm wondering if you can use any characters in an Event Name including special characters and other alphabets? Also are there length limits or just that of a standard string?

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

ID: 401d2997-0fbd-7966-8996-edbaab1819ff
Version Independent ID: c3ee3318-4c69-8ded-a8d5-5059d699351b
Content: Application Insights API for custom events and metrics
Content Source: articles/azure-monitor/app/api-custom-events-metrics.md
Service: application-insights
GitHub Login: @mrbullwinkle
Microsoft Alias: mbullwin

@mastjaso Thank you for the feedback!  We are investigating this and will get back to you shortly.

@m-sterspace It appears that you can use UTF-8 (tested with English, Japanese, Chinese, and Hindi) and several special characters (see below) up to at least 100 characters (hopefully you aren't planning on using more than that).
The recommendation is to keep it simple as there may be unforeseen consequences to using longer names with special characters, however you can see below that tracking will work.

@m-sterspace We are going to close this thread as resolved but if there are any further questions regarding the documentation, please tag me in your reply and we will be happy to continue the conversation.


No beacon ranged when used on IntentService

Hi. On Android 7.1, I'm able to start scanning and ranging beacon using the latest SDK in an Activity. However, when the same monitor and range codes are moved to an IntentService, the scan seems to be started but no beacon is ranged.
Here is the device I tested this on: Nexus 6p, Android 7.1.1.
The setup is very basic:
`EstimoteSDK.initialize(this, appId, appToken);
EstimoteSDK.enableDebugLogging(true);
    final BeaconManager beaconManager = new BeaconManager(this);

    final Region region = new Region(appId, UUID.fromString(uuid), null, null);

    beaconManager.setMonitoringListener(new MonitoringListener() {
        @Override
        public void onEnteredRegion(Region region, List<Beacon> list) {
            Log.e("TEST", "Region entered: " + region.getProximityUUID());
            beaconManager.startRanging(region);
        }

        @Override
        public void onExitedRegion(Region region) {
            Log.e("TEST", "Region exited: " + region.getProximityUUID());
        }
    });

    beaconManager.setRangingListener(new RangingListener() {
        @Override
        public void onBeaconsDiscovered(Region region, List<Beacon> list) {
            Log.e("TEST", "Beacons discovered: " + list.toString());
        }
    });

    beaconManager.connect(new ServiceReadyCallback() {
        @Override
        public void onServiceReady() {
            Log.e("TEST", "Service is ready");

            beaconManager.startMonitoring(region);
        }
    });`

Here are the logs when using on IntentService:
02-16 10:54:40.305 18165-18197/com.example.locnguyen.myapplication D/EstimoteSDK: com.estimote.sdk.service.internal.bluetooth.LollipopBluetoothAdapter.start:248 STARTED SCAN 02-16 10:54:50.325 18165-18165/com.example.locnguyen.myapplication D/EstimoteSDK: com.estimote.sdk.service.internal.bluetooth.NougatScanScheduler.onAlarmTick:166 Scheduler received alarm tick. Type = SYSTEM_ALARM 02-16 10:54:50.327 18165-18197/com.example.locnguyen.myapplication W/EstimoteSDK: com.estimote.sdk.service.internal.bluetooth.NougatScanScheduler$1.run:190 Scheduler stopping scan 02-16 10:54:50.339 18165-18197/com.example.locnguyen.myapplication D/BluetoothAdapter: STATE_ON 02-16 10:54:50.347 18165-18197/com.example.locnguyen.myapplication D/EstimoteSDK: com.estimote.sdk.service.internal.bluetooth.LollipopBluetoothAdapter.stop:278 STOPPED SCAN
Update: I tried the same code on a Google Pixel XL running Android 7.1 and neither Activity nor IntentService are able to range any beacon.

Same issue facing. Ranging list size comes  0, though there are 3 beacons present around device.

Hello guys,
Sorry for the delay - we are working hard to improve our scanning stack. Soon there will be a new release with many updates, stay tuned :)

Hi, the 1.0.0 update solves the issue but not completely. I have tried it on a number of Android 7.0+ devices and some seem to work fine, the Google Pixel, however, still will not range.

Hey @loc02998375
We are investigating the problem on Pixel phones, will post any info soon :)
Stay tuned!

I encourage you to try our new ProximitySDK 🚀 - it is dedicated for creating proximity interactions with our beacons - its main focus is to deliver the reliable enter/exit experience according to a different zones of beacons, based on our own data-science, and Estimote Monitoring packet.
It works extremely well with Android 5.0-8.0 devices (full support for Nougat, and Oreo included), and also allows you to configure it to keep scanning in the background.
Here is the official repository page ->  https://github.com/Estimote/Android-Proximity-SDK
Also, we keep posting updates about the progress of our development on this thread at our forums.
I encourage you to track it in order to be super up-to-date :)
Please, check the mentioned new SDK - the current SDK will soon be deprecated, and we will support only critical issues for some time.


Can't launch server appimage on linux, blank screen

When trying to launch appimage on linux, i see this in terminal:
[plyshka@arch vr]$ ./SlimeVR-amd64.appimage
 INFO  slimevr > Server found on path: /tmp/.mount_SlimeVguNJa8
 INFO  slimevr > Using Java binary: "java"
GStreamer element appsink not found. Please install it
GStreamer element autoaudiosink not found. Please install it

(WebKitWebProcess:25888): GLib-GObject-WARNING **: 21:50:25.084: invalid (NULL) pointer instance

(WebKitWebProcess:25888): GLib-GObject-CRITICAL **: 21:50:25.084: g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed

And completely blank (white) window of the slimevr
Previously i could launch 0.6.3 server just fine using appimage

still having problem on flatpak


Long press Windows key incomplete

ℹ Computer information

PowerToys version: 0.25.0
PowerToy Utility: Windows key shortcut guide
Running PowerToys as Admin: Yes
Windows build number: 19042 630

📝 Provide detailed reproduction steps (if any)

Long press WIndows key
You see on screen the functions of Windows key + characters

✔ Expected result
Show all characters that have a function combined with Windows key.
_What is the expected result of the above steps?
To also show what the outcome is of:
Win+B (selecting system tray)
Win+C (open Cortana)
Win+F (open Feedback)
Win+P (open Projecting > not sure if this is the right word in English)
Win+T (select Taskbar)
Win+V (multi paste)
Win+W (open whiteboard)
❌ Actual result
Now long pressing Windows key shows only combinations with A, D, E, G, H, I, K, L, M, R, S, U, X, 1, 2, 3, ...
What is the actual result of the above steps?
A more complete and helpful Windows key utility.
📷 Screenshots

I have my Taskbar at the right side of the screen...

Are there any useful screenshots? WinKey+Shift+S and then just paste them directly into the form

already tracked in #179

Duplicate of #179


when upgrade run very slow

WARNING: All log messages before absl::InitializeLog() is called are written to STDERR
I0000 00:00:1733145796.943476 3221728 gl_context_egl.cc:85] Successfully initialized EGL. Major : 1 Minor: 5
I0000 00:00:1733145797.046580 3222583 gl_context.cc:357] GL version: 3.2 (OpenGL ES 3.2 NVIDIA 555.42.02), renderer: NVIDIA GeForce RTX 4090/PCIe/SSE2
INFO: Created TensorFlow Lite XNNPACK delegate for CPU.
W0000 00:00:1733145797.067682 3222584 inference_feedback_manager.cc:114] Feedback manager requires a model with a single signature inference. Disabling support for feedback tensors.

use VIMatte(local) fix


feat: Send email with screenshot attachment

Description
I have this working on my local branch. Let me know if it's useful enough for the community to use. Helps me out with false/positives.

Possible solution

Yeah! Why not.

Already implemented.


Download Only CSS of One Component?

As it stands if you use the CSS file it changes the styles of multiple items such as header tags that could have already been declared in your own personal CSS file.

Duplicate of #1037 it looks like.


Fix_single_qubit_multiplication

Codecov Report

Merging #144 (f64f057) into main (995547a) will increase coverage by 1.65%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main     #144      +/-   ##
==========================================
+ Coverage   91.23%   92.88%   +1.65%
==========================================
  Files          33       17      -16
  Lines        4996     3178    -1818
==========================================
- Hits         4558     2952    -1606
+ Misses        438      226     -212

Flag
Coverage Δ

unittests
92.88% <100.00%> (+1.65%)
:arrow_up:

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

Impacted Files
Coverage Δ

...oqo/src/operations/single_qubit_gate_operations.rs
97.06% <100.00%> (ø)

qoqo/src/operations/two_qubit_gate_operations.rs

qoqo/src/operations/pragma_operations.rs

qoqo/src/operations/measurement_operations.rs

qoqo/src/measurements/cheated_measurement.rs

qoqo/src/circuit.rs

...src/measurements/classical_register_measurement.rs

qoqo/src/operations/define_operations.rs

qoqo/src/measurements/mod.rs

...c/measurements/measurement_auxiliary_data_input.rs

... and 7 more

Continue to review full report at Codecov.

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


fix: avoid escaping bind-like params containing colons

SUMMARY
A recent PR #17111 that fixed 500s being returned when a virtual table query contained a word prefixed by a colon (e.g. ":foo") caused a regression that unnecessarily also escaped similar strings that contained/ended in a colon (e.g. ":foo:" or ":foo:bar").
This PR simplifies the escaping logic by simply escaping all colons with a backslash when sa.text is used, as these elements are never expected to contain binds. In addition, an integration test is added that contains colons in the virtual table query, metric, filter and where clauses. The new test fails on current master with a 500.
AFTER
Now all strings including colons are displayed properly on the query:

BEFORE
Before the virtual table was incorrectly escaped in multiple places:

TESTING INSTRUCTIONS

ADDITIONAL INFORMATION

[ ] Has associated issue:
[ ] Required feature flags:
[ ] Changes UI
[ ] Includes DB Migration (follow approval process in SIP-59)

[ ] Migration is atomic, supports rollback & is backwards-compatible
[ ] Confirm DB migration upgrade and downgrade tested
[ ] Runtime estimates and downtime expectations provided

[ ] Introduces new feature or API
[ ] Removes existing feature or API

Thanks for the review @john-bodley, good comments to my oversights!

LGTM, with one non-blocking comment. Its somewhat strange that we need to handle this logic, i.e., blindly I would have assumed that SQLAlchemy would deal with the escaping.

AFAIK, currently there is no way of indicating that the clause is literal (like literal_column, for instance). Hence colons need to be escaped to indicate to SQLAlchemy that they should not be made available as bind parameters during compilation. But I'm going to propose adding is_literal to the text() factory, and then adding a literal_text factory as shorthand to match (literal_column), as I've seen multiple other people ask for the same thing elsewhere (in all the posts I've found, the author of SQLAlchemy always recommends just escaping the bind-like parameters).


Task 55

Related Issues

#issue-number

Proposed Changes:

Testing:

Extra Notes (optional):

Checklist

[ ] Related issues and proposed changes are filled
[ ] Tests are defining the correct and expected behavior
[ ] Code is well-documented via docstrings

Superseded by #62


Rename subcube to plane

Changed all occurences of subcube to plane, to match the new nomenclature.

LGTM


Facts should allow for wildcards

For large systems containing many facts sharing a common base name, it would be useful to have wildcards to check for multiple facts

I can only think of 2 main ways of handling this, each with pros and cons:

The compiler could be used to 'expand' the wildcards into the complete set of individual rules prior to writing the bytecode.  This could result in an extremely large set of expanded rules depending on the number of wildcards used in the 'base' rule.  Additionally, the compiler needs to know the complete list of all possible facts prior to compilation.
The system could introduce a new prefix tree, hash table, or other data structure to quickly match the wildcards patterns.  This would obviously increase the complexity of the implementation, and I'm uncertain as to what the impact on performance would/could be.

Sounds like the BBQ helped!  Just a few additional thoughts -

To ensure wildcards are used responsibly, it might be useful to generate additional logging information for the user, so they can see how many wildcard matches are being used.  This could be the number of wildcard matches and/or time needed to create the map (probably very fast).  That way, the user can identify excess checks and introduce more structures to the keys for more targeted wildcard usage (e.g., weather:somecity:temperature)

Can this support both single character wildcards (?) and multi character wildcards (*)?

Should this support wildcards in targets?

The short-circuiting for ANY and ALL conditions should apply to getting and checking the value (i.e., minimize number of MGet)

Thanks!

Yes.  I can associate it with a level of logging for the sake of reporting back to the user.  Perhaps it could also be tied in with Prometheus.
Sure.   Wait until I get an implementation of the * wildcard working BEFORE asking about the single character wildcards.   Scope creep!
I thought about it, but didn't implement it that way (yet).   It could definitely be misused and I really can't think of a great use case for it.
I really think it's more efficient to simply make the single request for all of the facts needed for an evaluation rather than splitting up the requests on a condition by condition basis.   Or am I misunderstanding?

I agree to all of your points.
For #4, I was referring to short-circuiting the MGet and checking the value as needed.  That way, if there are an inordinate amount of wildcard results, you don't need to call MGet for all of them.  You would still need to Scan for all the keys to get the sub-set of facts prior to this.


Support HTTP/2 for TLS servers.

This PR adds support for HTTP/2 servers when it is started in https mode.
It follows the same behavior as the Go net/http server. Start the graceful server using the following automatically enables http/2: ListenAndServeTLS(), server.ListenAndServeTLS(), server.ListenAndServeTLSConfig().
If the user wants to create his own listener and pass that in to server.Serve(), he will need to set server.TLSConfig to enable http/2. This is consistent with http.Server's behavior.
Go 1.6+ is required for http/2 support.
Closes #66.

Coverage increased (+14.2%) to 71.041% when pulling 389bfcef56c764f26c097db824392e72f7a56e49 on F21:http2 into bffe07886e519361228b315595ca8041f0733ce3 on tylerb:master.

Coverage increased (+14.2%) to 71.041% when pulling d52ea52bc18121880af6db19cd9001a4839fa59c on F21:http2 into bffe07886e519361228b315595ca8041f0733ce3 on tylerb:master.

It looks like request.Cancel was introduced in Go 1.5 and is required by the golang/x/net/http2 package.
The reason why this package was included was because I needed to use http2.ConfigureTransport to enable HTTP/2 for the client during test as I needed to allow insecure (self-signed) certificates. See https://github.com/golang/go/blob/605e751b53a8bec7d1f51b2ccc0093e063358dc6/src/net/http/transport.go#L200
Here are some solutions:

Remove the tests. I don't think this is a good idea as getting it to serve http/2 is somewhat tricky as the net/http uses a bit too much magic (imo) to upgrade to http/2. The tests prevents http/2 from being broken in the future.

Allow test failures for Go 1.3 and 1.4: Might reduce visibility of test failures, but is it something we can cope with?

Remove support for Go 1.3 and 1.4: 1.3 last had a release in late 2014. I believe the 1.4 released late last year is probably the last release for the 1.4 series. Are people still using these old releases? If not, maybe we can drop support for these 2 releases.

to fix the dependency problem i think you can put it in a new test file with a build tag for // +build go1.5
see https://golang.org/pkg/go/build/
i am not sure if that works but it is worth a try.

@mb0, hmm, that didn't work. :disappointed:

Coverage increased (+14.2%) to 71.041% when pulling 17943c97c6195dbe59fe473c388e83f4b4f5a404 on F21:http2 into bffe07886e519361228b315595ca8041f0733ce3 on tylerb:master.

Coverage increased (+14.2%) to 71.041% when pulling e5d8a1d0cd628b163340229d1996613b72c013ef on F21:http2 into bffe07886e519361228b315595ca8041f0733ce3 on tylerb:master.

Coverage increased (+14.2%) to 71.041% when pulling b1b9867204e0a527af9f5e9e6075ca92ff252505 on F21:http2 into bffe07886e519361228b315595ca8041f0733ce3 on tylerb:master.

Coverage increased (+14.2%) to 71.041% when pulling<PHONE_NUMBER>d0ef9bbbba297dc59ac559d2a1e930 on F21:http2 into bffe07886e519361228b315595ca8041f0733ce3 on tylerb:master.

Coverage increased (+14.2%) to 71.041% when pulling<PHONE_NUMBER>d0ef9bbbba297dc59ac559d2a1e930 on F21:http2 into bffe07886e519361228b315595ca8041f0733ce3 on tylerb:master.

@mb0 I neglected a blank line between the build directive and the code. It works perfectly now! :smile:

Coverage increased (+14.2%) to 71.041% when pulling 29229906ea40d9b763d1f6b576ba8dcae2c80b24 on F21:http2 into bffe07886e519361228b315595ca8041f0733ce3 on tylerb:master.

Thanks for your work on this, @F21 and @mb0. Sorry I've not been more responsive.
LGTM


NPM script runs with yarn instead of npm.

Does this issue occur when all extensions are disabled?: Yes/No

VS Code Version:  Version: 1.77.3 (Universal)
OS Version: macOS Monterey version 12.6.5

Steps to Reproduce:
Running NPM script from sidebar or running a task build uses yarn instead of npm, when project is opened from sub folders.
VSCode error:

Executing task: yarn run build:watch

zsh:1: command not found: yarn

The terminal process "/bin/zsh '-c', 'yarn run build:watch'" failed to launch (exit code: 127).
Terminal will be reused by tasks, press any key to close it.

This is my folder structure.
Root ==> If this is opened, uses npm.

node_modules
packages ==> If this is opened, uses yarn.

package1 ==> If this is opened, uses yarn.
package2 ==> If this is opened, uses yarn.
package3 ==> If this is opened, uses yarn.

If I open the root folder then NPM script runs with npm command. ==> OK
If I open packages folder or one of individual package folder then NPM script runs with yarn command. ==> FAIL

You can set this with npm.packageManager


[FEATURE]  Calculate the median spacing and size of the training data

Is your feature request related to a problem? Please describe.
It will be useful to calculate the median spacing and size of the training data
Describe the solution you'd like
N.A
Describe alternatives you've considered
N.A
Additional context
N.A

In addition to median spacing, other cohort-level stats can be calculated and saved.

@sarthakpati
I find this. Could you please check if it is useful for us?

Yup, this can be a good starting point.


Improves 'make help' documentation

Description

Adds some docs to the Makefile for the make help command. It could be improved by documenting the args each command takes, but this is a start.
How Has This Been Tested?

run make help and behold.
Merge criteria:

All the commits have been signed-off  (To pass the DCO check)

[x] The commits have meaningful messages; the author will squash them after approval or in case of manual merges will ask to merge with squash.
[x] Testing instructions have been added in the PR body (for PRs involving changes that are not immediately obvious).
[x] The developer has manually tested the changes and verified that the changes work.
[x] Code changes follow the kubeflow contribution guidelines.

If you have UI changes

[ ] The developer has added tests or explained why testing cannot be added.
[ ] Included any necessary screenshots or gifs if it was a UI change.
[ ] Verify that UI/UX changes conform the UX guidelines for Kubeflow.

/lgtm


Ensure all URLs in markdown pages have trailing slashes at the end

Description

Related Issue(s)

Checklist

[ ] I have read the contribution guidelines
[ ] I have considered the performance impact of these changes
[ ] Suitable unit/system level tests have been added and they pass
[ ] Documentation has been updated

Testing locally, this seems to work very well - great work Sumit

Thanks @joepavitt for the guidance provided while working on it.