Viva Engage License requirements for Champains

Can you please specify whiceViva Engage license sku is needed for users to be able to see, post to, and hashtag reference Viva Engage Campaigns?

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

ID: 4fb9d2aa-e703-ca77-fd4e-9303b38dedb4
Version Independent ID: 4fb9d2aa-e703-ca77-fd4e-9303b38dedb4
Content: Manage and set up campaigns in Microsoft Viva Engage
Content Source: Viva/engage/campaigns.md
Service: viva
Sub-service: viva-engage
GitHub Login: @mamiepjohnson
Microsoft Alias: mamiejohnson

Hi! Thanks for this message – to provide a bit more context, the SKU details for premium features are covered in the Key admin roles and permissions in Viva Engagehttps://learn.microsoft.com/en-us/viva/engage/eac-key-admin-roles-permissions article and the Set up the Engage admin centerhttps://learn.microsoft.com/en-us/viva/engage/eac-get-started
Article on the admin side. Additionally, in our end user documentation for campaignshttps://support.microsoft.com/en-us/topic/campaigns-in-viva-engage-d7b05128-f80b-4c16-b561-3ddce518eb14, we made sure to mention which license is required to participate in campaigns!
Thus, I don’t believe there’s a need to reiterate this information since it already is detailed throughout both our admin and end user documentation. Hope this helps add context!
Best,
Mamie
From: Jvasil @.>
Date: Tuesday, March 7, 2023 at 6:05 AM
To: MicrosoftDocs/Viva @.>
Cc: Mamie Johnson @.>, Mention @.>
Subject: [MicrosoftDocs/Viva] Viva Engage License requirements for Champains (Issue #547)
Can you please specify whiceViva Engage license sku is needed for users to be able to see, post to, and hashtag reference Viva Engage Campaigns?

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

ID: 4fb9d2aa-e703-ca77-fd4e-9303b38dedb4
Version Independent ID: 4fb9d2aa-e703-ca77-fd4e-9303b38dedb4
Content: Manage and set up campaigns in Microsoft Viva Engagehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flearn.microsoft.com%2Fen-us%2Fviva%2Fengage%2Fcampaigns&data=05|01|mamiejohnson%40microsoft.com|5034e93fb56d46e5b8ee08db1f14f655|72f988bf86f141af91ab2d7cd011db47|1|0|638137947120029148|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000|||&sdata=F9zPr3v7I1vbe9UGLIv8V2BKR2ESsrxQaYbEwI02KA8%3D&reserved=0
Content Source: Viva/engage/campaigns.mdhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoftDocs%2FOfficeDocs-WorkplaceAnalytics%2Fblob%2Fpublic%2FViva%2Fengage%2Fcampaigns.md&data=05|01|mamiejohnson%40microsoft.com|5034e93fb56d46e5b8ee08db1f14f655|72f988bf86f141af91ab2d7cd011db47|1|0|638137947120029148|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000|||&sdata=E1QZj%2BdMz3JNku2wcMEauh5pumQvefsZR%2F%2B9ihxVHiE%3D&reserved=0
Service: viva
Sub-service: viva-engage
GitHub Login: @mamiepjohnsonhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmamiepjohnson&data=05|01|mamiejohnson%40microsoft.com|5034e93fb56d46e5b8ee08db1f14f655|72f988bf86f141af91ab2d7cd011db47|1|0|638137947120029148|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000|||&sdata=6gyxgyipRphqEUTfkWwOawQkpJ3WkvwpRTQEv%2B20UZc%3D&reserved=0
Microsoft Alias: mamiejohnson

—
Reply to this email directly, view it on GitHubhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoftDocs%2FViva%2Fissues%2F547&data=05|01|mamiejohnson%40microsoft.com|5034e93fb56d46e5b8ee08db1f14f655|72f988bf86f141af91ab2d7cd011db47|1|0|638137947120029148|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000|||&sdata=FX7jfb6ptsDiatqdNFTrcDvUF9NzEk1lDQ%2BIQwpz6Ws%3D&reserved=0, or unsubscribehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FA3ZQYDNSTFXARRADRXXWRW3W246BLANCNFSM6AAAAAAVSQQ4CQ&data=05|01|mamiejohnson%40microsoft.com|5034e93fb56d46e5b8ee08db1f14f655|72f988bf86f141af91ab2d7cd011db47|1|0|638137947120029148|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000|||&sdata=WH8%2BRGd4x2pwbvqZBgLX9G2IIt7ji%2BhYpLmra02UOqs%3D&reserved=0.
You are receiving this because you were mentioned.Message ID: @.***>

We appreciate any feedback that improves the content in the Microsoft docs but we haven't had any response from you so we are going to close this issue.
Please feel free to re-open this issue if there is a specific area of the docs that we can improve or make better. Thank you.


replaced dbt_modules with dbt_packages, except in the changelog

resolves #3523
Description

Very very naive find and replace of dbt_modules into dbt_packages.
I did the global find and replace on everything except the changelog

Checklist

[x] I have signed the CLA
[ ] I have run this code in development and it appears to resolve the stated issue
[ ] This PR includes tests, or tests are not required/relevant for this PR
[ ] I have updated the CHANGELOG.md and added information about my change to the "dbt next" section.

Wanted to PR the meat here before my calls for today but have not gone through all the hoops quite yet. I'll be back!

I'm going to close this, insofar as there are a few complexities outlined in https://github.com/dbt-labs/dbt/issues/3523#issuecomment-874772533 that we'll want to take into account to preserve as much backwards compatibility as possible.
In the meantime, I tagged that issue with 1.0.0. So, it's on our list of opportunistic, not-a-hard-requirement-but-would-be-cool issues that we're trying to hit ahead of releasing v1.0 later this year.


mlc_chat.rest does not support llama2?

Does it only support vicuna-v1-7b?

It does support Llama 2. The steps should be the same, except invoking the command with a different model input.

Closing, please open a new issue if you run into any issues with llama2!


Returning the length of a collection of string

Description
For questions where I have to use a stream of strings and find the length of the strings, why is it I have to use the combiner argument in order to return an integer?
Topic:
Specific Topics this question is related to (If Any)
Screenshots
Screenshots (if any)

There are three versions of reduce in Streams. You can see from this 2 parameter reduce() function that everything is type T.
reduce(T identity, BinaryOperator accumulator)
This means the accumulator can only handle type T and return type T. It can't be used because you in your question, you probably would be using a integer and string type. Therefore we need to use this instead
reduce(U identity, BiFunction<U,? super T,U> accumulator, BinaryOperator combiner)

Thank you!!


Define Hint behavior

Currently the hints on spyder display the full information of the function etc.
We need to define what teh behavior of this should be to align the calltips on editors an consoles.
Also we need to define if the behavior will work on hover or with shortcut?
Some screenshots of what VSCode displays.
Hint on imports

Hint on funcs


Ordinal formating in NumberFormat

I'm not sure this is the right place to ask. But in the spirit of removing limitations in NumberFormat, wouldn't it be useful to add a way to format ordinal number? Indeed PluralRules gives us the order but NumberFormat does not allow us for example to map "one" to "st" (in English), "two" to "nd" etc... ?
See also: https://github.com/moment/luxon/issues/118#issuecomment-996083441

Related issues :

https://github.com/tc39/proposal-intl-numberformat-v3/issues/22
https://github.com/tc39/ecma402/issues/494
https://github.com/tc39/ecma402/issues/95

The issues @romulocintra linked are appropriate to track this feature request. Please upvote those issues and weigh in with use cases.


MAINT: _lib: add missing f string to _deprecate_positional_args

https://github.com/scipy/scipy/pull/22099#issuecomment-2555818300

Thanks Jake

Thanks for catching that, Jake, and thanks for beating me to the review, Tyler!


feat(docker): Build python 3.11 docker image

SUMMARY
We want to use Python 3.11 in the docker image to benefit from its performance improvements.
TESTING INSTRUCTIONS
Run the docker build and see if it works with Python 3.11
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 backward-compatible
[ ] Confirm DB migration upgrade and downgrade tested
[ ] Runtime estimates and downtime expectations provided

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

I am not changing the default image version which is using PY 3.9. I just added the ability to create additional images with 3.11 so that we can use it with Superset's code base.
Talking of database drivers, Many of the drivers we use, do support Py 3.11. For e.g. pyathena, redshift-connector, pyscopg2, and many more.

Closing in favor of upcoming PR as per this comment.


"No payment found" error

This might be related to #13 (same error message), but opening a separate issue since I'm not quite sure.
For me, steps to reproduce (as of moments ago, and after trying multiple times with different invoices):

opened chrome browser from android phone and visited https://pollofeed.com and generated invoice
pasted invoice into phoenix
got "No Payment found" error with no other description

A few days ago, I was still unable to pay PolloFeed but was getting a different error: "incorrect payment details or unknown payment hash." Whereas now, the error seems to have switched to this "No payment found" error at least when trying to pay PolloFeed.
When trying to pay some other sites (such as, for example, an invoice generated by the telegram bot @lntxbot), I am now getting the "incorrect payment details or unknown payment hash" error. Whereas before, I had successfully been able to pay with Phoenix.
Hope this helps with some debugging. Let me know if there is more information you need.
P.S. Nice work on Phoenix!! Once these kinks are worked out, it will be a fantastic user experience!

Hello, thanks for reporting this issue. I reckon this is the same as #13. Can you provide your node id? You can find that in the Settings page > Channels list.

Thanks. Node id sent privately via gitter to you.

The problem comes from an issue in the relaying node (ACINQ node here), which basically expects a direct channel to the final node when relaying a payment to this final node, if this node claims support for multipart payment. This issue will be fixed with https://github.com/ACINQ/eclair/pull/1253


Splash screen

For iOS:
I replaced the default splash screen images with the git-touch icon with three variations of resolution.
For Android:
There are two ways of doing this:

Adding the images in all the mipmap folders with varying densities.
Adding a drawable image.

The first one seems like a better option but for some reason, it doesn't work. The second one worked and that is what I've implemented. Let me know if this is alright.
(Sorry for the extra commit. Forgot to include the 1x resolution image for iOS)

Sorry for the extra commit

Never mind. The extra commit could be squashed


Fix circular DMA

Fixes #1142
This fixes a subtle bug which was discovered in #1142
@thedevleon mind testing if this fixes your original issue?

@jessebraham there are new clippy lints triggering as of today's nightly - and at least the thing about AesFlavour might be a false-positive. I wonder if we should limit clippy to the MSRV toolchain? We could get a bunch of new warnings/errors whenever we raise the MSRV then but with nightly we can get new (and especially unrelated) warnings out of a sudden with nightly - not sure what would be the best way to go ... I could probably mute those lints here but having totally unrelated changes in random PRs doesn't sound pleasant to me 🤔

@thedevleon mind testing if this fixes your original issue?

Yes, the embassy_i2s_sound sample now produces a noise-free sine wave without any additional modifications.


Fix certainty fill and recognition slider

Improved implementation
Fixes fill at 0% certainty bug
Aligns recognition point slider with certainty bar above as it has a min of 10 and a max of 90

The slider thumb still looks a a bit wonky compared to 10% and 90% in the certainty bar above, but this is due to the default styling of the slider thumb / nature of sliders.
See https://microbit-global.monday.com/boards/1356069004/views/10076885/pulses/1361692631

https://certainty-tweaks.ml-trainer.pages.dev/

I wonder if it is intuitive for users that we have intentionally limited the range of the slider, or whether they would think it is a bug since it looks like the slider should be able to slide to the ends. Also, I wonder whether there is a thoughtful design/practical reason why it is limited to 10-90. Maybe something to discuss?

I've added this comment to Monday.com task.


We need to minimally exercise/test the produced tgz releases

As a follow up on #2713 (and #672 and...):
We need to at minimum:
check that the tar file is usable/un tarrable, contains a working bin/istioctl for linux and ideally check also the mac version (and windows as a third priority)
and that using only that tar ball one can installs istio (kubectl -f install/kubernetes/istio-auth.yaml) and inject 1 service

Currently the images are functionally tested. We should add more tests like:

"istioctl version" and make sure it spits out the right version that we expect.
Image version check (Prevents https://github.com/istio/istio/issues/4266#issuecomment-374459516)


[FLINK-2790] [yarn] [ha] Adds high availability support for Yarn

Adds high availability support for Yarn by exploiting Yarn's functionality to restart a failed application master. Depending on the Hadoop version the behaviour is an increasing superset of functionalities of the preceding version's behaviour
2.3.0 <= version < 2.4.0

Set the number of application attempts to the configuration value yarn.application-attempts. This means that the application can be restarted yarn.application-attempts time before yarn fails the application. In case of an application master, all other task manager containers will also be killed. It's important to note that the number of application attempts set within Flink cannot exceed the yarn cluster setting yarn.resourcemanager.am.max-attempts with which the Yarn cluster was started. Thus, yarn.resourcemanager.am.max-attempts is the upper bound for application restarts.

2.4.0 <= version < 2.6.0

Additionally, enables that containers will be kept across application attempts. This avoids the killing of TaskManager containers in the case of an application master failure. This has the advantage that the startup time is faster and that the user does not have to wait for obtaining the container resources again.

2.6.0 <= version

Sets the attempts failure validity interval to the akka timeout value. The attempts failure validity interval says that an application is only killed after the system has seen the maximum number of application attempts during one interval. This avoids that a long lasting job will deplete it's application attempts.

This PR also refactors the different Yarn components to allow the start-up of testing actors within Yarn. Furthermore, the JobManager start up logic is slightly extended to allow code reuse in the ApplicationMasterBase.
The HA functionality is tested via the YARNHighAvailabilityITCase where an application master is multiple times killed. Each time it's checked that the single TaskManager successfully reconnects to the newly started YarnJobManager. In case of version 2.3.0, the TaskManager is restarted.

I've looked a bit over the code and it all looks like good changes.
I've tested the code on a Hadoop 2.6.0 cluster and the YARN session was restarting properly. But I think that's not the expected behavior.
We actually want the TMs to stay alive and reconnect to the new AM.

I think TMs are only kept alive if their containers have been properly started. If the AM happens to die while the TM container are started up, I think they will be terminated as well. Another question is how did you kill the AM and what do you mean with "[...] restarting properly. But I think that's not the expected behavior"?

Looks like a lot of work to figure out the different version behaviours. Good job and thanks for the clear explanation. :)
I guess Robert meant with "not restarting properly" that the TMs were restarted as well.

I will try this out later today.

I was just curious whether he killed them gracefully with a PoisonPill or via killing the JVM process.

I killed the AM using "kill" from the command line, and all the Taskmanagers were shutting down

I found the issue. My code did not properly reflected the methods setKeepContainersAcrossApplicationAttempts and setAttemptFailuresValidityInterval. With the fix, already started containers are retained. Tested it with Yarn 2.7.1.

Good catch @rmetzger :-)

The code looks good. :-) I like the changes around the testing classes and the changes to the retrieval utils (that one I've looked into in more detail). I didn't check the YARN logic in detail though. I'm going to try it out now locally and report back. I expect that to work just fine and then we can safely merge this I think. :)

I have a dependency problem with Curator leading to:
ERROR org.apache.flink.runtime.jobmanager.JobManager                - Error while starting up JobManager
java.lang.NoSuchMethodError: org.apache.curator.utils.PathUtils.validatePath(Ljava/lang/String;)Ljava/lang/String;
    at org.apache.curator.framework.imps.NamespaceImpl.<init>(NamespaceImpl.java:37)
    at org.apache.curator.framework.imps.CuratorFrameworkImpl.<init>(CuratorFrameworkImpl.java:113)
    at org.apache.curator.framework.CuratorFrameworkFactory$Builder.build(CuratorFrameworkFactory.java:124)
    at org.apache.flink.runtime.util.ZooKeeperUtils.startCuratorFramework(ZooKeeperUtils.java:83)
    at org.apache.flink.runtime.util.ZooKeeperUtils.createLeaderElectionService(ZooKeeperUtils.java:145)
    at org.apache.flink.runtime.util.LeaderElectionUtils.createLeaderElectionService(LeaderElectionUtils.java:52)
    at org.apache.flink.runtime.jobmanager.JobManager$.createJobManagerComponents(JobManager.scala:1595)
    at org.apache.flink.runtime.jobmanager.JobManager$.startJobManagerActors(JobManager.scala:1672)
    at org.apache.flink.runtime.jobmanager.JobManager$.startJobManagerActors(JobManager.scala:1629)
    at org.apache.flink.runtime.jobmanager.JobManager$.startActorSystemAndJobManagerActors(JobManager.scala:1307)
    at org.apache.flink.yarn.ApplicationMasterBase.runAction(ApplicationMasterBase.scala:127)
    at org.apache.flink.yarn.ApplicationMasterBase$$anon$1.run(ApplicationMasterBase.scala:76)
    at java.security.AccessController.doPrivileged(Native Method)
    at javax.security.auth.Subject.doAs(Subject.java:360)
    at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1608)
    at org.apache.flink.yarn.ApplicationMasterBase.run(ApplicationMasterBase.scala:74)
    at org.apache.flink.yarn.ApplicationMaster$.main(ApplicationMaster.scala:35)
    at org.apache.flink.yarn.ApplicationMaster.main(ApplicationMaster.scala)

Our application master class path:
13:45:50,795 DEBUG org.apache.flink.yarn.ApplicationMaster                       - All environment variables: {PATH=/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin, HADOOP_CONF_DIR=/Users/ufuk/Downloads/hadoop-2.6.0/etc/hadoop, MAX_APP_ATTEMPTS=2, HADOOP_SECURE_DN_PID_DIR=, HADOOP_PID_DIR=, MAIL=/var/mail/ufuk, LD_LIBRARY_PATH=:/Users/ufuk/Downloads/hadoop-2.6.0/lib/native:/Users/ufuk/Downloads/hadoop-2.6.0/lib/native, LOGNAME=ufuk, JVM_PID=13307, _DETACHED=false, PWD=/tmp/hadoop-ufuk/nm-local-dir/usercache/ufuk/appcache/application_1444217271951_0004/container_1444217271951_0004_01_000001, HADOOP_YARN_USER=yarn, HADOOP_PREFIX=/Users/ufuk/Downloads/hadoop-2.6.0, LOCAL_DIRS=/tmp/hadoop-ufuk/nm-local-dir/usercache/ufuk/appcache/application_1444217271951_0004, YARN_IDENT_STRING=ufuk, HADOOP_SECURE_DN_LOG_DIR=/, SHELL=/bin/zsh, YARN_CONF_DIR=/Users/ufuk/Downloads/hadoop-2.6.0/etc/hadoop, JAVA_MAIN_CLASS_10305=org.apache.hadoop.yarn.server.nodemanager.NodeManager, LOG_DIRS=/Users/ufuk/Downloads/hadoop-2.6.0/logs/userlogs/application_1444217271951_0004/container_1444217271951_0004_01_000001, _CLIENT_SHIP_FILES=file:/Users/ufuk/.flink/application_1444217271951_0004/flink-python-0.10-SNAPSHOT.jar,file:/Users/ufuk/.flink/application_1444217271951_0004/log4j-1.2.17.jar,file:/Users/ufuk/.flink/application_1444217271951_0004/slf4j-log4j12-1.7.7.jar,file:/Users/ufuk/.flink/application_1444217271951_0004/logback.xml,file:/Users/ufuk/.flink/application_1444217271951_0004/log4j.properties, _CLIENT_USERNAME=ufuk, HADOOP_YARN_HOME=/Users/ufuk/Downloads/hadoop-2.6.0, TMPDIR=/var/folders/_c/5tc5q5q55qjcjtqwlwvwd1m00000gn/T/, HADOOP_DATANODE_OPTS=-Dhadoop.security.logger=ERROR,RFAS -Dhadoop.security.logger=ERROR,RFAS , HADOOP_SECONDARYNAMENODE_OPTS=-Dhadoop.security.logger=INFO,RFAS -Dhdfs.audit.logger=INFO,NullAppender -Dhadoop.security.logger=INFO,RFAS -Dhdfs.audit.logger=INFO,NullAppender , _FLINK_JAR_PATH=file:/Users/ufuk/.flink/application_1444217271951_0004/flink-dist-0.10-SNAPSHOT.jar, __CF_USER_TEXT_ENCODING=0x1F5:0x0:0x0, LC_CTYPE=UTF-8, _CLIENT_TM_COUNT=2, _CLIENT_TM_MEMORY=1024, SHLVL=3, HADOOP_IDENT_STRING=ufuk, YARN_ROOT_LOGGER=INFO,RFA, _SLOTS=-1, _CLIENT_HOME_DIR=file:/Users/ufuk, APP_SUBMIT_TIME_ENV=1444218347305, NM_HOST=<IP_ADDRESS>, _APP_ID=application_1444217271951_0004, YARN_LOGFILE=yarn-ufuk-nodemanager-vinci.local.log, HADOOP_SECURE_DN_USER=, HADOOP_CLASSPATH=/contrib/capacity-scheduler/*.jar:/contrib/capacity-scheduler/*.jar, HADOOP_HDFS_HOME=/Users/ufuk/Downloads/hadoop-2.6.0, HADOOP_MAPRED_HOME=/Users/ufuk/Downloads/hadoop-2.6.0, HADOOP_COMMON_HOME=/Users/ufuk/Downloads/hadoop-2.6.0, HADOOP_CLIENT_OPTS=-Xmx512m -Xmx512m , _=/bin/java, APPLICATION_WEB_PROXY_BASE=/proxy/application_1444217271951_0004, _STREAMING_MODE=false, NM_HTTP_PORT=8042, JAVA_MAIN_CLASS_13316=org.apache.flink.yarn.ApplicationMaster, HADOOP_OPTS= -Djava.net.preferIPv4Stack=true -Dhadoop.log.dir=/Users/ufuk/Downloads/hadoop-2.6.0/logs -Dhadoop.log.file=hadoop.log -Dhadoop.home.dir=/Users/ufuk/Downloads/hadoop-2.6.0 -Dhadoop.id.str=ufuk -Dhadoop.root.logger=INFO,console -Djava.library.path=/Users/ufuk/Downloads/hadoop-2.6.0/lib/native -Dhadoop.policy.file=hadoop-policy.xml -Djava.net.preferIPv4Stack=true -Djava.net.preferIPv4Stack=true -Dhadoop.log.dir=/Users/ufuk/Downloads/hadoop-2.6.0/logs -Dhadoop.log.file=hadoop.log -Dhadoop.home.dir=/Users/ufuk/Downloads/hadoop-2.6.0 -Dhadoop.id.str=ufuk -Dhadoop.root.logger=INFO,console -Djava.library.path=/Users/ufuk/Downloads/hadoop-2.6.0/lib/native -Dhadoop.policy.file=hadoop-policy.xml -Djava.net.preferIPv4Stack=true, SSH_CLIENT=::1 60015 22, NM_PORT=60017, USER=ufuk, CLASSPATH=/tmp/hadoop-ufuk/nm-local-dir/usercache/ufuk/appcache/application_1444217271951_0004/container_1444217271951_0004_01_000001/*:/Users/ufuk/Downloads/hadoop-2.6.0/etc/hadoop:/Users/ufuk/Downloads/hadoop-2.6.0/share/hadoop/common/*:/Users/ufuk/Downloads/hadoop-2.6.0/share/hadoop/common/lib/*:/Users/ufuk/Downloads/hadoop-2.6.0/share/hadoop/hdfs/*:/Users/ufuk/Downloads/hadoop-2.6.0/share/hadoop/hdfs/lib/*:/Users/ufuk/Downloads/hadoop-2.6.0/share/hadoop/yarn/*:/Users/ufuk/Downloads/hadoop-2.6.0/share/hadoop/yarn/lib/*, SSH_CONNECTION=::1 60015 ::1 22, HADOOP_TOKEN_FILE_LOCATION=/tmp/hadoop-ufuk/nm-local-dir/usercache/ufuk/appcache/application_1444217271951_0004/container_1444217271951_0004_01_000001/container_tokens, HADOOP_NFS3_OPTS=, HADOOP_NAMENODE_OPTS=-Dhadoop.security.logger=INFO,RFAS -Dhdfs.audit.logger=INFO,NullAppender -Dhadoop.security.logger=INFO,RFAS -Dhdfs.audit.logger=INFO,NullAppender , YARN_NICENESS=0, HOME=/home/, CONTAINER_ID=container_1444217271951_0004_01_000001, HADOOP_PORTMAP_OPTS=-Xmx512m -Xmx512m , MALLOC_ARENA_MAX=4}

The problem is */Users/ufuk/Downloads/hadoop-2.6.0/share/hadoop/yarn/lib/**, which contains Curator 2.6.
I've used vanilla YARN 2.6.0. Robert for whom it worked used cdh 5.4.

Smooth experience now. Works as expected with vanilla YARN 2.6.0.
+1 to merge.

Thanks for the review @uce. I addressed your comments.
I fixed the problem with Hadoop 2.6.0 by relocating Flink's curator dependency to org.apache.flink.shaded.org.apache.curator. Furthermore, I bumped flink-shaded-curator's Guava version to Flink's Guava version so that we don't include too many different Guava versions in the resulting flink-dist.jar.


Is there a way to send a *slack.Message?

In the case of receiving a callback for an interactive message, we end up with a parsed *slack.Message as the original message (see https://github.com/nlopes/slack/blob/master/attachments.go#L55). Now what if we want to slightly modify this message, and then update it?
AFAICT the only way to post/update messages is through this family of methods. None of these seem to support taking the *slack.Message struct, and so to make a slight modification to the message it would require breaking everything apart into the appropriate MsgOptions (which seems both brittle and unnecessary).
Am I missing something here?

You're not missing anything, just hasnt' been a need to do what your asking.
slack's api historical uses url form posts for sending messages which means there isn't a direct translation between slack.Message and what we post. if you want to write a helper Option that does the conversation for the SendMessage api that would be useful. I'd have it take a straight struct though not a pointer.


whois doesn’t work

Issue description
In a terminal, whois nixos.org returns:
getaddrinfo: Servname not supported for ai_socktype

Steps to reproduce

Run nix-shell -p inetutils --run 'whois nixos.org'.

Technical details

System: 17.03.1700.51a83266d1 (Gorilla)
Nix version: nix-env (Nix) 1.11.13
Nixpkgs version: "17.03.1700.51a83266d1"
Sandboxing enabled: yes

I fixed this some time ago in master. Now I have back ported it: 7da346a9f8dffb3b4a9c66deeee84028dd478457

Awesome, thanks!

Looks like this issue re-surfaced, on latest nixos. I can reproduce it as follows:
; docker run -it --rm nixos/nix nix-shell '<nixpkgs>' -p inetutils --run 'whois nixos.org'
...
getaddrinfo: Servname not supported for ai_socktype
# FAILED(1) after 11.305s

Interestingly the same command works on my debian machine, even when using exactly the same nixpkgs release/checkout. My hunch is, that this has something todo with the missing /etc/services file.
Fetchmail was failing with a similar error, but worked after providing a port for pop3 access:
; fetchmail -f fetchmailrc.tmp
fetchmail: getaddrinfo("wp12252871.mail.server-he.de","pop3") error: Servname not supported for ai_socktype
fetchmail: Try adding the --service option (see also FAQ item R12).

I have the same issue. I think it must be configuration-dependent because in my case it works on some machine but not others, even if they're both running NixOS 23.05.

unable to reproduce via original instructions, not tested via docker.


Add basic interactable system

I'm not sure where to go from here, so I'm going to put it up for review. Hopefully people can help me steer this to a better place :)

I refactored some of this so we can utilize it for serverside shit too, and removed reliance on entity creation


can't use unicode string in caption

as the title says
btw, where can we find more eye-catching demo of InForm

no, I found that the unicode character can't display correclty in InForm, but can display in the QB64-built exe

Hi. That’s a limitation of QB64 itself, as it doesn’t handle Unicode on its own, so InForm inherits that.
There are a few demos at www.qb64.org/inform/demos


Operator Appends Tag to Image Digest, Causing InvalidImageName Errors

Despite using just the image digest (@sha256:...), the operator appears to append a tag automatically. This is breaking deployments since Kubernetes does not support both a tag and a digest together.
Steps to Reproduce:

Create or modify a CR to reference an image by its digest without specifying a tag:

app:
  image:
    repository: default-route-openshift-image-registry.apps-crc.testing/test2/wandb-local@sha256:95f854ed3dbe56290c6bad543aa55ce77986d5c444be2d71388c76ea0aea091b
    # No tag specified

Apply the CR:
oc apply -f cr.yaml

The operator processes the resource, but the deployment fails with the following error:
Warning  InspectFailed  kubelet  Failed to apply default image tag "<image-ref>:": couldn't parse image name "<image-ref>:": invalid reference format

Expected Behavior:
The operator should respect the image digest and not append any tag (especially an empty tag :) when using a digest reference in the CR.

app:
  image:
    repository: default-route-openshift-image-registry.apps-crc.testing/test2/wandb-local@sha25
    tag: 95f854ed3dbe56290c6bad543aa55ce77986d5c444be2d71388c76ea0aea091b

@vijay-wandb - Have you retested it?

Closing it as per Vijay's retest.


Classes are not generated - TailwindCSS

When a BE dev wanted to test out and created simple styling rules for organizing projects, tailwind was installed and properly generated by CLI.
Several methods were applied and tested but it seems like nothing worked.
The output.css were linked. It just reset the whole page but didn't do anything else.

"@import" statements were used and nothing changed.

Tried moving files around under different directories and renamed them but no progress.

It turns out the content in tailwind.config.js is the culprit. I've just realized that in order to see effects or stylings that are applied on any element, files must be included in content. For example, if you have src/index.html, you'll need
module.exports = {
  content: ["./src/**/*.{html,js}"],
  theme: {
    extend: {},
  },
  plugins: [],
}

Let's say if your index.html lives under public directory like public/index.html, the style won't be applied to the file.


riscv-cc: Describe that vxrm/vxsat is not preserved across calls

There are discussions in https://github.com/riscv/riscv-v-spec/issues/739.
The reason that ISA makes the vx round mode only available in CSR is for encoding space.
I think we can make it non-preserved across calls to use it efficiently.

Current description already implied call-clobber/caller-save, did you have practical example to show the advantage or intention behind this change?

I believe these should actually be treated the same as frm/fflags: that is, they have thread storage duration.  (In other words, they are effectively global variables within a thread context.)
cc @kasanovic

Since it is already call-clobbered, I think I have no problem now. Thanks.

I have a case to show the reason not to preserve vcsr/vxrm/vxsat across calls like VL/VType does.
Current ABI allows VXRM to be set in one function (e.g. foo()) and to be used in another function (e.g. bar()).
vint8m1_t test0(vint8m1_t dest, vint8m1_t op1, vint8m1_t op2, size_t vl)
{
    vint8m1_t t2 = vaadd_rdn_vv_i8m1(op1, op2, vl);
    foo();  // set VXRM to specific mode
    bar();  // user of the specific mode set by foo()
    ...
}

This imposes a strong order on intrinsics which use VXRM in function test0
The expected codegen of intrinsic vaadd_rdn_vv_i8m1 [1] is
  csrwi vxrm, 2 ; round-down
  vaadd.vv v8, v9, v10

Once the intrinsic vaadd_rdn_vv_i8m1 is moved to the between of the foo() and bar() by the compiler,
vint8m1_t test0(vint8m1_t dest, vint8m1_t op1, vint8m1_t op2, size_t vl)
{
-   vint8m1_t t2 = vaadd_rdn_vv_i8m1(op1, op2, vl);
    foo();  // set VXRM to specific mode
+   vint8m1_t t2 = vaadd_rdn_vv_i8m1(op1, op2, vl);
    bar();  // user of the specific mode set by foo()
    ...
}

the codegen would become the asssembly below:
   csrrwr a0, vxrm, 2   // Previous mode is unknown, then save it before setting it.
   vaadd.vv v8, v9, v10
   csrw vxrm, a0         // Restore the previous mode for bar();

If VXRM is not preserved across calls, then the compiler doesn't need to generate the instructions to save and restore the mode.
[1] vaadd_rdn_vv_i8m1 is in the proposal https://github.com/riscv-non-isa/rvv-intrinsic-doc/issues/144

I am still trying to understand why we don't treat vxrm and vxsat the same as frm and fflags (i.e. neither call-preserved nor call-clobbered, but thread-local).

I am still trying to understand why we don't treat vxrm and vxsat the same as frm and fflags (i.e. neither call-preserved nor call-clobbered, but thread-local).

I think the corresponding registers on X86 of the frm and fflags are the control bits and status bits of
MXCSR.
As x86-64 psABI says
The control bits of the MXCSR register are callee-saved (preserved across
calls), while the status bits are caller-saved (not preserved).

my understanding is that
when pragma FENV ACCESS is OFF, FP round mode is callee-saved. floating point operation can be optimized assuming they are all round-to-nearest-even in the caller function.
And when pragma FENV ACCESS is ON, callee's change on FP round mode can be observed by the caller.
Floating point operations need to be kept in strong order in the caller function and then the compiler would disable some floating-point optimizations.
I think it follows the same reason why we make VL/VTYPE non-preserved across calls and adopt explicit vl model on rvv intrinsics.
Based the discussion, flipping the fixed-point rounding mode could happen very frequently. And current compiler implementation doesn't perform CSE on fixed-point rvv intrinsics.
I think calling convention of X86 Direction Flag is one possible option we can learn.
X86 ABI says
The direction flag DF in the %rFLAGS register must be clear (set to “forward”
direction) on function entry and return.

Calling convention guide by Agner Fog
Direction flag
The rules for the direction flag is the same in all systems. The direction flag is cleared by
default. If the direction flag is set, then it must be cleared again before any call or return.

The default value on the function entry/return would introduce some issue for interrupt handler.
I see llvm clears the direction flag explicitly in the function prolog when the calling convention is X86_INTR.

The x86 psABI stuff is a distraction, IMO.  The C language's floating-point environment, which includes both the flags and the rounding mode, is defined to have thread storage duration [1], and that's true regardless of ABI.
[1] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf page 224

IIUC, you are trying to making vxrm changing implicitly without restore, and that's intrinsic design issue than ABI issue IMO, let me elaborate that by talking about the fenv first.
And why I using ﬂoating-point environment in C as reference is because I think we should align the behavior between vxrm/vxsat and frm/fflags.
ISO/IEC 9899:2011: 7.6:
1) The header <fenv.h> deﬁnes several macros, and declares types and functions that
provide access to the ﬂoating-point environment.  The ﬂoating-point environment refers
collectively to any ﬂoating-point status ﬂags and control modes supported by the
implementation.204) A ﬂoating-point status ﬂag is a system variable whose value is set
(but never cleared) when a ﬂoating-point exception is raised, which occurs as a side effect
of exceptional ﬂoating-point arithmetic to provide auxiliary information.205) A ﬂoating-
point control mode is a system variable whose value may be set by the user to affect the
subsequent behavior of ﬂoating-point arithmetic.

and more text from ISO/IEC 9899:2011: 7.6:
2) The ﬂoating-point environment has thread storage duration. The initial state for a
thread’s ﬂoating-point environment is the current state of the ﬂoating-point environment
of the thread that creates it at the time of creation.

That give us the reason why define frm/fflags as thread local storage rather than callee-save or caller-save like Andrew said in other comment, it's more like a global variable in the execution environment, and you won't say a global variable is callee-save or caller-save :p

And why I think that's intrinsic design issue than ABI issue? ISO/IEC 9899:2011: 7.6.3: give some description on that:
Certain programming conventions support the intended model of use for the ﬂoating-
point environment:206)
— a function call does not alter its caller’s ﬂoating-point control modes, clear its caller’s
ﬂoating-point status ﬂags, nor depend on the state of its caller’s ﬂoating-point status
ﬂags unless the function is so documented;
— a function call is assumed to require default ﬂoating-point control modes, unless its
documentation promises otherwise;
— a function call is assumed to have the potential for raising ﬂoating-point exceptions,
unless its documentation promises otherwise.

So based on the conventions described in C11 spec, yes, you CAN design those fixed-point operation intrinsic functions with the changing fenv, but I think it's might be a bad idea since those intrinsic functions is trying to emulate the static rounding mode by setting dynamic rounding mode, and those intrinsic function come with side effect of changing default rounding isn't make too much sense, I would strongly prefer those flags should only changed on explicitly function call, like fesetround in fenv stuffs.

In summary, I support @arcbbb 's PR and I would go further by making the same change to the floating-point section: clarifying frm/fflags as call-clobbered and removing mention of thread storage duration.

If the calling convention of frm & fflags changed, I am not sure how not to break a C conforming program. so I only address vxrm & vxsat here.

A separate question is whether fenv or venv are useful constructs to programmers. Another question is how C-language extensions, like RISC-V vector intrinsics, interact with them. I don't think these details need to mentioned in the ABI.
This is my understanding, feel free to correct it.

From the language perspective, I attempt to make the RISC-V vector intrinsics being context-free
in proposal [1] & [2].
I think we can move to rvv-intrinsic-doc for the follow-up discussion.

Assume we have a kernel function like this
void f(uint16_t c[256], uint16_t a[256], uint16_t b[256])
{
  for (int i = 0; i < 256; i++) {
    c[i] = (a[i] + b[i] + 1) / 2;
  }
}

and the compiler automatically vectorizes it into this
(It is a made-up example. correct me if there are mistakes)
f:
    li a6, 256
    vsetvli a4, a6, e16, m1, ta, mu
loop:
    vle8.v  v8, (a1)
    vle8.v  v9, (a2)
    csrwi vxrm, 0    ; round up mode
    vaadd.vv    v8, v8, v9
    vse8.v  v8, (a0)
    sub a6, a6, a4
    add a1, a1, a4
    add a2, a2, a4
    add a0, a0, a4
    vsetvli a4, a6, e16, m1, ta, mu
    bnez    a4, loop
    ret

It is done if vxrm is not preserved across calls.
But given the programming convention of FENV, user is not aware that the function could change the frm state. The compiler has to save and restore the state like this
f:
    li a6, 256
    vsetvli a4, a6, e16, m1, ta, mu
loop:
    vle8.v  v8, (a1)
    vle8.v  v9, (a2)
-   csrwi vxrm, 0    ; round up mode
+ csrrwi a5, vcsr, 0 ; save vxrm & vxsat. set round-up mode.
    vaadd.vv    v8, v8, v9
+  csrw vcsr, a5  ; restore vxrm & vxsat
    vse8.v  v8, (a0)
    sub a6, a6, a4
    add a1, a1, a4
    add a2, a2, a4
    add a0, a0, a4
    vsetvli a4, a6, e16, m1, ta, mu
    bnez    a4, loop
    ret

This PR is to save the compiler's effort to save/restore the vcsr state.

I think that should be intrinsic spec issue and irreverent to psABI, you can define those fixed-point operation intrinsic functions with the changing vxrm/vxsat field in vcsr.

My last example is a pure C code without using built-in intrinsic functions,
so it is beyond the scope of what intrinsic-doc can define.
Besides, the programming language can be C or other domain specific language, for example, Halide.
I think it is the reason to we specify calling convention in psABI.

Ideally compiler could hoist set/restore rounding mode before/after loop, so I would say that's compiler optimization issue rather than ABI issue.
f:
    li a6, 256
    vsetvli a4, a6, e16, m1, ta, mu
+ csrrwi a5, vcsr, 0 ; save vxrm & vxsat. set round-up mode.
loop:
    vle8.v  v8, (a1)
    vle8.v  v9, (a2)
    vaadd.vv    v8, v8, v9
    vse8.v  v8, (a0)
    sub a6, a6, a4
    add a1, a1, a4
    add a2, a2, a4
    add a0, a0, a4
    vsetvli a4, a6, e16, m1, ta, mu
    bnez    a4, loop
+  csrw vcsr, a5  ; restore vxrm & vxsat
    ret

ABI change isn't means we grant compiler permission to change the CSR silently, in that case, compiler will change vxrm and vxsat only IF vectorization successful, that mean user can't predict where vxrm and vxsat might be changed.

Ideally compiler could hoist set/restore rounding mode before/after loop, so I would say that's compiler optimization issue rather than ABI issue.

Right, compiler could hoist the rounding mode setting out of the loop.
But once psABI defines it is non-preserved across calls, the extra registers and instructions to backup the incoming value and restore the mode on return can be removed.

ABI change isn't means we grant compiler permission to change the CSR silently, in that case, compiler will change vxrm and vxsat only IF vectorization successful, that mean user can't predict where vxrm and vxsat might be changed.

Right, that's why we prefer non-preserved across calls.
Upon returning from a call, user don't assume vxrm state and need to set it again, as exactly how we deal with vl/vtype.

Yeah, I guess we should consider that, but one issue is we gonna to run release process next Monday, so that's kind of last minutes change...
@jrtc27 I don't like last minutes too :(, but I guess that would be harder to change once we release, so I proposal remove the sentence "The vxrm and vxsat fields of vcsr have thread storage duration." from the spec for now, and then add few more words after release?

It would be better to miss a release than to bake in a short-sighed ABI decision.

Whatever gets decided it needs to be done with the input of the LLVM and GNU developers actively working on vector support

LLVM vector folks: @rofirrim @fraser
GNU vector folks: @zhongjuzhe @rjiejie
I would suggest remove all words about vxrm and vxsat from psABI spec at this release, and then we could having more time to discuss more complete/detailed solution, are you guys OK with that?
A +1 emoji or explicitly LGTM would be appreciate, of cause more comment/inputs are welcome!

SGTM.

Fine for me

SGTM too, assuming I'm that Fraser :)

Thanks everyone, I created another PR to pull out the sentence :)
And I will keep this PR open, and welcome for more discussion on that.

@arcbbb did you mind write up a RFC and having more complete proposal and having comparison between different scheme? maybe include how interactive with vector intrinsic stuffs?

I'll just stop here if no one is against the idea.

Hmmm, I would strongly suggest you should prepare a proposal, then we can have further discussion on psABI and gather boarder feedback.

That's all I have for now. Thanks.

I am not sure we are on the same page yet, I just summary what we have now:
@nick-knight's opinion is that we should treat vxrm/vxsat by analogue with frm/fflags and having something like venv with defining extra API to controlling that like this proposal: https://github.com/riscv-non-isa/rvv-intrinsic-doc/pull/46.
@aswaterman's thought is we don't have C fenv analogue for the fixed-point state, so we might not rush do decide that yet.
@arcbbb is trying to propose ABI spec change, can let compiler modify  vxrm and vxsat, implicitly without restoring.
Am I understand/interpret that right?
My thought is more close to @nick-knight's opinion, defining venv and API to access that,
And furthermore, I would like to following the fenvconvention described in C lang spec.
But I think part of this issue is more than psABI issue like Nick mention that might be describe in C API doc rather than psABI doc.
And pull it out for now is to preventing we are too rush to decide anything without complete consideration.

My current position arose from a lengthy conversation with @nick-knight, so I assume he's roughly in agreement with me.

We can't leave this issue undecided if we want a ratified standard vector calling convention.
I believe (and agree with) the consensus from other discussions (https://github.com/riscv-non-isa/riscv-elf-psabi-doc/issues/287) was that these would be temporary state, not preserved across function calls.

@arcbbb and me will propose more complete proposal in next few days.

Moving to #294


Simplify Method model

Drops PermitsBody and NoBody mixins.  These were used as marker traits on the constants so we could create a client DSL that does not accept an entity on methods where they're disallowed. It seems like a lot of magic to prevent someone from writing TRACE("oops this is illegal", uri"http://www.example.com/").  I think this supersedes #3426, but we can merge that while people debate this.

Drops Semantics trait.  The name appears in no spec, and nobody was using these fields at the type level.  All we need are a pair of booleans to reflect the full IANA registry.

Method has been a case class since the Spray fork, but it's not a proper product: not all Strings are a valid names, and each name uniquely defines isSafe and isIdempotent.

An alternative that would permit the old restrictions in that DSL would be to make every Method value an object.  Then each value would have its own type, and we could add syntax for POST.type, GET.type, etc.  This would make the DSL implementation noisier, and prevent the change of Method to a final class.
Another option is to phase out this DSL entirely, which I don't think has worked out well in practice.  I know @SystemFw has argued for phasing it out.  We can make it gentle if we keep code like we did here, but also deprecate it.

needs a conflict resolution

Sneaky breaking change: this removes Method.unapply.

If this removes unapply, how does that effect the dsl?

I don't think appreciably.  Unless people were doing something like:
case Method(name) -> Root / "blah" =>


Ability to create alarms by selecting the specific date

original idea is came from qw123wh/new-clock:issue #4
Currently, I hardcoded in no_alarm_notification branch

https://github.com/sanpei3/new-clock/issues/3 should be done before doing this issue


createAddress function undocumented

It's in the code but missing here:
http://emiliote.github.io/node-coinbase-api/#accounts

Added documentation for .get() and .createAddress() under Accounts.


import resolution error even as the import executes just fine

Environment data

Language Server version: v2023.10.10
OS and version: VSCode 1.83.0 running on macOS connected remotely via SSH to AmazonLinux 2023 on aarch64
Python version (& distribution if applicable, e.g. Anaconda): python 3.11.3
Code being executed in a notebook. Notebook kernel is connected to an external jupyter server running on the same remote machine.
Jupyter server kernels are using the same python runtime as what the python interpreter in VSCode is set to. I just run jupyter server separately to keep kernels alive even is VSCode's ssh connection blips.
The notebook root is set to "jupyter.notebookFileRoot": "${workspaceFolder}"

Code Snippet

import pandas as pd
import numpy as np
import holoviews as hv
from holoviews import opts
hv.extension('bokeh', 'matplotlib')

Expected behavior
All imports are valid and should be resolved. In fact, if I set the notebook kernel to point to the runtime directly (i.e not the external jupyter server), the imports resolve just fine.
Actual behavior
Pylance reports imports as unresolved. See below.

Logs

attached
python_lang_server_output.txt

Thanks for the issue.
Your log is showing that we get the python path of 'python3' for the kernel. At least I think that's what is happening:
For example, here's all the paths we looked for holoviews:
2023-10-05 13:20:30.391 [info] [Info  - 1:20:30 PM] (2507395) Could not import 'holoviews' in file '/home/ec2-user/dev/macro/sample_notebooks/visual.ipynb:pylance-notebook-cell:W0sdnNjb2RlLXJlbW90ZQ==.py'
2023-10-05 13:20:30.391 [info] [Info  - 1:20:30 PM] (2507395)   Looking in stubPath '/home/ec2-user/dev/macro/typings'
2023-10-05 13:20:30.391 [info] [Info  - 1:20:30 PM] (2507395)   Attempting to resolve stub package using root path '/home/ec2-user/dev/macro/typings'
2023-10-05 13:20:30.391 [info] [Info  - 1:20:30 PM] (2507395)   Attempting to resolve using root path '/home/ec2-user/dev/macro/typings'
2023-10-05 13:20:30.391 [info] [Info  - 1:20:30 PM] (2507395)   Looking in root directory of execution environment '/home/ec2-user/dev/macro'
2023-10-05 13:20:30.391 [info] [Info  - 1:20:30 PM] (2507395)   Attempting to resolve stub package using root path '/home/ec2-user/dev/macro'
2023-10-05 13:20:30.391 [info] [Info  - 1:20:30 PM] (2507395)   Attempting to resolve using root path '/home/ec2-user/dev/macro'
2023-10-05 13:20:30.391 [info] [Info  - 1:20:30 PM] (2507395)   Finding python search paths
2023-10-05 13:20:30.391 [info] [Info  - 1:20:30 PM] (2507395)   Executing interpreter: 'python3'
2023-10-05 13:20:30.391 [info] [Info  - 1:20:30 PM] (2507395)   Skipping '/home/ec2-user/.pyenv/versions/3.11.3/lib/python311.zip' because it is not a valid directory
2023-10-05 13:20:30.391 [info] [Info  - 1:20:30 PM] (2507395)   Received 3 paths from interpreter
2023-10-05 13:20:30.391 [info] [Info  - 1:20:30 PM] (2507395)     /home/ec2-user/.pyenv/versions/3.11.3/lib/python3.11
2023-10-05 13:20:30.391 [info] [Info  - 1:20:30 PM] (2507395)     /home/ec2-user/.pyenv/versions/3.11.3/lib/python3.11/lib-dynload
2023-10-05 13:20:30.391 [info] [Info  - 1:20:30 PM] (2507395)     /home/ec2-user/.pyenv/versions/3.11.3/lib/python3.11/site-packages
2023-10-05 13:20:30.391 [info] [Info  - 1:20:30 PM] (2507395)   Looking in python search path '/home/ec2-user/.pyenv/versions/3.11.3/lib/python3.11'
2023-10-05 13:20:30.391 [info] [Info  - 1:20:30 PM] (2507395)   Attempting to resolve stub package using root path '/home/ec2-user/.pyenv/versions/3.11.3/lib/python3.11'
2023-10-05 13:20:30.391 [info] [Info  - 1:20:30 PM] (2507395)   Attempting to resolve using root path '/home/ec2-user/.pyenv/versions/3.11.3/lib/python3.11'
2023-10-05 13:20:30.391 [info] [Info  - 1:20:30 PM] (2507395)   Looking in python search path '/home/ec2-user/.pyenv/versions/3.11.3/lib/python3.11/lib-dynload'
2023-10-05 13:20:30.392 [info] [Info  - 1:20:30 PM] (2507395)   Attempting to resolve stub package using root path '/home/ec2-user/.pyenv/versions/3.11.3/lib/python3.11/lib-dynload'
2023-10-05 13:20:30.392 [info] [Info  - 1:20:30 PM] (2507395)   Attempting to resolve using root path '/home/ec2-user/.pyenv/versions/3.11.3/lib/python3.11/lib-dynload'
2023-10-05 13:20:30.392 [info] [Info  - 1:20:30 PM] (2507395)   Looking in python search path '/home/ec2-user/.pyenv/versions/3.11.3/lib/python3.11/site-packages'
2023-10-05 13:20:30.392 [info] [Info  - 1:20:30 PM] (2507395)   Attempting to resolve stub package using root path '/home/ec2-user/.pyenv/versions/3.11.3/lib/python3.11/site-packages'
2023-10-05 13:20:30.392 [info] [Info  - 1:20:30 PM] (2507395)   Attempting to resolve using root path '/home/ec2-user/.pyenv/versions/3.11.3/lib/python3.11/site-packages'
2023-10-05 13:20:30.392 [info] [Info  - 1:20:30 PM] (2507395)   Looking in bundled stubs path '/home/ec2-user/.vscode-server/extensions/ms-python.vscode-pylance-2023.10.10/dist/bundled/stubs'
2023-10-05 13:20:30.392 [info] [Info  - 1:20:30 PM] (2507395)   Attempting to resolve stub package using root path '/home/ec2-user/.vscode-server/extensions/ms-python.vscode-pylance-2023.10.10/dist/bundled/stubs'
2023-10-05 13:20:30.392 [info] [Info  - 1:20:30 PM] (2507395)   Attempting to resolve using root path '/home/ec2-user/.vscode-server/extensions/ms-python.vscode-pylance-2023.10.10/dist/bundled/stubs'
2023-10-05 13:20:30.392 [info] [Info  - 1:20:30 PM] (2507395)   Looking for typeshed stdlib path
2023-10-05 13:20:30.392 [info] [Info  - 1:20:30 PM] (2507395)   Looking for typeshed stdlib path
2023-10-05 13:20:30.392 [info] [Info  - 1:20:30 PM] (2507395)   Attempting to resolve using root path '/home/ec2-user/.vscode-server/extensions/ms-python.vscode-pylance-2023.10.10/dist/typeshed-fallback/stdlib'
2023-10-05 13:20:30.392 [info] [Info  - 1:20:30 PM] (2507395)   Typeshed path not found
2023-10-05 13:20:30.392 [info] [Info  - 1:20:30 PM] (2507395)   Looking for typeshed third-party path
2023-10-05 13:20:30.392 [info] [Info  - 1:20:30 PM] (2507395)   Looking for typeshed stubs path
2023-10-05 13:20:30.392 [info] [Info  - 1:20:30 PM] (2507395)   Typeshed path not found

Specifically this output:
2023-10-05 13:20:30.391 [info] [Info  - 1:20:30 PM] (2507395)   Executing interpreter: 'python3'

Says the interpreter is python3.
My guess is that the Jupyter Extension doesn't know the path to the remote kernel (well because it's not a kernel created by the Jupyter extension).

Yeah, I can reproduce the problem if I start a jupyter server and use that as my kernel. The python path the jupyter extension returns in that case is 'python'.
I think this should probably be fixed by the jupyter extension team. They could instead default to the current python interpreter in the workspace, or maybe query the jupyter server for the path.


Fixes the multicluster e2e test

The secret was being created after the apps where
deployed on the remote.  This was causes the test
to never think the apps successfully deployed since
the envoy sidecar was continually restarting.

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: john-a-joyce
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: costinm
If they are not already assigned, you can assign the PR to them by writing /assign @costinm in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

tests/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@john-a-joyce: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/e2e-mixer-no_auth.sh
9e5e263a270637570f82c12ae7fba4cecde3be8a
link
/test e2e-mixer-no_auth

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@john-a-joyce: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-pilot-e2e-envoyv2-v1alpha3.sh
9e5e263a270637570f82c12ae7fba4cecde3be8a
link
/test istio-pilot-e2e-envoyv2-v1alpha3

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@john-a-joyce: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-pilot-e2e-envoyv2-v1alpha3.sh
9e5e263a270637570f82c12ae7fba4cecde3be8a
link
/test istio-pilot-e2e-envoyv2-v1alpha3

prow/e2e-bookInfoTests-v1alpha3.sh
9e5e263a270637570f82c12ae7fba4cecde3be8a
link
/test e2e-bookInfoTests-envoyv2-v1alpha3

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@john-a-joyce: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-pilot-e2e-envoyv2-v1alpha3.sh
9e5e263a270637570f82c12ae7fba4cecde3be8a
link
/test istio-pilot-e2e-envoyv2-v1alpha3

prow/e2e-bookInfoTests-v1alpha3.sh
9e5e263a270637570f82c12ae7fba4cecde3be8a
link
/test e2e-bookInfoTests-envoyv2-v1alpha3

prow/e2e_pilotv2_auth_sds.sh
9e5e263a270637570f82c12ae7fba4cecde3be8a
link
/test istio_auth_sds_e2e

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@john-a-joyce: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-pilot-e2e-envoyv2-v1alpha3.sh
9e5e263a270637570f82c12ae7fba4cecde3be8a
link
/test istio-pilot-e2e-envoyv2-v1alpha3

prow/e2e-bookInfoTests-v1alpha3.sh
9e5e263a270637570f82c12ae7fba4cecde3be8a
link
/test e2e-bookInfoTests-envoyv2-v1alpha3

prow/e2e_pilotv2_auth_sds.sh
9e5e263a270637570f82c12ae7fba4cecde3be8a
link
/test istio_auth_sds_e2e

prow/e2e-bookInfoTests-trustdomain.sh
9e5e263a270637570f82c12ae7fba4cecde3be8a
link
/test e2e-bookInfoTests-trustdomain

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@john-a-joyce: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-pilot-e2e-envoyv2-v1alpha3.sh
9e5e263a270637570f82c12ae7fba4cecde3be8a
link
/test istio-pilot-e2e-envoyv2-v1alpha3

prow/e2e-bookInfoTests-v1alpha3.sh
9e5e263a270637570f82c12ae7fba4cecde3be8a
link
/test e2e-bookInfoTests-envoyv2-v1alpha3

prow/e2e_pilotv2_auth_sds.sh
9e5e263a270637570f82c12ae7fba4cecde3be8a
link
/test istio_auth_sds_e2e

prow/e2e-bookInfoTests-trustdomain.sh
9e5e263a270637570f82c12ae7fba4cecde3be8a
link
/test e2e-bookInfoTests-trustdomain

prow/istio-integ-k8s-tests.sh
9e5e263a270637570f82c12ae7fba4cecde3be8a
link
/test istio-integ-k8s-tests

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: john-a-joyce, sdake
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: costinm
If they are not already assigned, you can assign the PR to them by writing /assign @costinm in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

tests/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

/retest

/test istio-pilot-e2e-envoyv2-v1alpha3

/test e2e-bookInfoTests-envoyv2-v1alpha3

/test e2e-bookInfoTests-trustdomain

/test istio_auth_sds_e2e

/test e2e-mixer-no_auth

/test istio-pilot-multicluster-e2e

/lgtm

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: hzxuzhonghu, john-a-joyce, sdake
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: costinm
If they are not already assigned, you can assign the PR to them by writing /assign @costinm in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

tests/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

/lgtm
Thank you!

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: howardjohn, hzxuzhonghu, john-a-joyce, sdake
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: costinm
If they are not already assigned, you can assign the PR to them by writing /assign @costinm in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

tests/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: howardjohn, hzxuzhonghu, john-a-joyce, nmittler, sdake
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

tests/OWNERS [nmittler]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@john-a-joyce: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-integ-k8s-tests.sh
9e5e263a270637570f82c12ae7fba4cecde3be8a
link
/test istio-integ-k8s-tests

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.


Fix crash when processing PostgreSQL packets in weird order

Do not completely reset protocol state after receiving ReadyForQuery packet. Instead, remember if we got ParseComplete or BindComplete before, and if so, reset their protocol state part.

Checklist

[ ] Change is covered by automated tests
[x] The coding guidelines are followed
[x] ~Public API has proper documentation in the Acra documentation site or has PR on documentation repository
with new changes~
[ ] CHANGELOG.md is updated (in case of notable or breaking changes)
[ ] CHANGELOG_DEV.md is updated
[x] ~Benchmark results are attached (if applicable)~
[x] ~Example projects and code samples are up-to-date (in case of API changes)~

shouldn't we use mutex anywhere?

shouldn't we use mutex anywhere?
mutexes should be used to synchronize access to shared objects. Here is data related to 2 connections (app <> acra, acra <> db), and handled by 2 goroutines. If 2 goroutines change/update same data - then we should. If only one of them touches data at same time - then we shouldn't. For example if we touch data related to client's side packets in goroutine that work with client side connection, then we can omit mutexes because of opposite goroutine will not touch same data/buffers/processes.


Update rest-client version to support >2.0.0

Versions of Ubuntu 18.04 will run into the following issue because OpenSSL is too new:
https://github.com/rest-client/rest-client/pull/573
/ruby/2.5.0/gems/rest-client-1.8.0/lib/restclient/request.rb:163:in `fetch': key not found: :ciphers (KeyError)

I've noticed this too on 18.04, when performing a HTTP request... Did you find a workaround @Zarthus I'm just playing around with a lib that uses rest-client so haven't dived too deep into the issue

@stakach My "workaround" was to stop depending on a library I didn't need.
I changed to rest-client because my use was relatively basic. https://github.com/Zarthus/lobby-utility-bot/commit/c95ed19a9e39a980f5baf071e8895ffd14cc1f7b


In new native interactive window, restarting the kernel does not clear imported modules

Environment data

VS Code version: 1.59.0
Jupyter Extension version (available under the Extensions sidebar): v2021.8.1195043623
Python Extension version (available under the Extensions sidebar): v2021.8.1105858891
OS (Windows | Mac | Linux distro) and version: Windows 10
Python and/or Anaconda version: Python 3.7.6
Type of virtual environment used (N/A | venv | virtualenv | conda | ...): virtualenv
Jupyter server running: Local

Expected behaviour
Restarting the kernel should clear all variables and imports
Actual behaviour
After restarting the kernel, the variables remain in displayed in the "variables" tab of jupyter. Querying them from the interactive window's command line results in the correct "name XX not defined".
However, imported modules are not reloaded
Steps to reproduce:
[NOTE: Self-contained, minimal reproducing code samples are extremely helpful and will expedite addressing your issue]

Create the following two scripts in the same folder:

test.py:
#%%
import test_fun as tf
#%%

a = 10
b = 20
# %%

c = tf.my_fun(a)
print(c)

test_fun.py:
import numpy as np

def my_fun(a):
    print('I have received ' + str(a))
    return 2*a

run test.py, notice the output is as expected. In passing, note that the variables are NOT present in the "variables" tab, but they appear if, having the tab open, some code is run through the Interactive Window command line.
make some modification to my_fun, for instance add another line like print('now I am printing an extra line').
Restart jupyter kernel by clicking on the "restart" button at the top of the window. Note that the old variables do not disappear from the "variables" tab, however querying them from the Interactive Window comman line results in an expected error as the variable is not in memory.
re-run  test.py, notice the new line is not being printed, which means the imported module is not reloaded.

Logs

Output for Jupyter in the Output panel (View→Output, change the drop-down the upper-right of the Output panel to Jupyter)

XXX

@filipporemonato Thanks for the detailed repro steps here. I do repro both the issue with the variables not showing up until code is run in the IW as well as the issue with variables not being cleared on a restart. However I did see the new line that I added being printed when added to run_test.py ('Extra line added is what I added). Are you sure that you are not seeing the line added from the file change?

@joyceerhl I think the variables not initially showing (+ not clearing on restart) might be a known issue already?

Variables not initially showing is tracked in https://github.com/microsoft/vscode-jupyter/issues/6993. Not clearing on restart is a bug, but I'll add that to #6993 since I should fix both of those issues at the same time.

Hei @IanMatthewHuff  thanks for checking this out. Good you could repro the variables showing/clearing. I'm unsure why you could not repro the module reload; this is what I see:

As you can see the output does not change after restarting the kernel.
This is how my_fun was before the restart:

And this is after the restart:

I also made sure the modified file was saved before running the import again, and also tried again by saving it before restarting the kernel.

@filipporemonato Do you happen to have jupyter.runStartupCommands configured to something in your user settings, and are you relying on that for module reload? If so, we're fixing an issue where the startup commands aren't rerun after restarting the kernel and this issue would be a dupe of https://github.com/microsoft/vscode-jupyter/issues/7016.

I am facing the same issue with restart kernel. Does not update the imported modules.

Hi @joyceerhl, some days ago there has been a small update of VS Code; now I have version 1.59.1 (was 1.59.0).
This update seems to have fixed the issue about modules not being reloaded; now I can see the changes I make in the imported functions pop up in the interactive window as expected.
If @yourPhysio could confirm, then we can consider this part resolved, and then this issue would become a dupe of  #6993 as you mentioned so we can close it.

Sounds like this issue has been fixed--please file a new issue if this is not working for you.


320 migrate v3 manifest

Pull origin

Sorry, I thought it was the other way around: I tried to use the github interface to pull from you (patgmiller) into my fork :/.


Can't read /etc/pihole/pihole-FTL.db

When pihole_adlist_tool I get the following output:
~/pihole_adlist_tool (master) --ϐ ./pihole_adlist_tool

  *** Pihole Adlist Tool 2.6.3 ***

   ++++++++ Info ++++++++

  [i]  PIHOLE_DOCKER: No
  [i]  PIHOLE_DNSMASQ_VERSION: v2.87
  [i]  SQLITE_VERSION: 3.39.2
  [i]  DAYS_REQUESTED: 30
  [i]  TOP: Not shown
  [i]  SORT_ORDER: id ASC
  [i]  UNIQUE: Not shown
  [i]  REGEX_MODE: Disabled

   ++++++++++++++++++++++

  [i]  Warning: You requested to analyze the last 30 day(s) (starting from 14.09.2022	19:56:48),
       but last query is from 31.12.1969	17:00:00
  [i]  Nothing to do here. Exiting

Running
pihole-FTL sqlite3 "file:/etc/pihole/pihole-FTL.db" "SELECT MIN(timestamp) FROM queries;"

or
pihole-FTL sqlite3 "file:/etc/pihole/pihole-FTL.db" "SELECT MAX(timestamp) FROM queries;"

by itself returns nothing, so I believe that there's an issue with the command getting data from the db.
Output of pihole_adlist_tool -v
~/pihole_adlist_tool (master) --ϐ ./pihole_adlist_tool -v
Pihole Adlist Tool v2.6.3

so I believe that there's an issue with the command getting data from the db.

There is no issue with the command, there is an issue with your long-term database.  That's why it says "Can't read /etc/pihole/pihole-FTL.db"
Please open a help topic on Pi-hole's discourse forum and provide a debug token there.
https://discourse.pi-hole.net/c/bugs-problems-issues/11

Nowhere does it say "Can't read /etc/pihole/pihole-FTL.db", it doesn't return any data for the queries used.

It says so in your issue title.

But anyway, this is not an issue with the tool, but with your database.

Cool, thanks for your help


Update: Compatibility with Home Assistant 2023.05.0b6

Fixes https://github.com/JurajNyiri/HomeAssistant-Tapo-Control/issues/325


Add workaround to fix #929

Add workaround to fix #929 by manually setting the display to block inside the complete animation callback. I tried to find all .show() functions that might have been affected and add the fix.
I would like to ask what code beautifier to use in order to have consistency with the other contributors.

Coverage increased (+0.04%) to 40.786% when pulling dde76074f8588ef2303d5d1c1c254f4a2dc7a01b on SirmaITT:bugfix/ff_iframe_issue#929 into 76a35e7c179f31fdc4aad822c9a61b3f20348e3c on IIIF:release2.1.

@radpet Can you resubmit your PR without all of the whitespace changes?  I can't see what changes you made.

Coverage decreased (-0.04%) to 40.706% when pulling 45c4bf0019527d7ed3cdeb5e83ecb86e7d9172a4 on SirmaITT:bugfix/ff_iframe_issue#929 into 76a35e7c179f31fdc4aad822c9a61b3f20348e3c on IIIF:release2.1.

Coverage decreased (-0.05%) to 40.692% when pulling 3d1b14eee1fb3aa80bf3d84011a4788b3e5454f0 on SirmaITT:bugfix/ff_iframe_issue#929 into 76a35e7c179f31fdc4aad822c9a61b3f20348e3c on IIIF:release2.1.

Coverage decreased (-0.006%) to 40.736% when pulling 125317c810a6a2a0f113121c2bf9799b2557c4d7 on SirmaITT:bugfix/ff_iframe_issue#929 into 76a35e7c179f31fdc4aad822c9a61b3f20348e3c on IIIF:release2.1.

Coverage decreased (-0.05%) to 40.692% when pulling 3d1b14eee1fb3aa80bf3d84011a4788b3e5454f0 on SirmaITT:bugfix/ff_iframe_issue#929 into 76a35e7c179f31fdc4aad822c9a61b3f20348e3c on IIIF:release2.1.

Coverage decreased (-0.04%) to 40.706% when pulling 5d4c8cbb13e396807373eb1973c764f1c5ba770e on SirmaITT:bugfix/ff_iframe_issue#929 into 76a35e7c179f31fdc4aad822c9a61b3f20348e3c on IIIF:release2.1.

Coverage increased (+0.5%) to 41.207% when pulling 18b2824b3fc89cf101b41ccf9423e6f64b2f8590 on SirmaITT:bugfix/ff_iframe_issue#929 into 76a35e7c179f31fdc4aad822c9a61b3f20348e3c on IIIF:release2.1.


Offline transaction - missing transaction details when cosignature imported using Payload

Steps:

Open offline transactions
"Cosign Transaction" tab
Import cosignature by payload

Results: Transaction details are not presented and we are going to transaction signing.
Expected result:
Present transaction details as is done for import payload by QR:

@AdriaCarrera i'm getting error while extracting files from zip file , if i skip those errors that is causing issues while running the npm run dev code , please have a look

This issue is retested and passed, can be merged to main branch. Steps I followed 1. create multisig accounts 2. go to offline transactions,select cosign transaction,import the QR code, click continue , then close the pop up, you will get sign transaction 3.enter the password and the transaction is signed

transaction was signed in by importing the QR code online

I tried with the payload and the transaction was signed successfully,

while pasting the payload , first time not getting teh pop up but if I deete it go back to login page and come back to offline transaction and paste the same code , pop up of teh transaction appears

i used the below payload F8000000000000004402C778AB7380D0E8AE802A35D3324E484A72426B5F1702E9703E1720B2423B3E08980805A9B28EE7ECC8E26CAF6F7A86E7ACA408338066DF568DAA3918BB0932D3CAE58228B217F247B735D922CF477BC161042D2B69515A3BA2ACFB9D54BC000000000198414280402F0100000000704F705D0A0000005451AAEF3D419DCF62B3135D69BA2E553FF8D69E1295FC090D97A5585ADCCF4D5000000000000000500000000000000032D3CAE58228B217F247B735D922CF477BC161042D2B69515A3BA2ACFB9D54BC0000000001985541010101000000000098270851CACD47A2D5FC6B86B8AF584D0487A616FCF44684

Tested and can be closed


Name steps

Applied mkpr on .github/workflows/ci.yml
/Users/markus/bin/rename_step.pl

Pull Request Test Coverage Report for Build<PHONE_NUMBER>3
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 99.219%

Totals

Change from base Build<PHONE_NUMBER>8:
0.0%

Covered Lines:
109

Relevant Lines:
109

💛  - Coveralls


textadept: 10.8 -> 11.3

Description of changes

Textadept was split into textadept and textadept11 years ago to make the beta version of Textadept 11 available. Textadept v11 has long since stabilized, and is the only maintained branch of the project, so this change replaces textadept with the most recent version that was already packages in textadept11, and removes the defunct package textadept11.
Closes #175768
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[x] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
22.11 Release Notes (or backporting 22.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

Maybe create an alias (possibly with throw)?


Support configuration of .openzeppelin directory path

Our organization uses Hardhat for deployment across multiple private chains, and configures the paths of Hardhat's inputs and outputs (https://hardhat.org/hardhat-runner/docs/config#path-configuration) into folders not necessarily in the project's directory.
Currently the .openzeppelin directory is created in the root of where the oz-upgrades scripts are called from, at least when using the Hardhat plugin. This is due to the openZeppelin-upgrades directory being hardcoded as '.openzeppelin' in the core package's file ./packages/core/src/manifest.ts, and that string is defined as the .openzeppelin path in the manifest.ts constructor.
I'd like to have optional configuration of the manifest directory path, with a default to the current manifestDir string, '.openzeppelin', similar to how Hardhat handles configuration of its paths.
A possible solution would be to pass an optional parameter into the manifest.ts constructor that defines the manifest path for the this.fallbackFile and this.file variables, and falls back to the default path if the parameter is not passed/null. This passing of path data can be similar to how the manifest.ts constructor currently takes the chainId, which comes from the deployData object defined in the plugin packages. In the Hardhat plugin, when creating the deployData object in getDeployData function, another const can be added that reads the hre object for a path defined in the hardhat.config file, such as 'hre.config.ozUpgrades.manifestPath'. I am assuming something similar can be done with the Truffle plugin.

You included a lot of details about how this would be implemented, but we should focus on what this is going to look like for the end-user.
We currently don't have any global configuration (in hardhat.config.js) so I'd try to avoid that. Would it be sufficient to include it as an option in functions like deployProxy? deployProxy(..., { ..., manifest: 'path/to/manifest.json' })

My initial thought on the hardhat.config file was because that's how I'm use to using other hardhat plugins. I guess I let my tool bias drive the above 😅
Setting an option in a config to me means it only has to be set once, though I agree that if the other existing oz-upgrades configurations are tied to function calls then best to stick with that pattern for consistency. The user will need to ensure they pass the optional parameter for each deploy/upgrade function. Keeping it as a function's optional parameter will probably be easier to manage across multiple dev tools as well (HardHat, Truffle, future tools).

@ericglau what's your opinion on this?

I think it makes sense to introduce a global configuration for this scenario.  The existing options for function calls are specific to those functions, but the manifest path is something that should be common between all functions.  Having the manifest path as a function option could cause problems if users forget to specify the custom path in some functions (for example, that may lead to redeploying an implementation unnecessarily, or a proxy being registered in the wrong manifest location).
In terms of how to specify the global config, we could use the native configuration method for each dev environment (Hardhat or Truffle config file as suggested above) and/or fallback to look for an environment variable.  The environment variable fallback could possibly help with supporting this in future tools.  @frangio, any thoughts on the environment variable approach?

Environment variable as fallback sounds good to me.


5 separate help topics

@Hyperkid123 @ryelo Will you please review the new help topics and let me know whether the setup is correct.
These are the same old topics but it was decided to store them separately, hence 5 new subdirectories.
Thank you.
Have a nice upcoming weekend.

Thank you a lot for merging @Hyperkid123 .


复制了最新的UnityGameFramework也还是报错

Assets/GameMain/Scripts/Editor/StarForceBuildEventHandler.cs(9,25):
error CS0535: `StarForce.Editor.StarForceBuildEventHandler' does not implement interface member `UnityGameFramework.Editor.AssetBundleTools.IBuildEventHandler.PreProcessBuildAll(string, string, string, string, int, string, UnityEditor.BuildAssetBundleOptions, bool, string, string, string, string, string, string)'

还是有报错啊

此问题已修正。


Fix default auth and 'AzureTenantId' to persist and not reset on selection event

This PR fixes #21280, #21281, #21255 and other related issues.

Default auth is reset to empty string.
Issue in connectionWidget selection event led to reseting 'AzureTenantId' on selection event, which shouldn't have been done as azureTenantId itself is used to trigger selection event (here) and it should only be set with received connection Info.

Event triggers with cached model caused this property to lose its actual value.

+Cleaned up azurecore to not move around tenant Id as its not needed.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

4 of 8 (50.0%)  changed or added relevant lines in 7 files are covered.
4 unchanged lines in 1 file lost coverage.
Overall coverage decreased (-0.009%) to 42.042%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

extensions/azurecore/src/azureResource/tree/flatTreeProvider.ts
0
1
0.0%

src/sql/workbench/services/connection/browser/connectionWidget.ts
0
1
0.0%

extensions/azurecore/src/azureResource/tree/flatAccountTreeNode.ts
0
2
0.0%

Files with Coverage Reduction
New Missed Lines
%

extensions/notebook/src/jupyter/serverInstance.ts
4
75.5%

Totals

Change from base Build<PHONE_NUMBER>:
-0.009%

Covered Lines:
28810

Relevant Lines:
63679

💛  - Coveralls


Error occurred while enabling AntiHaxerman

To Reproduce
Steps to reproduce the behavior:

Upload to plugins folder
Start the server
See error

Expected behavior
https://pastebin.com/diVYGENT
Environement (please complete the following information):

OS: Ubuntu
Plugin Version 4.0.2
Server Version PandaSpigot 1.8.8

PandaSpigot is a Paper fork

It's a full log, just start server and get error

Like I said please try vanilla paper and please send the full server logs.

developer is strange


Specify encoding (and throw in fancy accents)

While adding a playful update to "internationalise" the spelling of smorgasbord, I realised that I didn't know what encoding the pages were. Just to show willing, this PR adds an explicit UTF-8 charset header to each and includes the smorgasbord update.
AFAICT, none of the other pages needed re-encoding as such; I've merely added the explicit header.

The pages are served with: Content-Type:text/html; charset=utf-8
So this a duplication / unneeded meta?
Kudos for smörgåsbord though...

I guessed as much; problem is that contributors wanting to update text
don't know this... Don't feel strongly, but so long as it doesn't cause
a problem, why not leave it in?
TJG
On 20/03/2015 09:25, Stephen Hawkes wrote:

The pages are served with: Content-Type:text/html; charset=utf-8
So this a duplication / unneeded meta?
Kudos for smörgåsbord though...
—
Reply to this email directly or view it on GitHub
https://github.com/PyconUK/pyconuk.github.io/pull/2#issuecomment-83966732.

@tjguk Hey Tim - could you please send PRs from a feature branch in future please.

Certainly. I'm a relative naïf when it comes to github collaboration,
I'm afraid!


Text Email sending fails with Array to String conversion notice

First of all, thank you so much for supporting PHP7 for this legacy beast!
Today I came across a problem, where I get the following notice:
message: "Array to string conversion"
code: 8
file: "/var/www/html/vendor/shardj/zf1-future/library/Zend/Mime.php"
line: 472
severity: E_NOTICE

when I try to send an email without HTML content - just Text and one attachment.
I had a look around the code and on that line it looks like the str_replace function is used incorrectly.
    /**
     * Converts a string into quoted printable format.
     *
     * @param  string $str
     * @return string
     */
    private static function _encodeQuotedPrintable($str)
    {
        $str = str_replace(
            ['=', self::$qpKeys],
            ['=3D', self::$qpReplaceValues],
            $str);

        return rtrim($str);
    }

qpKeys and qpRelaceValues (both arrays) should be spread in order for it to work as expected in future PHP versions.
We could use the spread operator, but since you are aiming min 7.0 support, another means should be used. I will create a PR soon.

Yeah looks like it's just an array merge needed between ['='] and self::$qpKeys and the same for ['=3D'] and self::$qpReplaceValues for params 1 and 2 respectively. I'll wait for your PR

Running into the same issue. PR LGTM. Anything I can help get this released?

@arueckauer release-1.18.8 has this out


provide a more advanced, dedicated 2D view of any section (lock a section, work in that locked section)

siibra-explorer can now open dzi, and reset view to plane native to the 2D view.
I will close this issue as complete for now.


small typo: rctd to rtcd

Summary

Just fixing a small typo. The added line feed at the end was added by the GitHub interface (sighs), I'll fix the commit soon.

Hello @nachtjasmin,
Thanks for your pull request! A Core Committer will review your pull request soon. For code contributions, you can learn more about the review process here.
Per the Mattermost Contribution Guide, we need to add you to the list of approved contributors for the Mattermost project.
Please help complete the Mattermost contribution license agreement?
Once you have signed the CLA, please comment with /check-cla and confirm that the CLA check is green.
This is a standard procedure for many open source projects.
Please let us know if you have any questions.
We are very happy to have you join our growing community! If you're not yet a member, please consider joining our Contributors community channel to meet other contributors and discuss new opportunities with the core team.

/check-cla


Incorrect test for whether a job has finished

If a job is canceled, then travis-after-all hangs forever waiting for the job to complete.

@mernst Thanks for opening this issue, however, this seems like a duplicate of #13.


Clearing input field does not reset date value

When a date is has been selected with the date picker and I manually clear the input field, the date is not reset. If I bound the datepicker value to a property on a model, the property still has the selected date as value (although the input field is empty).
Resetting the property with the 'clear'-button works correctly.

This might be related to the way bootstrap-datepicker handles changes in the input field. Will take a look.

Thanks!
Currently I wrap your component in an extra component and use
inputChanged: Ember.on('input', function () {
  //check input and reset date
})

as workaround.

Any chance that PR might be merged? I'm dealing with this issue at the moment as well.

@soulim Are there any updates on this issue or any reasons not to merge PR 35?

Great, thanks! And thanks for the great component.

Just merged #35. Sorry for delay. I didn't have enough time to give more love to this project.

Thank you for being awesome and patient!


CQF expression extension not working with html tags

Describe the bug
When we put html tags in cqf-expression extension, the html tags is not working.
This is used in Questionnaire.item.text, to make that text bold, while also allowing that text dynamic by using cqf-expression extension.
Component
SDC library
To Reproduce
"Congrats!" should be bold, w the following sample.
{
  "_text": {
    "extension": [
      {
        "url": "http://hl7.org/fhir/StructureDefinition/cqf-expression",
        "valueExpression": {
          "language": "text/fhirpath",
          "expression": "<b>Congrats!</b> you have %variable-1 symptoms"
        }
      }
    ]
  }
}

Expected behavior
CQF expression should work with html tags, therefore making the text bold.
Screenshots
N/A
Smartphone (please complete the following information):

Device: [e.g. Pixel4a emulator]
Android version: [e.g. Settings -> About phone -> Android version]
Build number: [e.g. Settings -> About phone -> Build number]
Version [e.g. 22]

Additional context
N/A
Would you like to work on the issue?
N/A

we probably should use Spanned for this

I will take a look, thanks!

Thanks @santosh-pingle :D


07/23/2018 05:56 : Create Pull Request for branch master -> prTesting1_2018072305

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

split/updateTestRef1.md
:white_check_mark:Succeeded

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


Fix #4

Return empty queryset when using filter method if hashid value does not exists.

good work! thank you!


[14.0] ISPN-14876 Return proper value for context path property

https://issues.redhat.com/browse/ISPN-14876

Rebased to include e29865c8b80954aa893aa9000314c3396e9a8436


Tools used to inspect a website when creating phishlets

I am learning how to create phishlets for this tool but I am not sure what's the best tool to use for finding the right cookie to captcha.
Thanks in advance

You can use Chrome's web inspector or Burp proxy for that to inspect traffic.

@kgretzky Thanks


Model weights

Hi, thank you for this exciting work. I want to try it out, but the link to huggingface doesn't work and I can't find the model weights.

Sorry for the delay, we are still preparing the final hosts of the weight. A temporary hugging face link is now available, hope it can be helpful for you!


Fix key for glitchtip-dsn Vault secret

Description

Vault secret for glitchtip-dsn was using the wrong key value, causing the edge-api-service pod to fail to start.
FIXES:
Type of change
What is it?

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Documentation update
[ ] Tests update
[ ] Refactor

Codecov Report
Base: 53.91% // Head: 53.88% // Decreases project coverage by -0.04% :warning:

Coverage data is based on head (8205b12) compared to base (0219f75).
 Consider uploading reports for the commit 936b47d to get more accurate results

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1897      +/-   ##
==========================================
- Coverage   53.91%   53.88%   -0.04%
==========================================
  Files          70       70
  Lines        9932     9932
==========================================
- Hits         5355     5352       -3
- Misses       4104     4106       +2
- Partials      473      474       +1

Impacted Files
Coverage Δ

pkg/services/devices.go
50.79% <0.00%> (-0.32%)
:arrow_down:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

On line 24, try this:
    dsn: ${GLITCHTIP_DSN}


Move observability components from nginx-ingress-controller to Istio

How to categorize this PR?

/area logging
/area monitoring
/area networking
/kind enhancement
What this PR does / why we need it:
Previous to this pull request kube-apiserver was exposed via istio while the observability components used nginx-ingress instead. This is unified by moving the observability components alertmanager, plutono, prometheus and vali to istio.
The observability components are exposed similarly to kube-apiserver using the standard https port (443). However, unlike kube-apiserver TLS is terminated and authentication is performed by istio for the observability components. vali is the exception in terms of authentication as it continues to use kube-rbac-proxy for this.
To perform a smooth migration, all components will temporarily get their own DNS records. When everything is migrated the wildcard DNS record can be moved to istio and the individual records can be removed again.
Similar to the current solution, which does not take exposure classes or availability zones into account, this change will always expose the observability components via the default istio ingress gateway.
Which issue(s) this PR fixes:
Part of #7232
Special notes for your reviewer:
This pull request is not yet complete. vali is missing and the communication between the components has not been adapted, yet.
Please note that the other part to closing #7232, i.e. the exposure of kube-apiserver via Ingress resource will be implemented in a separate pull request.
Release note:

The observability components `alertmanager`, `plutono`, `prometheus` and `vali` are now exposed via `istio` instead of `nginx-ingress`. This results in a change in IP address for their domain name.

/cc @istvanballok @rickardsjp @nickytd

/assign

/assign

/close


Resolve the Testing Farm on stage

Testing Farm has been allowed on the firewall, only propose-downstream and pull-from-upstream may be affected.

only propose-downstream and pull-from-upstream may be affected

shouldn't this be stated in the text? It now mentions only that TF is no longer a problem.

It's mentioned in the text above the “Known Issues”:

We have moved our staging instance to another OpenShift cluster which may result in some jobs failing.
This issue should mainly affect jobs that involve syncing to the dist-git, namely:

propose-downstream
pull-from-upstream
In case you are using our staging instance and you hit any issues when running propose-downstream or pull-from-upstream, please let us know.


Fix verbosity for virt-controller

Special notes for your reviewer:
Release note:
None

/approve

is there a way to unit test this?

I don't believe so. (Sorry for the late reply)

/lgtm

/retest


Forecast missing precipitation_probability

Describe the bug
I am possibly doing something wrong but I am unable to see a precipitation_probability attribute. It also is not an option when using a weather card and attempting to select it as secondary information to display.
To Reproduce
Steps to reproduce the behavior:

Inspect the state of the weather entity and see the missing attr

Expected behavior

See precipitation_probability in attributes

Here is what my attributes look like.
temperature: 68
dew_point: 45
temperature_unit: °F
humidity: 42
pressure: 764.09
pressure_unit: mmHg
wind_bearing: 51
wind_gust_speed: 6.71
wind_speed: 2.24
wind_speed_unit: mph
visibility_unit: mi
precipitation_unit: in
attribution: Weather data delivered by WeatherFlow
friendly_name: Forecast Weather Station
supported_features: 3

What you are showing above is not the forecast, but the Current Conditions. For some reason Precipitation is not a part of the specs for Current Condition but it is present in daily forecast. To retrieve the value in to a sensor you could create a triggered template sensor like the below. This will update every full hour, and read the precipitation probability for the current day.
Change the trigger to whatever you want, just note that first time you see data after you create it with the below setting, is on the next full hour.
- trigger:
    - platform: time_pattern
      hours: /1
  action:
    - service: weather.get_forecasts
      target:
        entity_id: weather.forecast_weather_station
      data:
        type: daily
      response_variable: daily_forecast
  sensor:
    - name: Precipitation Probability
      unique_id: 5dcaa215-3cfd-4cf5-8cba-818227a21321
      icon: mdi:weather-rainy
      unit_of_measurement: "%"
      state: >
        {% set forecast = daily_forecast['weather.forecast_weather_station']['forecast'] %}
        {{ forecast[0].precipitation_probability | int  }}

Thank you! That did the trick!


issue#127 Alert while logout

Added an Alert Pop out at Navbar.js and DashBoardNavbar.js logout buttons
which when pressed gives the alert confirmation pop out when press OK the the handlelogout function removes the token and takes the user back to login as it was programmed.
the flow doesn't do anything if the user select Cancel option from the alert pop up!
modified files :-
" handleLogout" function in both src/components/Navbar.js  &&  src/components/DashboardNavbar.js

Can you attach a screenshot of dialog please?


Upgrade to Docusaurus v3

Not urgent, just filing for tracking.
Docusaurus v3 was released last month and v2 is now in maintenance mode. They recommend upgrading to v3 by January 2024.
The upgrade guide seems mostly straight-forward.
I started making the changes just to get a sense of scope. Right now the primary blocker is the openapi plugin, which does have an approved (though not yet merged) PR for v3 support.
Once that is merged, hopefully this should be an easy lift.

Quick update here: docusaurus has announced v2.x is no longer supported, released 3.0.1. The openapi plugin has also been updated, so that's no longer a blocker.
At this point, the only blocker is actual Markdown changes that break because of the switch from MDX1 to MDX3. This is in line with what they say: https://docusaurus.io/docs/migration/v3

The main breaking change is the upgrade from MDX v1 to MDX v3

Specifically, a bunch of stuff in _commands.md now breaks due to the problems described here: https://docusaurus.io/docs/migration/v3#common-mdx-problems
Basically, bad usages of { and < that now need to be escaped properly.
Addressing this properly likely requires an update to stacks.js as well, I'll see if I can generate a PR easily. FYI @janniks


Use oldHeaders.count when reserving capacity in HTTPFields

Fixes use of reserveCapacity on HTTPFields
Motivation:
Speed.
Modifications:

Result:
Less reallocs.

@swift-server-bot add to allowlist


Allow removing optional related value

Describe the bug
When editing a document that contains an optional relation to another collection, it is impossible to un-select a relation that would have been previously selected : the dropdown has no clear button or empty value option
To Reproduce
Create a collection with a relation to another one.
Expected behavior
If the relation is optional, we should be able to clear the value

@bluelibs/x-ui-admin 1.4.8 released


client side and ci/cd

[x] 22 Back to the Client
[x] 23 CI-CD

starting client side

client side implementation finished

CI/CD pipeline finished without deployment


Exclude SimilarValueTool By Default

This PR excludes SimilarValueTool by default, if vector_store_dir is not configured. The change is made to ensure that we do not store vector db in-memory, as this could cause OOM.

@asl3 Seems there is test failure.


Update media so it expects to find jquery in the right place.

@s-block This PR updates NestedInline.media() so that it accords with the placement of jquery in a vendor directory in django 1.9+.
Testing
I tested an admin page using a NestedInline with and without this change.
With this change
Everything is fine. No network errors or 404s.

Without this change
The browser attempts to download jquery, but can't find it.

Thanks for writing this library! We've found it very useful.

I got duplicate jquery import, but I guess it is not a big problem.

If I understand correctly, the jquery import is superfluous since it's included on the changeform template, but I'd figured you were including it for a good reason. If that's not the case, then I think it makes sense to remove it altogether.

Could we get this merged please?


More description on generating CMAC license

I was super confused about this, so I wrote it out so that others could get an advantage from this.

Thanks


Getting Pointer being free is not allocated error in convex-local-backend

Hi all, right now I am experiencing this error while running convex-local-backend.

Any idea what happened?

Same error within 1 minute! Go to issues #240 , same error there.

Yeah let's just track it in #240