text:
[SPARK-48861][SQL] Enable shuffle file removal/skipMigration for all SQL executions

This PR follows https://github.com/apache/spark/pull/45930 and https://github.com/apache/spark/pull/46302 (which is open as of the creation of this PR) to enable shuffle file cleanup for all SQL executions, not just Spark Connect.
The prior PR https://github.com/apache/spark/pull/45930 introduces two new configs: spark.sql.shuffleDependency.skipMigration.enabled and spark.sql.shuffleDependency.fileCleanup.enabled. These two configs are not specifically namespaced to Spark Connect and I'd like to make sure we can use them from all QueryExecutions. Before this PR, only Spark Connect could enable it.
My change is to move the check for shuffleCleanupMode inside of QueryExecution, instead of having that be passed to this class in the constructor. I also am explicitly turning on these features in the tests, rather than using Utils.isTesting.
I would love to hear any concerns on why we shouldn't do this or what testing you want to see. I have run Standalone tests (note I needed https://github.com/apache/spark/pull/46302) and can run other tests if required or can code them.

@bozhang2820 @cloud-fan fyi

Hi @abellina, we tried this before but found that queries would fail, especially when DataFrame objects are reused. You can find test failures when you change the default value of the config back to Utils.isTesting.

I agree to expose this feature to all query executions, so that users can benefit from it if they know they won't execute a DataFrame twice. However, there are certain internal executions that we should not enable shuffle cleanup, such as cached DataFrame execution. It's hard to identify all these places, and I think it's better to limit the entry points to enable shuffle cleanup. Spark Connect is one of them, thriftserver can be another.

I agree to expose this feature to all query executions

I agree, I think there are a bunch of cases cleaning the shuffle is very useful.   We can go investigate options more.
Perhaps there is a way for to only be enabled for external calls but anything internally calling like caching wouldn't clean up.

authors: abellina bozhang2820 cloud-fan tgravescs


text:
[SPARKR] [DOCS] Add documentation for RStudio use case

I added a section on how to launch SparkR from RStudio to sparkr.md as it is easier for Windows users to do this rather than launch a shell.
cc @davies

Merged build triggered.

Merged build started.

Test build #35348 has started for   PR 6916 at commit 324fe60.

Test build #35348 has finished for   PR 6916 at commit 324fe60.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

@holdenk could you also update the documentation with your PR #6928 ? Then I can close this PR as we can just use the new API in 1.4.1 and future releases.

Sure, I can do that.

source: gharchive/pull-request

authors: AmplabJenkins SparkQA holdenk shivaram

repo: apache/spark

license_type: permissive

license_source: github-api


text:
[STREAMING][FLAKY-TEST] Catch execution context race condition in FileBasedWriteAheadLog.close()

There is a race condition in FileBasedWriteAheadLog.close(), where if delete's of old log files are in progress, the write ahead log may close, and result in a RejectedExecutionException. This is okay, and should be handled gracefully.
Example test failures:
https://amplab.cs.berkeley.edu/jenkins/job/Spark-1.6-SBT/AMPLAB_JENKINS_BUILD_PROFILE=hadoop1.0,label=spark-test/95/testReport/junit/org.apache.spark.streaming.util/BatchedWriteAheadLogWithCloseFileAfterWriteSuite/BatchedWriteAheadLog___clean_old_logs/
The reason the test fails is in afterEach, writeAheadLog.close is called, and there may still be async deletes in flight.
@tdas @zsxwing

Test build #46654 has started for PR 9953 at commit 890e6dc.

LGTM. @zsxwing what do you think?

Test build #46654 has finished for PR 9953 at commit 890e6dc.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/46654/
Test PASSed.

Merged build finished. Test PASSed.

LGTM

Thanks! Merging to master and 1.6

@brkyvz no JIRA for this one?

@zsxwing No. We could create one though if we like

authors: AmplabJenkins SparkQA brkyvz tdas zsxwing


text:
Remove unused riak container in to-integration-tests - issue: 5946

What does this PR (Pull Request) do?

[x] This PR fixes #5946

Which Traffic Control components are affected by this PR?

CI tests

What is the best way to verify this PR?

If this is a bug fix, what versions of Traffic Control are affected?

The following criteria are ALL met by this PR

[x] This PR includes tests
[x] This PR does not require necessary documentation updates
[x] This PR includes No necessary changes to CHANGELOG.md
[x] This PR includes any and all required license headers
[x] This PR DOES NOT FIX A SERIOUS SECURITY VULNERABILITY (see the Apache Software Foundation's security guidelines for details)

Additional Information

PR is trying to merge old commits as well. Looking into getting those removed.

In addition to removing the Riak container, I think we'll have to also ensure that the Postgres Traffic Vault backend is initialized and configured properly. Otherwise, the tests won't have a TV backend to use.

authors: bueale rawlinp

repo: apache/trafficcontrol


text:
Fix double do_io_close in HttpTunnel::chain_abort_all()

A state machine can not access the VConnectuion or any returned
VIOs after calling do_io_close().
The TVC maybe already destroyed while the 2nd close on TransformVC,
this bug may cause TransformVC crash.

RAT check successful! https://ci.trafficserver.apache.org/job/RAT-github/375/

clang format successful! https://ci.trafficserver.apache.org/job/clang-format-github/363/

Intel CC build successful! https://ci.trafficserver.apache.org/job/icc-github/488/

AU check successful! https://ci.trafficserver.apache.org/job/autest-github/359/

Linux build successful! https://ci.trafficserver.apache.org/job/linux-github/1950/

clang-analyzer build successful! https://ci.trafficserver.apache.org/job/clang-analyzer-github/621/

Cherry picked to 7.1.x, thanks Oknet!

Do we want to revert this again, or try to fix it?

@zwoop please revert the PR from 7.1.x and master.
The "double do_io_close()" bug stills here and can not be resolved in chain_about_all().
Since the vc->alive == false is not means the vc was closed already.

@zwoop  Can I consider the Http1ClientSession::do_io_close() has the same requirement as VConnection::do_io_close() ?
"Likeswise, the state machine must not access the VConnection or any VIOs obtained from it after calling this method."
source: I_VConnection.h
252   /**
253     Indicate that the VConnection is no longer needed.
254
255     Once the state machine has finished using this VConnection, it
256     must call this function to indicate that the VConnection can
257     be deallocated.  After a close has been called, the VConnection
258     and underlying processor must not send any more events related
259     to this VConnection to the state machine. Likeswise, the state
260     machine must not access the VConnection or any VIOs obtained
261     from it after calling this method.
262
263     @param lerrno indicates where a close is a normal close or an
264       abort. The difference between a normal close and an abort
265       depends on the underlying type of the VConnection.
266
267   */
268   virtual void do_io_close(int lerrno = -1) = 0;

There are some mistaken in HttpTunnel,
HttpTunnel::chain_abort_all(HttpTunnelProducer *p)
1453 void
1454 HttpTunnel::chain_abort_all(HttpTunnelProducer *p)
1455 {
1456   HttpTunnelConsumer *c = p->consumer_list.head;
1457
1458   while (c) {
1459     if (c->alive) {
1460       c->alive     = false;
1461       c->write_vio = nullptr;
1462       c->vc->do_io_close(EHTTP_ERROR);   // -------> do_io_close() but did not set c->vc = nullptr
1463       update_stats_after_abort(c->vc_type);
1464     }
....
1486     p->read_vio = nullptr;
1487     p->vc->do_io_close(EHTTP_ERROR);   // -------> do_io_close() but did not set p->vc = nullptr
1488     update_stats_after_abort(p->vc_type);
1489   }
1490 }

HttpTunnel::close_vc(HttpTunnelProducer *p) and HttpTunnel::close_vc(HttpTunnelConsumer *c)
1587 void
1588 HttpTunnel::close_vc(HttpTunnelProducer *p)
1589 {
1590   ink_assert(p->alive == false);
1591   HttpTunnelConsumer *c = p->self_consumer;
1592
1593   if (c && c->alive) {
1594     c->alive = false;
1595     if (c->write_vio) {
1596       c->bytes_written = c->write_vio->ndone;
1597     }
1598   }
1599
1600   p->vc->do_io_close();   // -------> do_io_close() but did not set p->vc = nullptr,  p->bytes_read = p->read_vio->ndone;
1601 }

I'm not sure to be honest, this is not really my area of expertise :-/. How do we want to proceed with this? The 7.1.x branch is not usable as it is now, so we have to do something (it crashes every 10 minutes on Docs / CI).

please revert this commit.
The double do_io_close bug still here and  can not be fixed easily.
I will show you a new patch to test on docs before push a PR.
Oknet xu
发自我的 iPhone

在 2017年5月8日，23:27，Leif Hedstrom notifications@github.com 写道：
I'm not sure to be honest, this is not really my area of expertise :-/. How do we want to proceed with this? The 7.1.x branch is not usable as it is now, so we have to do something (it crashes every 10 minutes on Docs / CI).
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub, or mute the thread.

authors: atsci oknet zwoop

repo: apache/trafficserver


text:
Changed the Warning messages to Debug for POST redirect on buffer limits

I was seeing about 20 of these warning per second in production on 8.0.0 RC0

I am going to keep the warnings since the POSTs fail to the client.  It would be good to have a feature to disable buffering of POSTs for follow redirect.


text:
[Unity][Tracking Issue] In-place operations

Per the discussion on in-place updates, this is a tracking issue to discuss the steps and implementation details.

[x] Implement a basic version of the call_tir_inplace operator. This will handle the "simple case" described in the discussion thread, where the input tensor must be at least large enough to hold the desired output. At this stage, we will not handle memory planning for the cases where the input tensor is too small to hold the output (thus requiring the memory planner to ensure that the underlying storage is large enough).
[ ] Implement a conservative alias analysis to ensure that candidates for in-place operations are not aliased. We may also need to implement special operators to assert that values are not aliased or assert that a given PackedCall does not create aliases.
[ ] Implement a liveness analysis to determine that candidates for an in-place operation are not live later in the program.
[ ] Implement a pass that uses the alias and liveness analyses to identify candidates for in-place operations and replaces them with call_tir_inplace invocations. At this stage, the memory planner should also be modified to handle cases where the input tensor needs a larger underlying storage.

cc @quic-sanirudh

@tqchen A question about implementing one of the relatively simple cases, an in-place operation where the result is smaller than the input. I discussed with @MasterJH5574 and we weren't entirely sure about how this should work.
Let's suppose we have a call out = call_tir_inplace(some_func, (t1,), return_shape), where return_shape is smaller (in at least one dimension) than t1. out will be treated as a tensor of the smaller shape (return_shape), but will in reality be stored in the same place as t1. @MasterJH5574 points out that slicing is an example where this could arise.
The question is, do we need to have any special handling in the memory planner for this case? Would Relax's runtime treat out as being of t1's shape even though it's supposed to be smaller? Where might we need to make changes to handle this case? I could imagine some difficulties potentially arising with stride, layout, etc.
(For now, I will implement the scenario where the output shape matches the input shape exactly.)

Alternative approach suggested by @tqchen and @psrivas2: Consider dataflow blocks only. This would have the advantage of avoiding a whole-program analysis for liveness and aliases and would be a large simplification due to not having to handle control flow, but the risk would be that the alias analysis would have to be overly conservative since any value that comes from outside the dataflow block would have to be treated as potentially an alias. This is worth trying on a real example (say, an excerpt from an LLM). If these very conservative versions of the analysis turn out to be sufficient, then that would be a reasonable starting point.

source: gharchive/issue

repo: apache/tvm


text:
[ZEPPELIN-1233]  Support Redis interpreter

What is this PR for?
Support Redis interpreter
What type of PR is it?
Feature
Todos

[ ] - Support Redis Cluster

What is the Jira issue?

https://issues.apache.org/jira/browse/ZEPPELIN-1233

How should this be tested?
Outline the steps to test the PR here.
Screenshots (if appropriate)
Questions:

Does the licenses files need update?
Is there breaking changes for older versions?
Does this needs documentation?

Hi - thank you for your contribution. Could you see the list of steps here:
https://zeppelin.apache.org/docs/0.6.1/development/writingzeppelininterpreter.html#contributing-a-new-interpreter-to-zeppelin-releases
Notably, could you add:

tests
documentation
list licenses for dependencies

@darionyaphet do you need some help for the change?

Hi @anthonycorbacho  thank you for you great help and I'm still working on it .
I have implement a lot of command include GEO ,HASH, HYPERLOGLOG,  LIST, KEYS, Sets ,SORTED SET and Strings and have updated .

I too checked the changes and they look good.The comment from @anthonycorbacho about usage of "Strategy pattern" for selecting the relevant redis command instance and executing them is the better way to implement it.
Also, could we add some test cases for this?
Thanks,
Kavin
MailTo: kavin.kumar@imaginea.com

Every command methods have a chance to leak Jedis instance when command is failing and throwing a kind of JedisException.
You need to replace your borrow-call-return pattern with try-with-resource thanks to Zeppelin requires Java 1.7.

@HeartSaVioR thank you for pointing that out, you are right we better handle the potential JedisException exception to avoid leak.

Hi  @anthonycorbacho  @HeartSaVioR  I have update RedisInterpreter with some redis commands (include APPEND ,BITCOUNT ,BITFIELD ,BITOP, BITPOS, DECR) .
Please help review this one . If anything is OK , I will clean the commented code and completion other redis commands . Thanks ~~ :)

@HeartSaVioR yeah i would love to have a class that manipulate redis cmd and handle null, ussually i am not a huge fan of returning null, i would prefer to return an EMPTY type instead.

Aha. A lot of files conflict and I can't resolve that . Maybe I will close this one and reopen another .

Follow this:

create a new branch which is based on current master
cherry-pick your commits (write down your last commit id)
change branch to PR's branch
git reset --hard last commit id
git push --force

last commit id might be replaced with branch name you created, but I didn't try it.

Add a Screenshot

authors: HeartSaVioR anthonycorbacho darionyaphet felixcheung kavinkumarks

repo: apache/zeppelin

license_source: bigquery


text:
[ZEPPELIN-1850] Remove grunt-contrib-clean (grunt)

What is this PR for?
Replaced grunt-contrib-clean to rimraf

to remove Gruntfile.js
to have npm managed scripts in package.json for running rm -rf in multiple platforms including windows
Also, fixed invalid prestart npm command to predev

This PR related to

https://github.com/apache/zeppelin/pull/1812 (Using yarn)
https://github.com/apache/zeppelin/pull/1818 (Removing jscs)

What type of PR is it?
[Improvement]
Todos
Done at once
What is the Jira issue?
ZEPPELIN-1850
How should this be tested?

npm run test, npm run build, npm run dev should work

Screenshots (if appropriate)
None
Questions:

Does the licenses files need update? - NO
Is there breaking changes for older versions? - NO
Does this needs documentation? - NO

mvn clean in zeppelin-web module now removes bower_components.
what do you think about making mvn clean run npm run clean as well?

@Leemoonsoo Thanks for review!
Now mvn clean will execute npm run clean (8baaea2)
$ zeppelin-web git:(ZEPPELIN-1850/remove-grunt-clean) mvn clean
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=1024m; support was removed in8.0
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building Zeppelin: web Application 0.7.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-clean-plugin:2.6.1:clean (default-clean) @ zeppelin-web ---
[INFO] Deleting /Users/lambda/github/apache-zeppelin/zeppelin-master/zeppelin-web/target
[INFO]
[INFO] --- frontend-maven-plugin:1.3:npm (npm clean) @ zeppelin-web ---
[INFO] Running 'npm run clean' in /Users/lambda/github/apache-zeppelin/zeppelin-master/zeppelin-web
[INFO]
[INFO] > zeppelin-web@0.0.0 clean /Users/lambda/github/apache-zeppelin/zeppelin-master/zeppelin-web
[INFO] > rimraf dist && rimraf .tmp

LGTM and merge to master if there're no further discussions.

Since this PR merge, first CI test profile fails with
[ERROR] Failed to execute goal com.github.eirslett:frontend-maven-plugin:1.3:npm (npm clean) on project zeppelin-web: Failed to run task: 'npm run clean' failed. java.io.IOException: Cannot run program "/home/travis/build/apache/zeppelin/zeppelin-web/node/node" (in directory "/home/travis/build/apache/zeppelin/zeppelin-web"): error=2, No such file or directory -> [Help 1]

@1ambda Could you take a look?


text:
[ZEPPELIN-2122][WIP] Add execution time for Spell

What is this PR for?
Add execution time for spell results. See the screenshot section.
What type of PR is it?
[Improvement]
Todos
NONE
What is the Jira issue?
ZEPPELIN-2122
How should this be tested?

Install any spell (e.g the eco spell)
Execute and check that the paragraph has valid execution time.

Screenshots (if appropriate)

Questions:

Does the licenses files need update? - NO
Is there breaking changes for older versions? - NO
Does this needs documentation? - NO

Tested and LGTM!

Thanks for the review @soralee!

@1ambda is this pr WIP?

@Leemoonsoo No. I have just changed the title again.

LGTM and merge to master if no further comment

authors: 1ambda Leemoonsoo soralee


text:
[ZEPPELIN-5319] Incorrect markdown in the documentation of sap interpreter

What is this PR for?
Fix incorrect example code display at "/interpreter/sap.html"
What type of PR is it?
[Documentation]
What is the Jira issue?

https://issues.apache.org/jira/browse/ZEPPELIN-5319

How should this be tested?

Checked modified document locally

Screenshots (if appropriate)

Questions:

Does the licenses files need update? No
Is there breaking changes for older versions? No
Does this needs documentation? No

LGTM

authors: Reamer cuspymd


text:
[ZEPPELIN-6105] add 'reload note' button to the new interface

What is this PR for?
Add missing button to action bar to reload note. This button exists in the old interface, but is missing in /next
What type of PR is it?
Bug Fix
What is the Jira issue?
https://issues.apache.org/jira/browse/ZEPPELIN-6105
Screenshots (if appropriate)

Thanks, merged to master/0.12


text:
Highlight modified values in counterexamples

Is your feature request related to a problem? Please describe

It's sometimes hard to tell which variables are modified between states of the counterexample.
State0 ==
  __FalseLiveness_init = FALSE
    /\ __InLoop = FALSE
    /\ __saved___temporal_t_1 = FALSE
    /\ __saved_x = 0
    /\ __temporal_t_1 = FALSE
    /\ __temporal_t_1_unroll = FALSE
    /\ __temporal_t_1_unroll_prev = FALSE
    /\ x = 0

(* Transition 1 to State1 *)
State1 ==
  __FalseLiveness_init = FALSE
    /\ __InLoop = TRUE
    /\ __saved___temporal_t_1 = FALSE
    /\ __saved_x = 0
    /\ __temporal_t_1 = FALSE
    /\ __temporal_t_1_unroll = FALSE
    /\ __temporal_t_1_unroll_prev = FALSE
    /\ x = 1

Describe the solution you'd like

There is some sort of indication that a variable changes between states of the counterexample,
like in the TLC toolbox. For example, comment MODIFIED after variables that changed.
State0 ==
  __FalseLiveness_init = FALSE
    /\ __InLoop = FALSE
    /\ __saved___temporal_t_1 = FALSE
    /\ __saved_x = 0
    /\ __temporal_t_1 = FALSE
    /\ __temporal_t_1_unroll = FALSE
    /\ __temporal_t_1_unroll_prev = FALSE
    /\ x = 0

(* Transition 1 to State1 *)
State1 ==
  __FalseLiveness_init = FALSE
    /\ __InLoop = TRUE  (* MODIFIED *)
    /\ __saved___temporal_t_1 = FALSE
    /\ __saved_x = 0
    /\ __temporal_t_1 = FALSE
    /\ __temporal_t_1_unroll = FALSE
    /\ __temporal_t_1_unroll_prev = FALSE
    /\ x = 1 (* MODIFIED *)

Describe alternatives you've considered

I've run a diff-checker on the text blocks for the states, but that's cumbersome.
Maybe the real solution is to use (or implement, if it doesn't exist) some visualizer
which anyways presents traces in a nicer format. Implementing this feature could, however,
be useful until such a visualizer exists.

I have found that copilot perfectly finds modified values in counterexamples

authors: konnov p-offtermatt

repo: apalache-mc/apalache


text:
feat: support orchestrator and proxysql for mysql

fix #353

HOW TO USE:
kbcli cluster create mysql {you_meta_mysql_name} --mode raftGroup
helm upgrade  orchestrator ./orchestrator --install
helm upgrade  orc-cluster ./orchestrator-cluster --install  --set serviceReference.orchestrator.cluster=
{you_meta_mysql_name}  --set serviceReference.orchestrator.namespace={you_meta_mysql_namespace}
helm upgrade  mysql-orc ./mysql-orc --install
helm upgrade  mysql-orc-c ./mysql-orc-cluster --install --set serviceReference.orchestrator.namespace=
{you_orchestrator_namespace} --set serviceReference.orchestrator.cluster=orc-cluster

/approve

authors: kubeJocker shanshanying

repo: apecloud/kubeblocks-addons


text:
Desc of 'parse'

Added a description of the function 'parse' in OmitValue. should resolve #11

Codecov Report

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

@@           Coverage Diff           @@
##           master      #34   +/-   ##
=======================================
  Coverage   68.31%   68.31%
=======================================
  Files         107      107
  Lines        7334     7334
  Branches     1388     1388
=======================================
  Hits         5010     5010
  Misses       1868     1868
  Partials      456      456

Continue to review full report at Codecov.

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

Please close this pull request and open a new one to merge it into the branch 'lab3'

authors: Samuelhertzberg codecov-io francislaus

repo: apeinot/java

license: MIT


text:
Fix redis throttled submission handler interceptor adapter

same fix as #4785, but for master branch

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.6 out of 9 committers have signed the CLA.:white_check_mark: marqc:white_check_mark: julienhuon:white_check_mark: fmartelli:white_check_mark: mmoayyed:white_check_mark: tsschmidt:white_check_mark: dima767:x: leleuj:x: dfish3r:x: leeyc0You have signed the CLA already but the status is still pending? Let us recheck it.

repo: apereo/cas


text:
[Feature] completely separate stages

Prerequisites

[x] I am running the latest version. (up upgrade)
[x] I searched to see if the issue already exists.
[x] I inspected the verbose debug output with the -v, --verbose flag.
[x] Are you an Up Pro subscriber?

Description
Essentially we need this
{
  "stages": {
    "staging": {
      "lambda": {
        "runtime": "nodejs10.x"
      }
    },
    "production": {
      "lambda": {
        "runtime": "nodejs8.10"
      }
    }
  }
}

Due to EOL of node 8 I upgraded several up deployments. nodejs10.x is the first runtime that runs on Amazon Linux 2.

This broke a deployment, because we had binaries that were compiled for Amazon Linux 1.
Now here's the feature request: Currently it's not possible to test a different runtime on staging while keeping production running as-is. It seems "lambda.runtime" is ignored inside the stages, at least the Version on the Lambda Dashboard doesn't change. This kind of makes sense because as far as I understand there's a Go proxy doing the "/production/" and "/staging/" routing inside the same runtime.
Assuming other runtimes (Python, Ruby, Java, Go, .NET) will eventually have versions running Amazon Linux 2 it would be really nice to be able to test in staging before changing production.
Edit: for anyone interested, this is related https://github.com/alixaxel/chrome-aws-lambda/issues/37

Agreed! I'll get that in the next release

Nice, thanks!

@tj did this make it into 1.5.0-pro? The commit is tagged v1.5.0 but the History.md doesn't mention it. I just added
"stages": {
  "staging": {
    "lambda": {
      "runtime": "nodejs10.x"
    }
  }
}

To an existing project. After running up I still see "Runtime: nodejs8.10" on the web dashboard for the latest version aliased "staging".

Hmm should be in there I think, I'll double check

Found it, I was saving a reference to the runtime before applying overrides. I'll start releasing 1.5.1

It's working now, thanks!

Awesome, sorry about that!

authors: Prinzhorn tj

repo: apex/up


text:
iOS 12.4 not supported

Description
On Safari iOS 12.4 and below, no charts are displayed.
I was also reported a problem on Android 7.0 but did not test myself.
I tried with custom code, with the official demos (https://apexcharts.com/javascript-chart-demos/), and with the official codepen (https://codepen.io/apexcharts/pen/bxzgZJ).
Nothing shows.
Errors logged in console are :
Can't find variable ResizeObserver
and
TypeError: undefined is not an object (evaluating this.w.globals.dom.Paper.node)
Steps to Reproduce

Find a device or emulator on iOS 12.4
Open with safari https://apexcharts.com/javascript-chart-demos/ and try to see the demos. No chart shows.

Reproduction Link
https://apexcharts.com/javascript-chart-demos
https://codepen.io/apexcharts/pen/bxzgZJ

I usually don't piggyback onto issues, but I think it's appropriate here.
Same exact issue with Safari 12 on macOS: https://sentry.io/share/issue/08b44283e5234ba6b1ec3e013a4bfe97/
We've had to put a banner across the top of our app, telling users we don't support Safari 12.

I have the same error using apexcharts latest release with:
Safari | 11.1.2
Safari | 12.1.2
Safari | 14.1.2

npm install resize-observer
import { install } from "resize-observer";
install();

authors: JocsSan alexBLR ffxsam linwee


text:
Do not require endpoints to be created

Currently, we require a transaction to be made for an endpoint to be created on-chain, essentially to only create an endpoint ID. Instead, we can use a providerId-endpointInd pair to refer to endpoints. This would also be preferable as we would have identical endpointInds across chains (which can be thought together with mirroring the providerId across chains, see #55 ).

Implemented in bade94b

endpointId is derived as keccak256("oisTitle/endpointName")

Nothing to be done at the node-side for this.


text:
Allow "Finished Actor Run" trigger to GET more than 100 records

From reported issue in Zapier:
Hi there, Apify Team!
JC here, reaching out from Zapier Support. One or more of our mutual customers has requested a new feature in your app.
Specifically, they'd like to see the Finished Actor Run trigger to GET more than 100 records, and not be limited to just 100.
An example use case for this is when a user has a "paid player" on Apify i.e. Tiktok Scraper that allows them to retrieve data from Tiktok but the scaper returns more than 100 records. All exceeding records are lost and are not sent to their downstream app, so removing this limit will allow them to do this.
Here's a GIST where we can see the endpoint query has a 100 record limit:
https://cdn.zapier.com/storage/files/c5c95c85dd8b0e9c548bd36a603a96ea_2.txt
Thanks, and please let us know if you have any questions!
cc https://developer.zapier.com/app/15018/issues/11

I answered on the issue:
Hi there,
Jakub is here from Apify team.
The data from the actor are stored in Apify dataset. We only attached part of the data in trigger data, as there can be a large number of items. But for some use cases, the 100 items are enough.
I would recommend using one more Apify action called "Fetch Dataset Items in Apify" to fetch the actor's data using this step in the Zap. In this action user can set the limit for how many items from the dataset need so that he can get the whole data. Users can find the dataset ID under the field "Default dataset ID" in the previous step trigger "Finished Actor Run".
I hope it helps.
Have a nice day, Jakub Drobník

Let's check what they answer and fix it based on that.

repo: apify/apify-zapier-integration


text:
fix: Accept string payload in the Request constructor

This is a follow-up to https://github.com/apify/crawlee-python/issues/668#issuecomment-2476392555.
Let's accept payload as both str and bytes in the Request.from_url constructor.
The field Request.payload has a validator that accepts both. With this change, we are consistent in the from_url constructor as well.
We do a similar thing for the Request.headers as well.

LGTM

authors: Mantisus vdusek

repo: apify/crawlee-python


text:
Apify.RequestList()'s regex option is not documented

Plus, we should make it clear it needs to be of form /xxx/g.

Just to clarify, it's the regex property of a source (see RequestList options.sources) and it's use to filter links added from a URL using requestsFromUrl. It's used in _addRequestsFromUrl

authors: jancurn mnmkng

repo: apifytech/apify-js


text:
test: improve coverage

The code coverage https://codecov.io/github/ctripcorp/apollo seems to be less than 60%.
It would be great if it can be brought up around 80-90%.

Yes, 80-90% is truly a better status. Do you have some time to work on this?

OK, I'm free on weekends, but I need to take the time to familiarize myself with the code logic first.

Sure, feel free to let the community know if you need any assistance.

#4113 add test for https://github.com/apolloconfig/apollo/blob/4a202065964a2daf4ebe1316b0f6ea5c0ce73105/apollo-core/src/main/java/com/ctrip/framework/apollo/core/utils/PropertiesUtil.java
Thanks @youyulan

The test of xxxUtil is a good first pull request for new contributors.

These xxxUtil are lacking test too.

[ ] https://github.com/apolloconfig/apollo/blob/master/apollo-biz/src/main/java/com/ctrip/framework/apollo/biz/utils/EntityManagerUtil.java
[ ] https://github.com/apolloconfig/apollo/blob/master/apollo-client/src/main/java/com/ctrip/framework/apollo/spring/util/BeanRegistrationUtil.java
[ ] https://github.com/apolloconfig/apollo/blob/master/apollo-client/src/main/java/com/ctrip/framework/apollo/util/http/HttpUtil.java
[ ] https://github.com/apolloconfig/apollo/blob/master/apollo-common/src/main/java/com/ctrip/framework/apollo/common/exception/BeanUtilsException.java
[ ] https://github.com/apolloconfig/apollo/blob/master/apollo-common/src/main/java/com/ctrip/framework/apollo/common/utils/BeanUtils.java
[ ] https://github.com/apolloconfig/apollo/blob/master/apollo-common/src/main/java/com/ctrip/framework/apollo/common/utils/ExceptionUtils.java
[ ] https://github.com/apolloconfig/apollo/blob/master/apollo-core/src/main/java/com/ctrip/framework/apollo/core/utils/DeprecatedPropertyNotifyUtil.java
[ ] https://github.com/apolloconfig/apollo/blob/master/apollo-core/src/main/java/com/ctrip/framework/apollo/core/utils/DNSUtil.java
[ ] https://github.com/apolloconfig/apollo/blob/master/apollo-core/src/main/java/com/ctrip/framework/apollo/core/utils/MachineUtil.java
[ ] https://github.com/apolloconfig/apollo/blob/master/apollo-core/src/main/java/com/ctrip/framework/apollo/core/utils/ResourceUtils.java
[ ] https://github.com/apolloconfig/apollo/blob/master/apollo-core/src/main/java/com/ctrip/framework/foundation/internals/io/IOUtils.java
[ ] https://github.com/apolloconfig/apollo/blob/master/apollo-core/src/main/java/com/ctrip/framework/foundation/internals/Utils.java
[ ] https://github.com/apolloconfig/apollo/blob/master/apollo-portal/src/main/java/com/ctrip/framework/apollo/openapi/util/OpenApiBeanUtils.java
[ ] https://github.com/apolloconfig/apollo/blob/master/apollo-portal/src/main/java/com/ctrip/framework/apollo/portal/util/ConfigToFileUtils.java
[ ] https://github.com/apolloconfig/apollo/blob/master/apollo-portal/src/main/java/com/ctrip/framework/apollo/portal/util/NamespaceBOUtils.java

@ayush0407 Thanks for your kind support, I believe what @Anilople proposed is still valid.

These xxxUtil are lacking test too.

[ ]  https://github.com/apolloconfig/apollo/blob/master/apollo-biz/src/main/java/com/ctrip/framework/apollo/biz/utils/EntityManagerUtil.java
[ ]  https://github.com/apolloconfig/apollo/blob/master/apollo-client/src/main/java/com/ctrip/framework/apollo/spring/util/BeanRegistrationUtil.java
[ ]  https://github.com/apolloconfig/apollo/blob/master/apollo-client/src/main/java/com/ctrip/framework/apollo/util/http/HttpUtil.java
[ ]  https://github.com/apolloconfig/apollo/blob/master/apollo-common/src/main/java/com/ctrip/framework/apollo/common/exception/BeanUtilsException.java
[ ]  https://github.com/apolloconfig/apollo/blob/master/apollo-common/src/main/java/com/ctrip/framework/apollo/common/utils/BeanUtils.java
[ ]  https://github.com/apolloconfig/apollo/blob/master/apollo-common/src/main/java/com/ctrip/framework/apollo/common/utils/ExceptionUtils.java
[ ]  https://github.com/apolloconfig/apollo/blob/master/apollo-core/src/main/java/com/ctrip/framework/apollo/core/utils/DeprecatedPropertyNotifyUtil.java
[ ]  https://github.com/apolloconfig/apollo/blob/master/apollo-core/src/main/java/com/ctrip/framework/apollo/core/utils/DNSUtil.java
[ ]  https://github.com/apolloconfig/apollo/blob/master/apollo-core/src/main/java/com/ctrip/framework/apollo/core/utils/MachineUtil.java
[ ]  https://github.com/apolloconfig/apollo/blob/master/apollo-core/src/main/java/com/ctrip/framework/apollo/core/utils/ResourceUtils.java
[ ]  https://github.com/apolloconfig/apollo/blob/master/apollo-core/src/main/java/com/ctrip/framework/foundation/internals/io/IOUtils.java
[ ]  https://github.com/apolloconfig/apollo/blob/master/apollo-core/src/main/java/com/ctrip/framework/foundation/internals/Utils.java Add unit tests for Utils #4193 Thanks @joshknopp
[ ]  https://github.com/apolloconfig/apollo/blob/master/apollo-portal/src/main/java/com/ctrip/framework/apollo/openapi/util/OpenApiBeanUtils.java
[ ]  https://github.com/apolloconfig/apollo/blob/master/apollo-portal/src/main/java/com/ctrip/framework/apollo/portal/util/ConfigToFileUtils.java
[ ]  https://github.com/apolloconfig/apollo/blob/master/apollo-portal/src/main/java/com/ctrip/framework/apollo/portal/util/NamespaceBOUtils.java

Ok cool, I'll try to cover as many of these as I can over this weekend. Thanks guys!

Which branch should I pull from and commit to?

Which branch should I pull from and commit to?

see https://www.apolloconfig.com/#/en/contributing

Yeah, I forked the project created a new branch but when I am trying to commit from my eclipse IDE it's not allowing me.
Am I missing something?
Please help me out.

Yeah, I forked the project created a new branch but when I am trying to commit from my eclipse IDE it's not allowing me. Am I missing something? Please help me out.

Try another git tool?

https://desktop.github.com/
https://tortoisegit.org/
Git bash

I tried from terminal using auth code but it's giving access denied 403 for my id?
remote: Permission to ayush0407/apollo.git denied to ayush0407.
fatal: unable to access 'https://github.com/ayush0407/apollo.git/': The requested URL returned error: 403
ayushjha@Ayushs-MacBook-Pro apollo7 %

authors: Anilople ayush0407 mghio nobodyiam

repo: apolloconfig/apollo


text:
display output of apollo-integration task

missed printing the Gradle task output in the previous PR

com.apollographql.apollo.ApolloWatcherTest > testQueryWatcherUpdated_SameQuery_DifferentResults_cacheOnly FAILED     java.util.concurrent.TimeoutException at ApolloWatcherTest.java:298
seems flaky.

repo: apollographql/apollo-android


text:
chore(deps): update dependency rollup to v4.18.1

This PR contains the following updates:

Package
Change
Age
Adoption
Passing
Confidence

rollup (source)
4.18.0 -> 4.18.1

Release Notes

rollup/rollup (rollup)
v4.18.1
Compare Source
2024-07-08
Bug Fixes

Prevent "%" in generated file names to ensure imports resolve (#5535)

Pull Requests

#5524: chore(deps): lock file maintenance minor/patch updates (@renovate[bot])
#5525: chore(deps): lock file maintenance (@renovate[bot])
#5526: chore(deps): lock file maintenance minor/patch updates (@renovate[bot])
#5527: chore(deps): lock file maintenance minor/patch updates (@renovate[bot])
#5529: Use Spanned trait to simplify logic (@lukastaegert)
#5530: Fix typos in ARCHITECTURE.md (@younggglcy)
#5532: Use Rust macros for converters where possible (@lukastaegert)
#5535: fix: escape % if URI malformed (@baseballyama, @lukastaegert)
#5536: chore(deps): lock file maintenance minor/patch updates (@renovate[bot], @lukastaegert)
#5541: chore(deps): lock file maintenance minor/patch updates (@renovate[bot])
#5542: chore(deps): lock file maintenance (@renovate[bot])
#5543: Watch rust files and rebuild during dev (@lukastaegert)
#5544: Refactor AST converters (@lukastaegert)
#5545: chore(deps): update dependency @rollup/plugin-commonjs to v26 (@renovate[bot])
#5546: chore(deps): update dependency nyc to v17 (@renovate[bot])
#5547: chore(deps): lock file maintenance minor/patch updates (@renovate[bot])
#5548: chore(deps): lock file maintenance (@renovate[bot])
#5549: chore(deps): lock file maintenance (@renovate[bot])
#5550: chore(deps): update dependency eslint-plugin-unicorn to v54 (@renovate[bot], @lukastaegert)
#5551: chore(deps): lock file maintenance minor/patch updates (@renovate[bot], @lukastaegert)
#5555: chore(deps): lock file maintenance minor/patch updates (@renovate[bot])
#5556: chore(deps): lock file maintenance (@renovate[bot])
#5558: Consider that the body of ClassBody might be of type StaticBlock (@TrickyPi)
#5565: refactor(ast): conditional branch (@Simon-He95)
#5566: chore(deps): lock file maintenance minor/patch updates (@renovate[bot])
#5567: chore(deps): lock file maintenance (@renovate[bot])

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - "after 8am and before 4pm on tuesday" in timezone Etc/UTC.
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.

This PR has been generated by Renovate Bot.

Combined into a single PR #432.x

authors: calvincestari svc-secops

repo: apollographql/apollo-ios-dev


text:
[Data Builders] Fields with @skip or @include Directives should be nullable

Apollo generated kotlin classes properly reflect that a field is nullable when it has a @skip or @include directive but Data Builders currently do not.
For example if I have a sample query like this
query Sample($useFirst: Boolean!) {
  first @include(if: $useFirst)
  second @skip(if: $useFirst)
}

Then the associated Data Builder's first and second field will not be nullable making it impossible to test scenario's where one or both are null.

Good find! Indeed currently if a value is omitted, the default resolver will put a value there...
If Kotlin had union types, we could do something like this:
public class QueryBuilder : ObjectBuilder {
  public var first: Int | Absent
  public var second: Int | Absent
}

which could then be used like so:
SampleQuery.Data {
  first = Absent
  second = 42
}

But I don't think this is really feasible so making everything nullable might be the solution. We'll dig into this.

Yeah that should work! Thanks for the quick response!

This has been released as part of v3.7.5

authors: BoD martinbonnin matthewrkula

repo: apollographql/apollo-kotlin


text:
[schema-stitching]: Alias arguments: Fields X conflict because they have differing arguments.

Now with #411 this query results in the correct response now:
{
  orders {
    itemTotal: total(category: TAXES) {
      amount
      currency
    }
  }
}

But as soon as you add a second alias with the same field and different arguments, new errors pop up.
This one works:
{
  orders {
    itemTotal: total {
      amount
      currency
    }
    taxesTotal: total {
      amount
      currency
    }
  }
}

But that one here does not:
{
  orders {
    itemTotal: total(category: ITEMS) {
      amount
      currency
    }
    taxTotal: total(category: TAXES) {
      amount
      currency
    }
    paymentTotal: total(category: PAYMENT) {
      amount
      currency
    }
    deliveryTotal: total(category: DELIVERY) {
      amount
      currency
    }
    netTotal: total(category: NET) {
      amount
      currency
    }
  }
}

Response is:
{
  "data": null,
  "errors": [
    {
      "message": "Fields \"total\" conflict because they have differing arguments. Use different aliases on the fields to fetch both if this was intentional.\nFields \"total\" conflict because they have differing arguments. Use different aliases on the fields to fetch both if this was intentional.\nFields \"total\" conflict because they have differing arguments. Use different aliases on the fields to fetch both if this was intentional.\nFields \"total\" conflict because they have differing arguments. Use different aliases on the fields to fetch both if this was intentional.\nFields \"total\" conflict because they have differing arguments. Use different aliases on the fields to fetch both if this was intentional.\nFields \"total\" conflict because they have differing arguments. Use different aliases on the fields to fetch both if this was intentional.\nFields \"total\" conflict because they have differing arguments. Use different aliases on the fields to fetch both if this was intentional.\nFields \"total\" conflict because they have differing arguments. Use different aliases on the fields to fetch both if this was intentional.\nFields \"total\" conflict because they have differing arguments. Use different aliases on the fields to fetch both if this was intentional.\nFields \"total\" conflict because they have differing arguments. Use different aliases on the fields to fetch both if this was intentional.",
      "locations": [
        {
          "line": 2,
          "column": 3
        }
      ],
      "path": [
        "orders"
      ]
    }
  ]
}

And this is the result when firing the same query directly to the proxied server:
{
  "data": {
    "orders": [
      {
        "itemTotal": {
          "amount": 5958,
          "currency": "CHF"
        },
        "taxTotal": {
          "amount": 441,
          "currency": "CHF"
        },
        "paymentTotal": {
          "amount": 0,
          "currency": "CHF"
        },
        "deliveryTotal": {
          "amount": 0,
          "currency": "CHF"
        },
        "netTotal": {
          "amount": 5958,
          "currency": "CHF"
        }
      },...

Ugly workaround at the moment:
{
  order {
    total(category: TAXES) {
      amount
      currency
    }
  }
  taxes: order {
    total(category: ITEMS) {
      amount
      currency
    }
  }
}

Should be fixed in #418.

authors: freiksenet pozylon

repo: apollographql/graphql-tools


text:
cacheControl directives not propagated when you rename a Type with schema stitching

Given schema A:
type Query {
   allPosts: [Post]
}

type Post {
    id: String!
    title: String!
}

And schema B:
extend type Query {
   myPosts: [Thread] @cacheControl(maxAge: 40)
}

type Thread {
   id: ID!
   title: String! @cacheControl(maxAge: 20)
}

and a myPosts resolver that contains a mergeInfo.delegate('query', 'allPosts'), the cacheControl directives specified on Thread do not appear in the output:
"cacheControl": {
  "version": 1,
  "hints": [
    {
      "path": [
        "myPosts"
      ],
      "maxAge": 40
    }
  ]
}

In general, schema stitching and cache control don't work together properly. Going to fold this into #890

authors: kbrandwijk stubailo


text:
correctly pass through errors

error != errors 👎

Haha maybe something that could be improved with better typings.

It certainly fixed the bug though!

authors: jbaxleyiii stubailo

repo: apollostack/react-apollo

license: mit


text:
Address Review Comments

move to num-traits for wrapping ops --> Closes #30
use substrate-fixed instead of custom saturated_mul --> Closes #23
use FullCodec --> Closes #21
use RuntimeDebug --> Closes #24

other changes:

remove #![warn(missing_docs)] until substrate macros are fixed

sorry for delay, yes looks good https://github.com/encointer/substrate-fixed seems a good library

Thanks and no worries. I mostly do these PRs for documentation :-)
On Mon, 6 Apr 2020 at 11:26, thiolliere notifications@github.com wrote:

sorry for delay, yes looks good
https://github.com/encointer/substrate-fixed seems a good library
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/apopiak/pallet-stablecoin/pull/32#issuecomment-609680030,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABVBKYSJPKZNTLJ6TWY3ROLRLGN43ANCNFSM4L2IABGA
.

--
Wichtige Mitteilung
Diese Mitteilung wurde von Parity Technologies
Deutschland GmbH kommuniziert, eine im Handelsregister des Amtsgerichtes
Charlottenburg unter HRB 190583 B registrierte Gesellschaft mit
beschränkter Haftung (GmbH). Die Geschäftsführerin der GmbH ist Frau Dr.
Jutta Steiner. Der registrierte Geschäftssitz ist Glogauer Straße 6 in
10999 Berlin, Deutschland.
Diese Mitteilung enthält Informationen welche
vertraulich sind und welche eventuell die Vertraulichkeit der
Rechtsberatung ("Anwaltsgeheimnis") berühren. Sie ist ausschließlich für
den/die vorgesehenen Empfänger bestimmt. Wenn Sie nicht der/die
beabsichtigte(n) Empfänger sind, benachrichtigen Sie bitte admin@parity.io
mailto:admin@parity.io und löschen Sie diese Nachricht sofort.
Unsere
Datenschutzrichtlinie, einschließlich die Art und den Umfang von
personenbezogenen Daten, die wir erfassen, wie wir diese Daten erfassen und
verarbeiten, an wen wir sie in Bezug auf die von uns angebotenen Dienste
weitergeben dürfen, sowie bestimmte Rechte und Optionen, die Sie in dieser
Hinsicht haben, finden Sie unter: https://www.parity.io/privacy/
https://www.parity.io/privacy/

authors: apopiak thiolliere

repo: apopiak/pallet-stablecoin


text:
Rework of license processing

introduced that archive has two separate collections of detected and resulting licenses, where te detected licenses collection is not modified by the
license processing (so that it can be displayed in its original form in
license reports)
reworked the license processing stage completely
added the possibility to signal "no override" of licenses in the
checked archives list (for cases where only provider, notice or doc URL
should be set)
adapted test cases
adapted documentation

Type of request

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[x] Refactoring
[ ] Documentation or documentation changes

Related Issue(s)

Concept

Description of the change

Description of current state
Description of target state
Estimated investment / approximate investment

Initiator
Matthias Pfisterer
Technical information
Platform / target area

known side-effects
other
DB Changes (if so: incl. scripts with definitions and testdata)
How has this Tested?
Added new unit tests for new configuration option in checked archives
Executed all existing unit and integration tests.
Screenshots, Uploads, other documents (if appropriate):

Checklist:

[x] All the commits are signed.
[x] My code follows the code style of this project.
[x] I agree with die CLA.
[x] I have read the CONTRIBUTING docs.
[x] I have added/updated necessary documentation (if appropriate).

Closed in favour of #129

repo: aposin/LicenseScout


text:
Spotify 突然无法登陆了

今天打开Spotify 突然要求重新登陆，然后一直无法登陆，重新安装app也不行。ios16.5,qx,看了下在网络活动里提示这个，请看看是怎么回事，谢谢，万分感谢。

网络是通的

这是你代理软件上配置的一些规则拦截了spotify的网络请求。
你找到对应的规则删掉即可。

哦哦，好的谢谢，我去找找，都没弄过其他的呀。


text:
Tool should display the usage if required args are missing

If the tool has been executed with missing arguments, it should display the usage and exit. However it goes panic.
MacBerry:bin sebastian$ ./alpinepass
panic: stat input.yml: no such file or directory

goroutine 1 [running]:
panic(0x16d980, 0x10530b00)
	/usr/local/go/src/runtime/panic.go:500 +0x325
github.com/appPlant/alpinepass/src/util.CheckError(0x22a8a0, 0x10530b00)
	/go/src/github.com/appPlant/alpinepass/src/util/util.go:13 +0x3e
github.com/appPlant/alpinepass/src/io.readFile(0x18de95, 0x9, 0x0, 0x0)
	/go/src/github.com/appPlant/alpinepass/src/io/input.go:16 +0x64
github.com/appPlant/alpinepass/src/io.ReadConfigs(0x0, 0x0, 0x0, 0x0, 0x0)
	/go/src/github.com/appPlant/alpinepass/src/io/parse.go:62 +0x4e
github.com/appPlant/alpinepass/src/app.execute(0x105b2000, 0x0, 0x0)
	/go/src/github.com/appPlant/alpinepass/src/app/execution.go:17 +0x62
github.com/appPlant/alpinepass/src/app.RunApp.func1(0x105b2000, 0x0, 0x0)
	/go/src/github.com/appPlant/alpinepass/src/app/application.go:51 +0x25
github.com/urfave/cli.HandleAction(0x166980, 0x1a81bc, 0x105b2000, 0x0, 0x0)
	/go/src/github.com/urfave/cli/app.go:485 +0x7f
github.com/urfave/cli.(*App).Run(0x105a25b0, 0x1052a0e0, 0x1, 0x1, 0x0, 0x0)
	/go/src/github.com/urfave/cli/app.go:259 +0xa58
github.com/appPlant/alpinepass/src/app.RunApp()
	/go/src/github.com/appPlant/alpinepass/src/app/application.go:54 +0x565
main.main()
	/root/code/src/alpinepass.go:6 +0x11

When an error occurs a descriptive message is shown and the app's usage is printed!

@katzer You can review the changes and close the issue!

authors: EightBitBoy katzer

repo: appPlant/alpinepass


text:
Stack CLI / RPC support for up command

Adds the amp stack up command and RPC support for up. The CLI command currently only supports the -f, --file option (and it's currently not optional!).
Verification
Create a sample config file. It doesn't matter what's in if for now:
$ touch sample-config.yml

$ make install
# start swarm and amplifier
$ amp stack up -f sample-config.yml

Confirm an ID is printed on the terminal.

:+1:

authors: chrisccoy subfuzion

repo: appcelerator/amp


text:
Updated deps for amp logs testing

This PR adds the difflib needed for @bertrand-quenin's amp logs tests. Separating the dependency update in its own PR makes it easier to view just the relevant changes in the following PR after rebasing.
The way glide get works is that other related dependencies in the dependency graph also get updated when installing a new packaged, hence the total number of files.
Verification
Run tests after pulling to verify package updates don't break anything.

:+1:


text:
Is posible get location for a element?

Good Morning...
I need you help please!!! I try to automated a seek bar using flutter appium driver but I can't have success.
My first idea was get location for element, after try to use TouchAction with the coordinates
element = FlutterElement(self.driver, key_finder)
element.location
element.location raise the exception "Message: Method has not yet been implemented"
Get location is posible in flutter appium driver?
I also try to send keys for element but not working. I use python

Afaik, flutter context only supports commands listed in https://github.com/appium-userland/appium-flutter-driver#commands. So you cannot do other commands in FLUTTER contexts.
It seems https://api.flutter.dev/flutter/flutter_driver/flutter_driver-library.html does not provide any apis to get an element coordinate. I guess flutter_driver by Flutter team does not have such APIs. (then, this driver cannot do anything)
In NATIVE_APP context like https://github.com/appium-userland/appium-flutter-driver#desired-capabilities-for-flutter-driver-only , you can call appium apis. Then, you can interact with elements that are available via OS's accessibility feature.

As the above comment, probably it is not available in Flutter context. Possibly NATIVE context in this driver is available. (Then, the element should be available via OS's accessibility feature.)

@alexis9205110  did you try any of the below methods?

driver.execute('flutter:getBottomLeft', buttonFinder)
driver.execute('flutter:getBottomRight', buttonFinder)
driver.execute('flutter:getCenter', buttonFinder)
driver.execute('flutter:getTopLeft', buttonFinder)
driver.execute('flutter:getTopRight', buttonFinder)

authors: KazuCocoa alexis9205110 sanneabhilash

repo: appium-userland/appium-flutter-driver


text:
Log an error and continue if instruments doesn't shut down

Supersedes https://github.com/appium/appium-instruments/pull/61

LGTM.

authors: imurchie scottdixon

repo: appium/appium-ios-driver


text:
Quickstart link icons do not update when the step has been completed

Upon completing a step in the install guide, the quickstart step should depict its completion state.
IntelliJ

VS Code

Should be fixed with 0.11.0-2, please reopen if it's still a bug on your machine. This isn't implementing the "lock" icon as in VSCode.
https://github.com/applandinc/appmap-intellij-plugin/releases/tag/install-guide-preview

authors: dustinbyrne jansorg

repo: applandinc/appmap-intellij-plugin


text:
Printing with Lexmark CX510de

L'OS de mon PC est Mageia Linux 6.
Pour certaines impressions (je n'ai pas réussi à comprendre pourquoi), l'imprimante sort d'abord une page avec un peu de texte (..., @PJL SET USERNAME = "*****", @PJL ENTER LANGUAGE = POSTS) en haut, avant d'imprimer ensuite le document (= 1 page gaspillée). Je ne sais pas si il s'agit d'une page générée par la nouvelle impression ou si il s'agit d'une page qui "traine" depuis l'impression précédente.
Que puis-je faire ? Est-ce un problème de paramètres dans l'imprimante ? Ou est-ce un problème de paramètres du pilote d'impression ?
Même si j'utilise ensuite ces pages en trop comme brouillons, je n'utilise pas mon imprimante pour me générer des pages de brouillons !!!
If necessary I can write this comment in English.
Pierre

This is probably a printer driver issue - you can try deleting the following line in your PPD file (/etc/cups/ppd/queuename.ppd):
*JCLBegin: "..."

but otherwise there isn't much we can do. Sorry...

Thank you Michael for your answer.
When I apply your solution I no longer get these useless pages. But it is then impossible to print in black and white a colour document ... !
Pierre

authors: Papipio michaelrsweet

repo: apple/cups


text:
[Index] For registering units process them in batches of maximum 10 at a time

This introduces a const variable to control the max number of batches, instead of only being able to process one at a time.

@swift-ci Please test

repo: apple/indexstore-db


text:
"Reformat" breaks the pkl file validity

Let's say I have a poorly-formatted, but working file:
x = new Dynamic {
  modno = 33
  version = 1
  host = "blog"
  repos {
    new Dynamic {
      id = "ban-bot"
      uri = "url:/restic/ban-bot"
      password = "redacted"prunePolicy {
        maxFrequencyDays = 7
        maxUnusedPercent = 25
      }
    }
 };
 plans { new Dynamic { id = "ban-bot";
 repo = "ban-bot";
 paths { "xxx" };
 cron = "50 0 * * *";
 retention { policyTimeBucketed { hourly = 24;
 daily = 7;
 weekly = 4;
 monthly = 6;
 yearly = 2 } };
 hooks { new Dynamic { conditions { "CONDITION_ANY_ERROR" };
 actionGotify { baseUrl = "gotify";
 token = "redacted";
 template = "{{ .Summary }}";
 titleTemplate = "Backrest {{ .EventName .Event }} in plan {{ .Plan.Id }}" } } } };
 };
 auth { users { new Dynamic { name = "asm0dey";
 passwordBcrypt = "redacted" } } } }

When I run the command
pkl eval -f json test.pkl

It successfully compiles an expected json.
However, when I execute a "Reformat" action (and I do it all the time), I get the following:
x = new Dynamic {
  modno = 33
  version = 1
  host = "blog"
  repos {
    new Dynamic {
      id = "ban-bot"
      uri = "url:/restic/ban-bot"
      password = "redacted"prunePolicy {
        maxFrequencyDays = 7
        maxUnusedPercent = 25
      }
    }
  }plans { new Dynamic { id = "ban-bot"repo = "ban-bot"paths { "xxx" }cron = "50 0 * * *"retention { policyTimeBucketed { hourly = 24daily = 7weekly = 4monthly = 6yearly = 2 } }hooks { new Dynamic { conditions { "CONDITION_ANY_ERROR" }actionGotify { baseUrl = "gotify"token = "redacted"template = "{{ .Summary }}"titleTemplate = "Backrest {{ .EventName .Event }} in plan {{ .Plan.Id }}" } } } } }auth { users { new Dynamic { name = "asm0dey"passwordBcrypt = "redacted" } } } }

This file cannot be compiled to JSON anymore.
I would expect the "Reformat" to not break my code and, if possible, align it.
My environment:
IntelliJ IDEA 2024.1 (Ultimate Edition)
Build #IU-241.14494.240, built on March 28, 2024
...
Runtime version: 17.0.10+8-b1207.12 amd64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o.
Linux 6.6.27-1-lts
...
Memory: 4040M
Cores: 16
Registry:
  debugger.auto.attach.from.console=true
  ide.experimental.ui=true
  llm.generate.commit.summary=true
  terminal.new.ui=true
  markdown.open.vcs.log.link=true
  search.everywhere.preview=true
  ide.smart.update=true
  editor.minimap.enabled=true
  jetbrains.tbe.show.error.popup=true
  shared.indexes.download.auto.consent=true
  jetbrains.tbe.branding.icon.show=false
Non-Bundled Plugins:
  com.intellij.grazie.pro (0.3.298)
  DevKit (241.14494.247)
  org.jetbrains.plugins.hocon (2024.1.0)
  org.pkl (0.26.0)
  woaini.liquibase.plugin (1.3-SNAPSHOT)
  com.intellij.ml.llm (241.14494.320)
  kotest-plugin-intellij (1.3.74-241.9959-EAP-CANDIDATE-SNAPSHOT)
  org.jetbrains.toolbox-enterprise-client (2024.3.0.2860-ij241)
  com.intellij.git.instant (1.3.8)
Kotlin: 241.14494.240-IJ
Current Desktop: KDE

Whew, that's a pretty ugly result from formatting. Thanks for the report.

the problem here is semicollon.
If you remove all the semicollons it should format correctly

Thanks for the answer! According to the docs, semicolon is an allowed delimiter. If it's not supported, I would expect it to be highlighted by the IDE. Also, IIRC, I got this ill-formatted pkl from the json module during import.

Just checked, when I use the following command:
pkl eval -p input="$(cat my.json)" -x 'new Parser {}.parse(read("prop:input"))' pkl:json

I've got an output that cannot be formatted by IDEA

Semicolons are treated as whitespace in Pkl. FYI; our style guide is to use them to separate inline object members--if object members are on their own line, semicolons should be omitted.

Got you, thanks! I think they should be underlined as incorrect then

Don’t get me wrong: I am just pointing out the problem that case formattter to act up is semicolon, it can be worked around by just removing every thing, but it’s better to be fixed .

authors: asm0dey bioball thefallentree

repo: apple/pkl-intellij


text:
[5.6] Adapt tests to work better in Swift CI (#45)

Rationale: The original modified a large number of unit tests. If this is different in main and release/5.6 it increases the chance that a commit from main that's cherry picked onto 5.6 has a conflict in the unit testing code.
Risk: Low.
Risk Detail: This is almost entirely a change in test code. Minor non-test code changes were made to allow unit tests to pass in custom unique temp directories to code that write temp data.
Reward: Low/Medium
Reward Details: Minimizes risk of conflicts when cherry picking other work onto the 5.6 release branch.
Original PR: #45
Issue:  rdar://85055022
Code Reviewed By: @franklinsch
Testing Details: This is almost entirely a change in test code.

I'll close this and open a new PR with a better branch name.

repo: apple/swift-docc


text:
Support diffing for RenderNode

Bug/issue #, if applicable: N/A
Summary
These changes implement support to diff any two RenderNode objects, across all their properties, and generate a list of JSON Patches to go from the first RenderNode to the second one. To achieve this:

A new RenderJSONDiffable protocol is defined to ensure similar object types can be diffed. RenderJSONDiffable conformance requires the object to implement difference(from:at:) and optionally isSimilar(to:) methods. This is done for all RenderNode object types and for common built-in types used with JSON.
DifferenceBuilder is defined to help abstracting away the different difference methods. It collects differences between two objects and handles the JSON paths for those differences using addDifferences(atKeyPath:forKey:) method.
The following content is not supported for diffing yet:

Language-specific overrides
Tutorials

Dependencies
None.
Testing
Given two RenderNode objects renderNodeOriginal and renderNodeModified, we can get the list of differences between them with:
renderNodeModified._difference(from: renderNodeOriginal)

Added unit tests loading test .docc bundles, making changes to markdown files within, converting them to RenderNode, and comparing against the version without changes to verify expected diffs. The tests currently cover diffing for:
- abstract
- references
- metadata
- primary content sections
- topic sections
- see also sections
- deprecation summary
- sample download

Ran performance tests comparing against commit previous to these changes.

Results from performance test using a test bundle of size factor 10:

─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Metric                                   │ Change          │ f70b3ea281773121a468d9c0966ab8a34bba58d2 │ current              │
├──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Duration for 'bundle-registration'       │ no change¹,²    │ 2.372 sec                                │ 2.35 sec             │
│ Duration for 'convert-total-time'        │ no change³,⁴    │ 3.503 sec                                │ 3.491 sec            │
│ Duration for 'documentation-processing'  │ no change⁵,⁶    │ 1.037 sec                                │ 1.046 sec            │
│ Duration for 'finalize-navigation-index' │ no change⁷,⁸    │ 0.052 sec                                │ 0.052 sec            │
│ Peak memory footprint                    │ no change⁹,¹⁰   │ 433.2 MB                                 │ 435.6 MB             │
│ Data subdirectory size                   │ no change       │ 111.7 MB                                 │ 111.7 MB             │
│ Index subdirectory size                  │ no change       │ 993 KB                                   │ 993 KB               │
│ Total DocC archive size                  │ no change       │ 117.7 MB                                 │ 117.7 MB             │
│ Topic Anchor Checksum                    │ no change       │ c8f03d4e81da8e3b6d7fb7f63c771147         │ c8f03d4e81da8e3b6d7f │
│ Topic Graph Checksum                     │ no change       │ 36cec4e1bc36e10c1c9323a139ffe2da         │ 36cec4e1bc36e10c1c93 │
└──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

Results from performance test using a test bundle of size factor 50:

─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Metric                                   │ Change          │ f70b3ea281773121a468d9c0966ab8a34bba58d2 │ current              │
├──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Duration for 'bundle-registration'       │ no change¹,²    │ 11.918 sec                               │ 11.975 sec           │
│ Duration for 'convert-total-time'        │ no change³,⁴    │ 18.245 sec                               │ 18.235 sec           │
│ Duration for 'documentation-processing'  │ no change⁵,⁶    │ 5.811 sec                                │ 5.756 sec            │
│ Duration for 'finalize-navigation-index' │ no change⁷      │ 0.27 sec                                 │ 0.264 sec            │
│ Peak memory footprint                    │ no change⁸,⁹    │ 2.02 GB                                  │ 2 GB                 │
│ Data subdirectory size                   │ no change       │ 564.3 MB                                 │ 564.3 MB             │
│ Index subdirectory size                  │ no change       │ 5.1 MB                                   │ 5.1 MB               │
│ Total DocC archive size                  │ no change       │ 594.7 MB                                 │ 594.7 MB             │
│ Topic Anchor Checksum                    │ no change       │ 08d0a84bec913460905fcae417423215         │ 08d0a84bec913460905f │
│ Topic Graph Checksum                     │ no change       │ b8bcd297c1546e3eaa8fbfc8c63eba69         │ b8bcd297c1546e3eaa8f │
└──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

Checklist
Make sure you check off the following items. If they cannot be completed, provide a reason.

[X] Added tests
[X] Ran the ./bin/test script and it succeeded
[ ] Updated documentation if necessary

@swift-ci please test

Looks great! Have you done any performance testing of docc with this change? There's a tool to help with that here: https://github.com/apple/swift-docc/tree/main/bin/benchmark. And you can use the make-test-bundle tool to help generate a large test bundle for testing.
I wouldn't expect any issues but would be good to confirm before we land this.

No, I was not aware of the performance testing tools as a requirement for the PR. I will run it and post the results here.

No, I was not aware of the performance testing tools as a requirement for the PR. I will run it and post the results here.

Thank you! Generally we have an expectation that no change will regress performance – this is a large enough change that I think it's worth checking ahead of time instead of relying on CI to catch it after the fact.

No, I was not aware of the performance testing tools as a requirement for the PR. I will run it and post the results here.

Thank you! Generally we have an expectation that no change will regress performance – this is a large enough change that I think it's worth checking ahead of time instead of relying on CI to catch it after the fact.

I have added the results from running two performance tests (using test bundles of size factor 10 and 50) to the Testing section in the PR.

@swift-ci please test

@swift-ci please test

@swift-ci please test

@swift-ci please test

authors: ethan-kusters raul-ramirezl


text:
Fix handling of the '--' argument followed by inputs for the immediate compilation mode ('swift')

Resolves rdar://114191406

@swift-ci test

repo: apple/swift-driver


text:
Fix copy-pasta typo in regex utility for int parsing

Title kind've says it all 😅

@swift-ci please test

@swift-ci please test

@swift-ci please test

authors: compnerd gwynne

repo: apple/swift-foundation


text:
Stop matching pre-release suffixed next version

Fix https://bugs.swift.org/browse/SR-787

Updated.

Thanks, though we need a test to prevent regression.

Rebased and added test.

@swift-ci Please Test

@swift-ci is available for SwiftPM now? 😲 WoW

woah, can others trigger it or only admins?

Only “Apple Members”, the fear was allowing anyone to trigger remote code execution.

I understand

But, seems broken. I have tested locally and for some reason this patch causes a failure in ManifestTests on Linux—but not Darwin.

Test Case 'ManifestTests.testManifestLoading' started.
/home/mxcl/src/swiftpm/Tests/ManifestParser/ManifestTests.swift:40: error: ManifestTests.testManifestLoading : XCTAssertEqual failed: ("[PackageDescription.Package.Dependency]") is not equal to ("[PackageDescription.Package.Dependency]") -
Test Case 'ManifestTests.testManifestLoading' failed (0.202 seconds).

Could it be that XCTAssertEqual itself behaves differently in swift-corelibs-xctest? 🤔
What are the types of the two inputs?

@swift-ci Please Test

Pull request testing system for swiftpm is working now.
Sorry for the trouble.

I hope this will be in next SNAPSHOT…

Oh, new SNAPSHOT has been released without this. :cry:
What can I do for merging this?

Rebased.

@norio-nomura sorry a test was failing, so I didn't merge. Let me try again.

Yes, I still get a failure on Linux, but I do not on Darwin, and I do not get this failure on Linux for master branch.
Test Case 'ManifestTests.testManifestLoading' started.
/home/mxcl/src/swiftpm/Tests/ManifestParser/ManifestTests.swift:40: error: ManifestTests.testManifestLoading : XCTAssertEqual failed: ("[PackageDescription.Package.Dependency]") is not equal to ("[PackageDescription.Package.Dependency]") -
Test Case 'ManifestTests.testManifestLoading' failed (0.225 seconds).
Executed 1 test, with 1 failure (0 unexpected) in 0.225 (0.225) seconds

weird, it passes for me on Ubuntu 15.05
Test Case 'ManifestTests.testManifestLoading' started.
Test Case 'ManifestTests.testManifestLoading' passed (0.17 seconds).
Executed 1 test, with 0 failures (0 unexpected) in 0.17 (0.171) seconds

$ swiftc -v
Swift version 3.0-dev (LLVM a7663bb722, Clang 4ca3c7fa28, Swift 1c2f40e246)
Target: x86_64-unknown-linux-gnu

--
@norio-nomura unrelated but you also probably need to add PackageDescriptiontest.PackageTests() in LinuxMain.swift

Thanks all. :pray:
@aciidb0mb3r I added that!

@swift-ci Please Test

Yay! Test passed! :raised_hands:

Thanks! 🙏

authors: aciidb0mb3r kostiakoval modocache mxcl norio-nomura shahmishal

repo: apple/swift-package-manager


text:
Add support for the Scudo sanitizer.

The Swift PR apple/swift#28538 adds support for the Scudo hardened
allocator to swiftc. This patch adds support for it to Swift Package
Manager, allowing the Package Manager to correctly plumb Scudo through
the entire build pipeline.
See the aforementioned PR for more discussion on the value of supporting
Scudo.
Note that the tests will fail until apple/swift#28538 lands.

@swift-ci please test

I've brought this patch back up-to-date with master, as the scudo support did in fact land. It'd be nice if we could back port this to 5.3, if it's not too late to do so.

@swift-ci please smoke test

@swift-ci please test

@swift-ci please test

Merged.  Please open a separate PR for the 5.3, which Rick (release manager for SwiftPM in 5.3) will need to approve.

authors: Lukasa abertelrud


text:
[swift-build] Use OptionParserError instead of OptionsParser.Error

master broken...

@swift-ci please test and merge

I just fixed this as part of my further work on Options.


text:
Basics: fix DiagnosticsHanderWrapper typo

Motivation:
This type is private, so plain renaming should be safe.
Modifications:
Applied renaming to DiagnosticsHandlerWrapper within Basics/Observability.swift. Also fixed a typo in a comment in the same file.
Result:
No more typo here, the type easier to find with textual/symbol search.

@swift-ci please smoke test


text:
SwiftPM plugin: allow file glob patterns in protoFiles file list

As mentioned in another issue, we have our proto files integrated using submodules. We want to generate code for proto files in specific directories in this submodule. in the protoc command, we can do this with glob patterns, and it'd be great to be able to support this in the plugin so that we don't need to have a large list of files, if possible.
Our use case requires a pattern that looks like this:
submodules/**/feature/*.proto

Alternatively, if glob's aren't possible, adding a directory that holds proto files would allow the config to be more lean and easier to maintain.

Great, thank you!

repo: apple/swift-protobuf


text:
Generalize Lexeme State into Flags

Generalize the current "is at start of line" bit into a small flag set. On top of that, pass the lexer's "is multiline string" flag up to the parser. This mirrors the behavior of the C++ parser and makes sure we don't have to spend time re-lexing the string literal to determine this for ourselves in a completely separate component.
The important part here is that we have a space to attach a future "error" bit to the tokens, rather than yielding plain .unknown back. This should give us the space to start issuing (what were formerly) lex-time diagnostics.

@swift-ci test

repo: apple/swift-syntax


text:
Remove "unconditional" messaging from Issue kind .unconditional.

This PR changes the default message for an issue of kind .unconditional from "Unconditionally failed" to "Issue recorded".
Although the failure is unconditional at the point it is recorded, the code that recorded the issue may not be unconditionally executing, so we shouldn't describe it as unconditional (we just don't know!)
For example, given the following code:
if case .empty = potatoSack.contents {
  Issue.record("No potatoes left.")
}

We would previously log:

Unconditionally failed: No potatoes left.

Now we'll log:

Issue recorded: No potatoes left.

Resolves #574.
Checklist:

[x] Code and documentation should follow the style of the Style Guide.
[x] If public symbols are renamed or modified, DocC references should be updated.

@swift-ci please test

Looks good, thank you!

authors: grynspan stephencelis

repo: apple/swift-testing


text:
Creating a Dictionary or Set with an element type containing a type parameter pack via a literal crashes the compiler in release builds

Description
Attempting to create an instance of a Set or a Dictionary where the generic parameter (Element in the case of the Set, and Key in the case of the Dictionary) is a Hashable type that uses variadic generics and is passed a single class type as its type parameter pack, crashes the compiler in a release build, if the Set or Dictionary is created using a literal.
See the example program below: it defines several variables (sets and dictionaries) with different parameters for the generic parameter, and using different ways of initialising the values (using a literal and using .init()).
When compiled with a debug build, the entire program will compile without any issues. But in a release build, the compiler will crash if the program contains at least one instantiation of Set or Dictionary where the Hashable generic parameter is HashableTuple<C>.
For some reason, this only happens when HashableTuple's parameter pack consists of a single class type. If a struct type is specified instead, or multiple class types, or a mix of class and struct types, everything seems to work just fine.
I also tried defining a custom type with a Hashable-constrained generic parameter that implements ExpressibleByArrayLiteral, but for some reason instantiating that instead of eg Set worked fine (ie, didn't crash the compiler).
Reproduction
func zip<each T, each U>(_ firsts: (repeat each T), _ seconds: (repeat each U)) -> (repeat (each T, each U)) {
    return (repeat (each firsts, each seconds))
}

/// Determines if two tuples of arbitrary length are equal.
func == <each T: Equatable>(_ lhs: (repeat each T), _ rhs: (repeat each T)) -> Bool {
    let zipped = zip((repeat each lhs), (repeat each rhs))
    var equal = true
    func imp<U: Equatable>(_ input: (U, U)) {
        equal = equal && input.0 == input.1
    }
    repeat imp(each zipped)
    return equal
}

struct HashableTuple<each T: Hashable>: Hashable {
    var elements: (repeat each T)

    func hash(into hasher: inout Hasher) {
        (repeat (each elements).hash(into: &hasher))
    }

    static func == (lhs: Self, rhs: Self) -> Bool {
        return (repeat each lhs.elements) == (repeat each rhs.elements)
    }
}

class C: Hashable {
    func hash(into hasher: inout Hasher) {
        hasher.combine(ObjectIdentifier(self))
    }

    static func == (lhs: C, rhs: C) -> Bool {
        return ObjectIdentifier(lhs) == ObjectIdentifier(rhs)
    }
}

struct S: Hashable {}

// all of the following will fail
var set1: Set<HashableTuple<C>> = []
var dict1: [HashableTuple<C>: Void] = [:] // replace C with S to make it compile...

// all of these are fine
var set2: Set<HashableTuple<C>> = .init()
var dict2: [HashableTuple<C>: Void] = .init()
var set3: Set<HashableTuple<C, C>> = []
var dict3: [HashableTuple<C, C>: Void] = [:]

Stack dump
error: compile command failed due to signal 11 (use -v to see invocation)
Please submit a bug report (https://swift.org/contributing/#reporting-bugs) and include the crash backtrace.
Stack dump:
0.	Program arguments: /Applications/Xcode-15.3.0.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swift-frontend -frontend -c -primary-file x.swift -target arm64-apple-macosx14.0 -Xllvm -aarch64-use-tbi -enable-objc-interop -stack-check -sdk /Applications/Xcode-15.3.0.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.4.sdk -color-diagnostics -O -new-driver-path /Applications/Xcode-15.3.0.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swift-driver -empty-abi-descriptor -resource-dir /Applications/Xcode-15.3.0.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift -module-name x -disable-clang-spi -target-sdk-version 14.4 -target-sdk-name macosx14.4 -external-plugin-path /Applications/Xcode-15.3.0.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.4.sdk/usr/lib/swift/host/plugins#/Applications/Xcode-15.3.0.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.4.sdk/usr/bin/swift-plugin-server -external-plugin-path /Applications/Xcode-15.3.0.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.4.sdk/usr/local/lib/swift/host/plugins#/Applications/Xcode-15.3.0.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.4.sdk/usr/bin/swift-plugin-server -external-plugin-path /Applications/Xcode-15.3.0.app/Contents/Developer/Platforms/MacOSX.platform/Developer/usr/lib/swift/host/plugins#/Applications/Xcode-15.3.0.app/Contents/Developer/Platforms/MacOSX.platform/Developer/usr/bin/swift-plugin-server -external-plugin-path /Applications/Xcode-15.3.0.app/Contents/Developer/Platforms/MacOSX.platform/Developer/usr/local/lib/swift/host/plugins#/Applications/Xcode-15.3.0.app/Contents/Developer/Platforms/MacOSX.platform/Developer/usr/bin/swift-plugin-server -plugin-path /Applications/Xcode-15.3.0.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/host/plugins -plugin-path /Applications/Xcode-15.3.0.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/local/lib/swift/host/plugins -enable-default-cmo -o /var/folders/72/gdk4ykgs6bdg2kds9pynlhzc0000gn/T/TemporaryDirectory.baPUSv/x-1.o
1.	Apple Swift version 5.10 (swiftlang-5.10.0.13 clang-1500.3.9.4)
2.	Compiling with the current language version
3.	While evaluating request ExecuteSILPipelineRequest(Run pipelines { PrepareOptimizationPasses, EarlyModulePasses, HighLevel,Function+EarlyLoopOpt, HighLevel,Module+StackPromote, MidLevel,Function, ClosureSpecialize, LowLevel,Function, LateLoopOpt, SIL Debug Info Generator } on SIL for x)
4.	While running pass #17655 SILFunctionTransform "DCE" on SILFunction "@$ss22__RawDictionaryStorageC4find_9hashValues10_HashTableV6BucketV6bucket_Sb5foundtx_SitSHRzlF1x13HashableTupleVyAK1CC_QPG_Tg5".
 for <<debugloc at "<compiler-generated>":0:0>>Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it):
0  swift-frontend           0x000000010841ff3c llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) + 56
1  swift-frontend           0x000000010841f0f8 llvm::sys::RunSignalHandlers() + 112
2  swift-frontend           0x0000000108420544 SignalHandler(int) + 360
3  libsystem_platform.dylib 0x000000018cec5a24 _sigtramp + 56
4  swift-frontend           0x000000010381aacc (anonymous namespace)::DCE::markValueLive(swift::SILValue) + 424
5  swift-frontend           0x000000010381aacc (anonymous namespace)::DCE::markValueLive(swift::SILValue) + 424
6  swift-frontend           0x000000010381793c (anonymous namespace)::DCEPass::run() + 3788
7  swift-frontend           0x000000010375ba68 swift::SILPassManager::runFunctionPasses(unsigned int, unsigned int) + 3856
8  swift-frontend           0x0000000103754a0c swift::SILPassManager::executePassPipelinePlan(swift::SILPassPipelinePlan const&) + 240
9  swift-frontend           0x0000000103791354 swift::SimpleRequest<swift::ExecuteSILPipelineRequest, std::__1::tuple<> (swift::SILPipelineExecutionDescriptor), (swift::RequestFlags)1>::evaluateRequest(swift::ExecuteSILPipelineRequest const&, swift::Evaluator&) + 56
10 swift-frontend           0x0000000103775184 llvm::Expected<swift::ExecuteSILPipelineRequest::OutputType> swift::Evaluator::getResultUncached<swift::ExecuteSILPipelineRequest>(swift::ExecuteSILPipelineRequest const&) + 476
11 swift-frontend           0x0000000103777e94 swift::runSILOptimizationPasses(swift::SILModule&) + 504
12 swift-frontend           0x0000000102f2d16c swift::CompilerInstance::performSILProcessing(swift::SILModule*) + 1224
13 swift-frontend           0x0000000102d1df98 performCompileStepsPostSILGen(swift::CompilerInstance&, std::__1::unique_ptr<swift::SILModule, std::__1::default_delete<swift::SILModule>>, llvm::PointerUnion<swift::ModuleDecl*, swift::SourceFile*>, swift::PrimarySpecificPaths const&, int&, swift::FrontendObserver*) + 1128
14 swift-frontend           0x0000000102d1d444 swift::performCompileStepsPostSema(swift::CompilerInstance&, int&, swift::FrontendObserver*) + 608
15 swift-frontend           0x0000000102d21694 performCompile(swift::CompilerInstance&, int&, swift::FrontendObserver*) + 1448
16 swift-frontend           0x0000000102d1f6d0 swift::performFrontend(llvm::ArrayRef<char const*>, char const*, void*, swift::FrontendObserver*) + 4968
17 swift-frontend           0x0000000102caee8c swift::mainEntry(int, char const**) + 2612
18 dyld                     0x000000018cb150e0 start + 2360
error: fatalError

Expected behavior
IMO this should compile just fine.
Environment
swift-driver version: 1.90.11.1 Apple Swift version 5.10 (swiftlang-5.10.0.13 clang-1500.3.9.4)
Target: arm64-apple-macosx14.0
Additional information
i also tried this with the nightly compiler, which also crashed.

Update:
Having looked into this a bit more (and spent some more time trying to work around this issue), it seems like this is in fact not caused by the use of set/dictionary literals, but rather is somehow directly related to the use of a single class type in the generic type parameter pack?
To provide some more context, the HashableTuple defined above is used as part of a memoize function:
func memoize<each Input: Hashable, Output>(_ fn: @escaping (repeat each Input) -> Output) -> (repeat each Input) -> Output {
    var cache: [HashableTuple<repeat each Input>: Output] = .init()
    return { (input: repeat each Input) -> Output in
        let key = HashableTuple(elements: (repeat each input))
        // rest omitted bc not relevant
    }
}

even though declaring and initializing a dict as a global variable using .init() works (as seen in the original post), it still fails when done within a function.
As with the initial issue, this seems to happen only if the type using a generic type parameter pack (HashableTuple in this case) is instantiated using only a single class type parameter.
Simply always adding an implicit trailing non-class type parameter to the pack (and thereby ensuring it never consists of only a single class type) seems to work around this issue:
private struct EmptyStruct: Hashable {}

func memoize<each Input: Hashable, Output>(_ fn: @escaping (repeat each Input) -> Output) -> (repeat each Input) -> Output {
    var cache: [HashableTuple<repeat each Input, EmptyStruct>: Output] = [:] // <--
    return { (input: repeat each Input) -> Output in
        let key = HashableTuple(elements: (repeat each input, EmptyStruct())) // <--
        // rest omitted bc not relevant
    }
}

repo: apple/swift


text:
#if targetEnvironment(simulator)

This is an implementation of https://github.com/apple/swift-evolution/pull/764 which has now been accepted. It is ready to merge.

@swift-ci please test

@swift-ci please test

Build failed
Swift Test Linux Platform
Git Sha - 81cc50b181e2874816d0c1f7eac3bb69b70c417e

Build failed
Swift Test OS X Platform
Git Sha - 81cc50b181e2874816d0c1f7eac3bb69b70c417e

authors: graydon swift-ci


text:
[swiftc] Add test case for crash triggered in swift::ValueDecl::isInstanceMember()

What's in this pull request?
Crash case with stack trace:
4  swift           0x0000000001040c01 swift::ValueDecl::isInstanceMember() const + 1
10 swift           0x0000000000e8d9fc swift::TypeChecker::resolveWitness(swift::NormalProtocolConformance const*, swift::ValueDecl*) + 652
11 swift           0x000000000108c18b swift::NormalProtocolConformance::getWitness(swift::ValueDecl*, swift::LazyResolver*) const + 171
13 swift           0x0000000000e84684 swift::TypeChecker::lookupUnqualified(swift::DeclContext*, swift::DeclName, swift::SourceLoc, swift::OptionSet<swift::NameLookupFlags, unsigned int>) + 404
14 swift           0x0000000000e309e6 swift::TypeChecker::resolveDeclRefExpr(swift::UnresolvedDeclRefExpr*, swift::DeclContext*) + 102
16 swift           0x0000000000fe1b03 swift::Expr::walk(swift::ASTWalker&) + 19
17 swift           0x0000000000e31fdd swift::TypeChecker::solveForExpression(swift::Expr*&, swift::DeclContext*, swift::Type, swift::FreeTypeVariableBinding, swift::ExprTypeCheckListener*, swift::constraints::ConstraintSystem&, llvm::SmallVectorImpl<swift::constraints::Solution>&, swift::OptionSet<swift::TypeCheckExprFlags, unsigned int>) + 125
18 swift           0x0000000000e38720 swift::TypeChecker::typeCheckExpression(swift::Expr*&, swift::DeclContext*, swift::Type, swift::ContextualTypePurpose, swift::OptionSet<swift::TypeCheckExprFlags, unsigned int>, swift::ExprTypeCheckListener*) + 576
19 swift           0x0000000000e398e2 swift::TypeChecker::typeCheckBinding(swift::Pattern*&, swift::Expr*&, swift::DeclContext*) + 162
20 swift           0x0000000000e39abb swift::TypeChecker::typeCheckPatternBinding(swift::PatternBindingDecl*, unsigned int) + 267
25 swift           0x0000000000e4a8b6 swift::TypeChecker::typeCheckDecl(swift::Decl*, bool) + 150
26 swift           0x0000000000e6dc92 swift::performTypeChecking(swift::SourceFile&, swift::TopLevelContext&, swift::OptionSet<swift::TypeCheckingFlags, unsigned int>, unsigned int) + 1026
27 swift           0x0000000000cbefbf swift::CompilerInstance::performSema() + 3087
29 swift           0x000000000078bb5f frontend_main(llvm::ArrayRef<char const*>, char const*, void*) + 2495
30 swift           0x0000000000786625 main + 2837
Stack dump:
0.	Program arguments: /path/to/swift/bin/swift -frontend -c -primary-file validation-test/compiler_crashers/28274-swift-valuedecl-isinstancemember.swift -target x86_64-unknown-linux-gnu -disable-objc-interop -module-name main -o /tmp/28274-swift-valuedecl-isinstancemember-23334f.o
1.	While type-checking 'S' at validation-test/compiler_crashers/28274-swift-valuedecl-isinstancemember.swift:9:1
2.	While type-checking expression at [validation-test/compiler_crashers/28274-swift-valuedecl-isinstancemember.swift:10:7 - line:10:7] RangeText="f"
<unknown>:0: error: unable to execute command: Segmentation fault
<unknown>:0: error: compile command failed due to signal (use -v to see invocation)

Resolved bug number: –

Before merging this pull request to apple/swift repository:

[ ] Test pull request on Swift continuous integration.

Triggering Swift CI
The swift-ci is triggered by writing a comment on this PR addressed to the GitHub user @swift-ci. Different tests will run depending on the specific comment that you use. The currently available comments are:
Smoke Testing
    Platform     | Comment
    ------------ | -------------
    All supported platforms     | @swift-ci Please smoke test
    OS X platform               | @swift-ci Please smoke test OS X platform
    Linux platform              | @swift-ci Please smoke test Linux platform

Validation Testing
    Platform     | Comment
    ------------ | -------------
    All supported platforms     | @swift-ci Please test
    OS X platform               | @swift-ci Please test OS X platform
    Linux platform              | @swift-ci Please test Linux platform

Note: Only members of the Apple organization can trigger swift-ci.

@swift-ci Please smoke test

authors: practicalswift tkremenek


text:
[CSRanking] Favour concrete members over protocol requirements

This PR comes in two pieces:
1. A narrow Swift 4.1 compatibility hack that favours properties in concrete types over protocol requirements
This was unintentionally regressed by #15412, and is tracked by SR-7425. This is added as a ranking tie-breaker in order to ensure we don’t introduce any new ambiguities.
2. A new Swift 5 mode ranking rule that favours arbitrary concrete type members over protocol requirements
We already have a similar rule that prefers concrete members over protocol extension members – IMO this new rule is a natural extension of it.
This allows the following code to become unambiguous in Swift 5 mode:
protocol X {
  func baz() -> Int
}

class Y {
  func baz() -> Int { return 0 }
}

func foo(_ x: X & Y) {
  // currently ambiguous, will be made unambigous in Swift 5 mode (favouring Y's `baz()`)
  x.baz()
}

Note that this new rule isn’t applied to overloads found through dynamic lookup in order to ensure we keep cases such as SR-7299 ambiguous.
Note also that this new rule is potentially source breaking (hence why it requires Swift 5 mode) – for example, the following contrived case is currently unambiguous, but will be made ambiguous by the change:
protocol P {
  static func foo() -> Int
}

class C {
  func foo() -> Int { return 0 }
}

extension P where Self : C {
  static func bar() {
    let m = foo // currently unambiguous, will be made ambiguous in Swift 5 mode
  }
}

Arguably this change is unifying the behaviour with that of protocol extensions, where a similar example is already ambiguous:
protocol P {}
extension P {
  static func foo() -> Int { return 0 }
}

class C {
  func foo() -> Int { return 0 }
}

extension P where Self : C {
  static func bar() {
    let m = foo // error: Ambiguous use of 'foo()'
  }
}

And currently, adding static func foo() as a protocol requirement to the above suddenly resolves the ambiguity – with this Swift 5 mode change, the ambiguity is kept in both cases, which seems more consistent.
I’m happy to split this PR up if the Swift 5 mode change requires more discussion.
Resolves SR-7425.

Build failed
Swift Test Linux Platform
Git Sha - 2e6ba53ebcc20fc1c943f46a79f7604ee005dbb3

Just fixed the Linux failure. The source compatibility suite succeeded, though looking through the projects I realise that we wouldn't have exercised -swift-version 5 at all. Is there a way to do so?

@hamishknight No. What I would suggest is removing the version check for the sake of running the compat suite to check that there aren't any unexpected breaks (and see what actually will break for people moving to Swift 5).

@rudkx Thanks, I've gone ahead and done that – could you kick off the compat suite again?

@swift-ci Please test source compatibility

Can you split the changes up into separate PRs we get some feedback from the source compatibility suite?
I'll take a closer look at each once that's done. I am a little concerned that at first glance some of the changes remind me of https://github.com/apple/swift/pull/17995

Sure thing – I've split it up into #18952 & #18951. Shall I go ahead and close this PR?

@rudkx As this branch stands today it preserves behavior when it comes to protocol vs. protocol extension declarations, and would always pick declaration on protocol...

@hamishknight Yes, we can close this out in favor of the two new PRs. Thanks!

authors: hamishknight rudkx swift-ci xedin


text:
Update tests to enable -solver-enable-operator-designated-types when …

…possible.
Add the following to all the expression type checker performance tests
that do not regress as a result:

-swift-version 5
-solver-disable-shrink
-disable-constraint-solver-performance-hacks
-solver-enable-operator-designated-types

@swift-ci Please smoke test

@swift-ci Please smoke test


text:
[build-preset] Add no_test variants of all of the buildbot_linux_* pr…

…esets.
The key thing is that these skip all testing except for the integration testing
and thus are perfect for subproject buildbot testing.
The reason why I am doing this is I discovered that dispatch is not using
build-presets. This means that dispatch may not get updated properly (resulting
in integration test failures) when we add new package installation dependencies
(like llvm-cov, llvm-profdata) for the integration tests.
This is functionally the same as dispatch's build today except that we /will/
build lldb. That being said I think it makes sense to build the entire package
for dispatch so if we have any integration issues in between lldb and dispatch
we can test them.
SR-9080

@swift-ci smoke test

preset=buildbot_linux_1604,notest
@swift-ci Please test with preset Linux Platform

Looks like, I can't use multiple mixins = (.

Nope. I just messed up.

preset=buildbot_linux_1604,notest
@swift-ci Please test with preset Linux Platform

preset=buildbot_linux_1604,notest
@swift-ci Please test with preset Linux Platform

@swift-ci smoke test

@swift-ci smoke test

@swift-ci smoke test

preset=buildbot_linux_1604,notest
@swift-ci Please test with preset Linux Platform


text:
[stdlib] Expunge FixedArray from ABI

@swift-ci please benchmark

@swift-ci please smoke test

Build comment file:
Performance: -Onone

TEST
OLD
NEW
DELTA
RATIO

Regression

DropFirstArrayLazy
31975
35208
+10.1%
0.91x

PrefixArrayLazy
31857
35032
+10.0%
0.91x

DropLastArrayLazy
10638
11696
+9.9%
0.91x

SuffixArrayLazy
10629
11599
+9.1%
0.92x

How to read the data
The tables contain differences in performance which are larger than 8% and
differences in code size which are larger than 1%.
If you see any unexpected regressions, you should consider fixing the
regressions before you merge the PR.
Noise: Sometimes the performance results (not code size!) contain false
alarms. Unexpected regressions which are marked with '(?)' are probably noise.
If you see regressions which you cannot explain you can try to run the
benchmarks again. If regressions still show up, please consult with the
performance team (@eeckstein).

Hardware Overview
  Model Name: Mac Pro
  Model Identifier: MacPro6,1
  Processor Name: 12-Core Intel Xeon E5
  Processor Speed: 2.7 GHz
  Number of Processors: 1
  Total Number of Cores: 12
  L2 Cache (per Core): 256 KB
  L3 Cache: 30 MB
  Memory: 64 GB

--------------

authors: milseman swift-ci


text:
[runtime] Fix some bugs when the stable ABI's is-Swift bit is set.

cmake: Propagate SWIFT_DARWIN_ENABLE_STABLE_ABI_BIT to overlay builds.
runtime: Clear the correct bit in getROData()
test/IRGen/objc_class_export.swift: Allow either is-Swift bit.
test/stdlib/SwiftObjectNSObject.swift: Allow either name for SwiftObject.

@swift-ci please test


text:
Add compatibility tests for implicit (un)tupling in patterns.

Resolves SR-11212. See the issue description on JIRA for an explanation behind the test cases.

@swift-ci please smoke test

@swift-ci please smoke test

So, hang on, if these all already work, what's different about SR-11160?

Good point! Case 1
switch Optional<(Int, Int)>((5, 6)) {
case .some(let b): print(b)
case .none:        print(-1)
}

compiles fine but the supposedly equivalent code Case 2
switch Optional<(Int, Int)>((5, 6)) {
case let b?: print(b)
case .none:  print(-1)
}

does not.
The reason this is happening is because the pattern decomposition is incorrect (this is the 3-line fix around conArgSpace in the SR-11160 PR):
_: Optional<(Int, Int)> --> DISJOIN(.none | .some(_: Int, _: Int)) // wrong on master

On master, there is another bug (which I just found out during this investigation), where projecting .some(let b) gives .some(_: Int, _: Int). I will fix this in the SR-11160 PR (turns out, I ended up changing something else, which was wrong).
In Case 1, the two bugs cancel out as the overall operation becomes
_: Optional<(Int, Int)> - DISJOIN(.none | .some(_: Int, _: Int))

In Case 2, the pattern that gets formed for let b? is the correct one (because the desugaring does the right thing) so you end up subtracting DISJOIN(.none | .some(let b: (_: Int, _: Int))).
When we try to subtract that from _: Optional<(Int, Int)> we get an error.

Oh wow, so SR-11160 really is specific to the Optional sugar syntax, even if accidentally. Okay, thanks for the explanation, and this looks good to merge!

No wonder we didn't catch it earlier.

I think the SR-11160 PR is actually introducing another error because it is allowing illegal subtractions instead of fixing the wrong pattern projection. Investigating that right now.

Hello! I have following warning in Xcode 11.4b1 and not sure what does it mean.

$0 is of type Result<(username: String, sessionKey: String), Error>
What exactly should I fix in this code?

@okla you can fix it by writing
.success((username, sessionKey))

Sorry for the trouble. We have PR https://github.com/apple/swift/pull/28076 up for improving the diagnostic but we haven't merged that yet.

Now I understand, thanks!

authors: jrose-apple okla varungandhi-apple