Rename NOTES*, README*, VERSION, HACKING, LICENSE to .md or .txt

This implements https://github.com/openssl/openssl/pull/12098#issuecomment-641355034.
For the files with names changed to .md, numerous small layout issues had to be solved because those files are now interpreted as MarkDown. It's likely that I missed some of them but at least all those files look reasonable now.
I also had to update various references to the renamed files - hope I caught all of them (I noticed and corrected some cases where similar references to other files renamed earlier had not been updated). Where it made most sense I converted them to proper (clickable) MarkDown-style references.

I got about 25% through this PR.

Thanks @richsalz and @levitte for pointing out various mistakes;
I fixed all of them and some further minor issues I found in the course of doing that.

Did you run make md-nits on your machine before creating this PR?

Oh, never heard of that.
So I've installed mdl and I'm working through the findings now...

So I've installed mdl and I'm working through the findings now...

Please be careful what conclusions you draw.  mdl is over-zealous on quite a lot of points (to the point of actually being wrong, or at least overly unflexible), until told otherwise util/markdownlint.rb.

Please be careful what conclusions you draw. mdl is over-zealous on quite a lot of points (to the point of actually being wrong, or at least overly unflexible), until told otherwise in util/markdownlint.rb.

Good point. For this reason I've added three more rule exceptions,
in particular to allow bare URL. I see no point in re-writing, e.g.,
 directly at http://www.delorie.com/pub/djgpp. For help on which

to
 directly at [http://www.delorie.com/pub/djgpp](http://www.delorie.com/pub/djgpp).
 For help on which

as this just adds redundancy, wastes space,
and often adds the need for extra line breaks.

I'm done with all changes due to the reviews, and make md-nits is satisfied.

I didn't mean link references.  Some markdown processors, when you would otherwise have [link-text](link-text) allow you to omit the parentheses part.
And while I'm here, just wanted to say that this is amazing work!

I've just rebased this, fixing conflicts with the just merged 12098.
Anything more to do on this PR?

@levitte, since you reviewed this and in my view all requested changes are done,
can you approve this now?

Travis failures are unrelated.

Please be careful what conclusions you draw. mdl is over-zealous on quite a lot of points (to the point of actually being wrong, or at least overly unflexible), until told otherwise in util/markdownlint.rb.

Good point. For this reason I've added three more rule exceptions,
in particular to allow bare URL. I see no point in re-writing, e.g.,
 directly at http://www.delorie.com/pub/djgpp. For help on which

to
 directly at [http://www.delorie.com/pub/djgpp](http://www.delorie.com/pub/djgpp).
 For help on which

as this just adds redundancy, wastes space,
and often adds the need for extra line breaks.

The sane alternative to disabling the bare URL warning is to write urls within <>: <https://www.example.com/>

A few comments below.

Thanks @romen.

I also have read about 1/3 of the changes so far, and this looks great!

Pleased to hear!

I would mention here (instead than repeating the same comment line by line) that [foo/bar.md] is equivalent to [foo/bar.md](foo/bar.md) and in many places we could prefer the implicit notation for readability and maintainability.

This would be great, but sadly, as mentioned meanwhile in https://github.com/openssl/openssl/pull/12232#issuecomment-648623226, I found that this is not supported at least by Firefox and Chrome/Chromium.

The other general note that I hope we will be able to address is that it seems git (well, the github ui at least, I haven't checked out this PR locally yet to examine more closely) seems to be losing track of some of the renames and instead treating them as o"old file was deleted, here is a new file". This is bad to track changes/blame in the documentation (which is often important in navigating how the project evolved and when features have been added, changed, deprecated, etc.).
IIRC our resident git guru @mspncp recently faced similar problems and of course he found a solution to provide git with enough hints that it was able to track file history/renames correctly. @mspncp can you guide us with your magic once more?

I think that in this case git (and the GitHub pages) does the right thing already.
For instance, git log -p shows things like
diff --git a/NOTES.ANDROID b/NOTES-Android.md
similarity index 100%
rename from NOTES.ANDROID
rename to NOTES-Android.md

Can we please finalize this PR soon?
Due to the vast number of changes in many doc files this tends to quickly collect vast numbers of conflicts.
I've just rebased to cover the conflicts than came up recently.

While you're correct things, there's this at line 2934:
   configuration in one of the `Configurations/*.conf~ files (in

It should probably be:
   configuration in one of the `Configurations/*.conf` files (in

While you're correct things, there's this at line 2934:
   configuration in one of the `Configurations/*.conf~ files (in

It should probably be:
   configuration in one of the `Configurations/*.conf` files (in

Oops, thanks, fixed.
Strange that mdl does not report such an imbalanced use of "`".
I just went though the rest of CHANGES.md and found many occurrences of "`xyz'"
and changed them to "xyz".

Strange that mdl does not report such an imbalanced use of "`".

Not at all, you are allowed to have multiline inline code blocks

Strange that mdl does not report such an imbalanced use of "`".

Not at all, you are allowed to have multiline inline code blocks

Yes, but I would expect that the number of backticks in a file should still be even.
There seems to be an implicit (redendering) rule that the effect of a backtick stretches at most to the end of its paragraph.

Similarly, there's this line:
  * Make `openssl version' output lines consistent.

where the ' should be converted to a `

Done.

Rebased this mostly for kicking Travis after it had timed out on two runs last time.

I had to handle merge conflicts again.
Can we please finalize this soon?

Hopefully @levitte can add his approval and we can get this in ... it is nice work!

Hopefully @levitte can add his approval and we can get this in ... it is nice work!

Thanks @t-j-h!
@levitte (and also @richsalz and @romen) had already given various good comments, which I addressed,
and it appears to me he simply did not notice that or had no time to check on this.
In any case your approval will be sufficient.

Understood. The approval you require is there. I'm just hoping that @levitte can use the 24 hour delay before merge to also indicate his approval as well given you addressed all of his comments and he did a detailed review.

24 hours has passed since 'approval: done' was set, but as this PR has been updated in that time the label 'approval: ready to merge' is not being automatically set.  Please review the updates and set the label manually.

Partly squashed, merged - thanks!

Well, it still seems weird to me that INSTALL.md contains quite thorough details about all aspects of configuration, building and installation, but that the testing details are thrown off to the side, so to say...  I'm not sure I'll understand the purpose.  But again, i seem to be a minority, so I'll accept this outcome.


$cordovaGoogleAnalytics docs source link incorrect

The "Source" link on http://ngcordova.com/docs/plugins/googleAnalytics/ incorrectly points to:
https://github.com/driftyco/ng-cordova/blob/master/src/plugins/ga.js
The link should point to:
https://github.com/driftyco/ng-cordova/blob/master/src/plugins/googleAnalytics.js

Greetings @willmore!
I've closed this issue because my sensors indicated it was old and inactive, and may have already been fixed in recent versions of Ionic. However, if you are still experiencing this issue, please feel free to reopen this issue by creating a new one, and include any examples and other necessary information, so that we can look into it further.
Thank you for allowing me to assist you.


[BUG] spark 3.4.1 incompatible with delta-core 2.4.0 missing class

Bug
Which Delta project/connector is this regarding?

[X] Spark
[ ] Standalone
[ ] Flink
[ ] Kernel
[ ] Other (fill in here)

Describe the problem
class not found albeit https://docs.delta.io/latest/releases.html lists the versions of spark and delta as compatible
This goes for a normal /path/to/file and file:///path/to/file path
I am running in local mode
Steps to reproduce
Please include copy-pastable code snippets if possible.

install pyspark from conda-forge in version 3.4
include a suitable openjdk package
run a delta lake IO (writing) operation

Observed results
Py4JJavaError: An error occurred while calling o253.save.
: java.lang.NoClassDefFoundError: org/apache/spark/sql/execution/datasources/FileFormatWriter$Empty2Null

Expected results
the delta lake file write operation to succeed
Further details
Py4JJavaError: An error occurred while calling o253.save.
: java.lang.NoClassDefFoundError: org/apache/spark/sql/execution/datasources/FileFormatWriter$Empty2Null
	at org.apache.spark.sql.delta.DeltaLog.startTransaction(DeltaLog.scala:218)
	at org.apache.spark.sql.delta.DeltaLog.startTransaction(DeltaLog.scala:215)
	at org.apache.spark.sql.delta.DeltaLog.withNewTransaction(DeltaLog.scala:231)
	at org.apache.spark.sql.delta.commands.WriteIntoDelta.run(WriteIntoDelta.scala:92)
	at org.apache.spark.sql.delta.sources.DeltaDataSource.createRelation(DeltaDataSource.scala:171)
	at org.apache.spark.sql.execution.datasources.SaveIntoDataSourceCommand.run(SaveIntoDataSourceCommand.scala:47)
	at org.apache.spark.sql.execution.command.ExecutedCommandExec.sideEffectResult$lzycompute(commands.scala:75)
	at org.apache.spark.sql.execution.command.ExecutedCommandExec.sideEffectResult(commands.scala:73)
	at org.apache.spark.sql.execution.command.ExecutedCommandExec.executeCollect(commands.scala:84)
	at org.apache.spark.sql.execution.QueryExecution$$anonfun$eagerlyExecuteCommands$1.$anonfun$applyOrElse$1(QueryExecution.scala:98)
	at org.apache.spark.sql.execution.SQLExecution$.$anonfun$withNewExecutionId$6(SQLExecution.scala:118)
	at org.apache.spark.sql.execution.SQLExecution$.withSQLConfPropagated(SQLExecution.scala:195)
	at org.apache.spark.sql.execution.SQLExecution$.$anonfun$withNewExecutionId$1(SQLExecution.scala:103)
	at org.apache.spark.sql.SparkSession.withActive(SparkSession.scala:827)
	at org.apache.spark.sql.execution.SQLExecution$.withNewExecutionId(SQLExecution.scala:65)
	at org.apache.spark.sql.execution.QueryExecution$$anonfun$eagerlyExecuteCommands$1.applyOrElse(QueryExecution.scala:98)
	at org.apache.spark.sql.execution.QueryExecution$$anonfun$eagerlyExecuteCommands$1.applyOrElse(QueryExecution.scala:94)
	at org.apache.spark.sql.catalyst.trees.TreeNode.$anonfun$transformDownWithPruning$1(TreeNode.scala:512)
	at org.apache.spark.sql.catalyst.trees.CurrentOrigin$.withOrigin(TreeNode.scala:104)
	at org.apache.spark.sql.catalyst.trees.TreeNode.transformDownWithPruning(TreeNode.scala:512)
	at org.apache.spark.sql.catalyst.plans.logical.LogicalPlan.org$apache$spark$sql$catalyst$plans$logical$AnalysisHelper$$super$transformDownWithPruning(LogicalPlan.scala:31)
	at org.apache.spark.sql.catalyst.plans.logical.AnalysisHelper.transformDownWithPruning(AnalysisHelper.scala:267)
	at org.apache.spark.sql.catalyst.plans.logical.AnalysisHelper.transformDownWithPruning$(AnalysisHelper.scala:263)
	at org.apache.spark.sql.catalyst.plans.logical.LogicalPlan.transformDownWithPruning(LogicalPlan.scala:31)
	at org.apache.spark.sql.catalyst.plans.logical.LogicalPlan.transformDownWithPruning(LogicalPlan.scala:31)
	at org.apache.spark.sql.catalyst.trees.TreeNode.transformDown(TreeNode.scala:488)
	at org.apache.spark.sql.execution.QueryExecution.eagerlyExecuteCommands(QueryExecution.scala:94)
	at org.apache.spark.sql.execution.QueryExecution.commandExecuted$lzycompute(QueryExecution.scala:81)
	at org.apache.spark.sql.execution.QueryExecution.commandExecuted(QueryExecution.scala:79)
	at org.apache.spark.sql.execution.QueryExecution.assertCommandExecuted(QueryExecution.scala:133)
	at org.apache.spark.sql.DataFrameWriter.runCommand(DataFrameWriter.scala:856)
	at org.apache.spark.sql.DataFrameWriter.saveToV1Source(DataFrameWriter.scala:387)
	at org.apache.spark.sql.DataFrameWriter.saveInternal(DataFrameWriter.scala:303)
	at org.apache.spark.sql.DataFrameWriter.save(DataFrameWriter.scala:239)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
	at py4j.reflection.MethodInvoker.invoke(MethodInvoker.java:244)
	at py4j.reflection.ReflectionEngine.invoke(ReflectionEngine.java:374)
	at py4j.Gateway.invoke(Gateway.java:282)
	at py4j.commands.AbstractCommand.invokeMethod(AbstractCommand.java:132)
	at py4j.commands.CallCommand.execute(CallCommand.java:79)
	at py4j.ClientServerConnection.waitForCommands(ClientServerConnection.java:182)
	at py4j.ClientServerConnection.run(ClientServerConnection.java:106)
	at java.base/java.lang.Thread.run(Thread.java:829)
Caused by: java.lang.ClassNotFoundException: org.apache.spark.sql.execution.datasources.FileFormatWriter$Empty2Null
	at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:476)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:589)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)

Environment information

Delta Lake version: 2.4.0
Spark version: 3.4.1/3.4.0
Scala version: 2.12/pyspark 3.10

Willingness to contribute
The Delta Lake Community encourages bug fix contributions. Would you or another member of your organization be willing to contribute a fix for this bug to the Delta Lake code base?

[ ] Yes. I can contribute a fix for this bug independently.
[ ] Yes. I would be willing to contribute a fix for this bug with guidance from the Delta Lake community.
[X] No. I cannot contribute a bug fix at this time.

when you installed spark 3.4 from conda-forge.. was it Spark 3.4.0 or 3.4.1 ?
Delta 2.4.0 is expected to work with Spark 3.4.0. It hasnt been tested explicitly with Spark 3.4.1 since it came out after Delta 2.4.0. So that may be the reason. And if it turns out that you were using Spark 3.4.1 via conda, can you explicitly test with Spark 3.4.0?

I tested with both and both failed for me. However, it was working some weeks ago in an old conda env.

I could identify a local environment specific error to solve the issue

I could identify a local environment specific error to solve the issue

What did you do? I'm having the same error.

There were multiple sources (4 places) that specified the versions one out of the four specified the mismatch of 3.4 with 2.3 delta which does not work. I fixed it to now specify in all places the correct version.

2.3 as documented - as said this was a local mixup with one of the multiple locations where it was configured


[RFC] Should we block old daemons trying to join a swarm cluster?

Opening this as a separate discussion, after reading https://github.com/docker/docker/pull/31714#issuecomment-288278321
The docker CLI, and API has backwards-compatibility;

the API is versioned, so an old CLI talking to a "new" daemon will use the API version that matches the CLI
likewise, if a new CLI connects to an older daemon, it will downgrade to the API version supported by that daemon, and not use features that are not supported by that daemon.

However, a swarm cluster may be a different beast; how do we deal with old daemons trying to join a "new" cluster, e.g., a  Docker 17.03 node trying to join a Swarm cluster that consists of Docker 17.06 nodes?

Should the whole cluster downgrade to features only supported by the all nodes in the cluster?
What if the cluster already uses features that are not supported by the client trying to join?

These scenarios also apply when upgrading a swarm; during the upgrade, not all nodes may be on the latest version; should we disable new features during that time? Is there already a mechanism in place to take this into account?
FWIW, we should not "block" old daemons,  but we need to find a solution if daemons have conflicting features
ping @docker/core-swarmkit-maintainers

However, a swarm cluster may be a different beast; how do we deal with old daemons trying to join a "new" cluster, e.g., a Docker 17.03 node trying to join a Swarm cluster that consists of Docker 17.06 nodes?

We need to support mixed-version clusters - otherwise upgrading to a new version would involve downtime. So I don't see anything inherently wrong with nodes joining the cluster using an older version. We need to handle the mixed version case anyway.

Should the whole cluster downgrade to features only supported by the all nodes in the cluster?

In most cases, I don't think this is desirable or necessary. For example, if a worker that doesn't support secrets joins a cluster with services that have secrets set up, it's not a good reason to block secrets from working anywhere else. But it gets more complicated when you're talking about outdated managers, or scenarios like removing the ingress network.

These scenarios also apply when upgrading a swarm; during the upgrade, not all nodes may be on the latest version; should we disable new features during that time?

Ideally yes

Is there already a mechanism in place to take this into account?

Not yet

it's not a good reason to block secrets from working anywhere else.

Yes, that may be a good example; what happens if a node joins that doesn't support secrets, and a task gets rescheduled (landing on such a node)?

Yes, that may be a good example; what happens if a node joins that doesn't support secrets, and a task gets rescheduled (landing on such a node)?

Currently, the task will run on that node, but not have access to any secrets.
I think it's acceptable for new features like secrets not to work on nodes which are running a version that predates the feature. Our general policy so far has been that you need to finish upgrading all your nodes before using new features. But there are definitely things we can do to make this more foolproof.

@aluzzardi fyi. this is tracking the discussion we had f2f. can you pls share your views ?

I'm surprised this is even being considered. :scream:

Currently, the task will run on that node, but not have access to any secrets.

Should such tasks be rejected by the node?

I'm surprised this is even being considered.

Are you surprised that backward compatibility is being considered, or that one of the possibilities under discussion is preventing outdated nodes from joining the cluster after features that they don't support are already in use? Can you elaborate on your concerns?

Shouldn't such tasks be rejected by the node?

If the node is running a version that predates secrets, it has no way of knowing that it should reject a task that uses secrets.

Are you surprised that backward compatibility is being considered, or that one of the possibilities under discussion is preventing outdated nodes from joining the cluster after features that they don't support are already in use? Can you elaborate on your concerns?

I'm surprised that we'd consider blocking older daemons from joining the swarm cluster.

I'm surprised that we'd consider blocking older daemons from joining the swarm cluster.

I think I agree in general. This issue was raised in the context of having some kind of feature flags that are gated on all nodes in the cluster supporting the feature. For example, in this world you wouldn't be allowed to replace the ingress network until you've upgraded to a version which supports this feature, because doing so causes problems for versions that predate the feature. The question that comes up is what to do if a new node, running an older version, joins the cluster after the cluster had previously converged on a version new enough to allow flipping the flag on. One of the simpler possibilities, which I believe @thaJeztah proposed as a straw man, is to block older versions if admitting that node to the cluster would force us to turn off features we've already exposed. While it would be nice to find something more elegant, this sounds like a reasonable option to me if we can't come up with a better approach that's practical.

Let me close this ticket for now, as it looks like it went stale.


Added samkhawase.com to the 512 club

This PR is:

[x] Adding a new domain
[ ] Updating existing domain size
[ ] Changing domain name
[ ] Removing existing domain from list
[ ] Website code changes (512kb.club site)
[ ] Other not listed

[x] I used the uncompressed size of the site
[x] I have included a link to the Cloudflare report
[x] This site is not an ultra minimal site
[x] The following information is filled identical to the data file

I confirm that I have read the FAQ section, particularly the two red items around minimal pages and inappropriate content and I attest that this site is neither of these things.

[x] Check to confirm

- domain:
  url:
  size:
  last_checked:

Cloudflare Report:
https://radar.cloudflare.com/scan/bef7de2d-a324-42a5-bda5-0034e4043a34/summary

Thanks!


remove isFromKeyboard

Warnings

:warning:
There are no updates provided to CHANGELOG. Ensure there are no publicly visible changes introduced by this PR.

  Generated by :no_entry_sign: dangerJS


doc: how it works

@Kuadrant/engineering ready for review

@Kuadrant/engineering ready for review


FIX toDict to send requests as list, not dict

Solution
Requests should be set as list when converting to a Dict for YAML, not a Dictionary.

Codecov Report
Base: 95.07% // Head: 94.48% // Decreases project coverage by -0.58% :warning:

Coverage data is based on head (223e735) compared to base (01810a8).
Patch coverage: 0.00% of modified lines in pull request are covered.

Additional details and impacted files
@@            Coverage Diff             @@
##             main       #8      +/-   ##
==========================================
- Coverage   95.07%   94.48%   -0.59%
==========================================
  Files           7        7
  Lines         487      490       +3
==========================================
  Hits          463      463
- Misses         24       27       +3

Impacted Files
Coverage Δ

skelerest/skelerest.py
92.52% <0.00%> (-2.67%)
:arrow_down:

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

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


HTTP 503 when enabling a zone

Unable to control a zone
Steps to reproduce the behavior:

Turn off zone on Master Controller
Select 'Heat' option for zone accessory in Home app
Observe errors in HB log:
[Actron Neo] Maximum retries exceeded -> Actron Neo API returned a server side error: http status code = 504
[Actron Neo] API Error when attempting command send:
{"command":{"UserAirconSettings.EnabledZones[0]":true,"type":"set-settings"}}
[Actron Neo] Failed to send command, Actron Neo Cloud unreachable

Homebridge Version: 1.6.1
Plugin Version: 1.2.13

Resolved in release 0.0.16


Token exchange rfc8693

This PR adds rudimentary support for OAuth 2.0 Token Exchange
For now the exchange is supposed to be triggered by library-users manually. In a later stage it might be done automatically by reading the capability from the .well-known.
We created this PR here as Jumbo seems to be unmaintained.
List of common tasks a pull request require complete

[ ] Changelog entry is added or the pull request don't alter library's functionality

Continued in https://github.com/JuliusPC/OpenID-Connect-PHP/pull/21


error: use of undeclared identifier '_mm256_cvtph_ps'

zimg 2.2.1 fails to build on macOS <= 10.10
The errors look like this (this is just an excerpt):
src/zimg/depth/f16c_ivb.cpp:52:14: error: use of undeclared identifier '_mm256_cvtph_ps'; did you mean '_mm256_cvtpd_ps'?
                __m256 x = _mm256_cvtph_ps(_mm_load_si128((const __m128i *)(src_p + vec_left - 8)));
                           ^~~~~~~~~~~~~~~
                           _mm256_cvtpd_ps
/usr/bin/../lib/clang/5.1/include/avxintrin.h:528:1: note: '_mm256_cvtpd_ps' declared here
_mm256_cvtpd_ps(__m256d __a)
^
src/zimg/depth/f16c_ivb.cpp:52:30: error: cannot initialize a parameter of type '__m256d' with an rvalue of type '__m128i'
                __m256 x = _mm256_cvtph_ps(_mm_load_si128((const __m128i *)(src_p + vec_left - 8)));
                                           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/bin/../lib/clang/5.1/include/avxintrin.h:528:25: note: passing argument to parameter '__a' here
_mm256_cvtpd_ps(__m256d __a)
                        ^

Here's a full build log: https://gist.github.com/ilovezfs/643b502700507d49eec09ccb3b3ba348
The underlying issue is that https://reviews.llvm.org/rL254528 moved the relevant symbols from f16cintrin.h to immintrin.h, so earlier versions won't have them defined if only immintrin.h is included. If you try to include f16cintrin.h directly, the build will complain that f16cintrin.h should be included directly, and that instead it should be included indirectly by including x86intrin.h.
So for the Homebrew upgrade to 2.2.1 I'm working around the build failure by adding the following to the formula:
    if MacOS.version < :el_capitan
      (buildpath/"brew_include/immintrin.h").write <<-EOS.undent
        #include <x86intrin.h>
        #include_next <immintrin.h>
      EOS
      ENV.prepend "CPPFLAGS", "-I#{buildpath}/brew_include"
    end

It would be great, though, if there were a proper upstream fix in the zimg source code. Thanks for your help.
Cf.
https://github.com/Homebrew/homebrew-core/pull/4109
(and same problem in 2.2 https://github.com/Homebrew/homebrew-core/pull/3956)

This won't be fixed. Upgrade your CLANG version to 3.8 (XCode 7.3?), so that it will be compatible with ICC/ICL.

It's not my clang version. I'm one of the Homebrew maintainers, who happened to be updating this software, and our CI failed on 10.9 and 10.10 due to this issue.
I'll interpret your remark above as a request to set a minimum macOS requirement of El Capitan (7.2.1 is the maximum Xcode version that runs on 10.10 Yosemite), which is unfortunate since Apple is still supporting 10.10 at this point and since the fix is trivial.

I thought you discovered a workaround for this issue on your end? You can also configure with "--disable-simd" for a C++-only build.


Use jasmine rails

Came to this repo to add tests for a new component but found that the tests were running but then erroring and I was completely unable to run them in browser.
This PR updates the JS test suite to use rails-jasmine rather than the jasmine gem. The tests can now be run by going to /specs or using bundle exec rake spec:javascript or bundle exec rake or bundle exec rake tests depending on how much of the test suite you want to run.
I hope this is an improvement, using jasmine-rails is the way all of the newer GOV.UK repos use jasmine.

The admin tools are mostly using the official jasmine gem for tests, rather than jasmine-rails but there is only one clear reason I can think of for this. In the jasmine gem there's a configuration option that prevents jasmine from automatically downloading and installing a version of PhantomJS (by the phantomjs gem). @alext originally highlighted the automatic install as a cause for concern in a managed environment and we patched the jasmine gem to make it configurable.
For more context, here's the issue I raised on jasmine-rails: https://github.com/searls/jasmine-rails/issues/133 and the PR to fix this issue on the jasmine gem: https://github.com/jasmine/jasmine-gem/pull/213 (I fixed it here as that was the gem being used at the time)
Here is where static is preventing the download:
https://github.com/alphagov/static/blob/master/spec/javascripts/support/jasmine_helper.rb

To summarise the conversation @fofr and I just in meatspace:
There are three options here

Revert the change, things are still a bit broken but phantomjs isn't being downloaded automatically.
Keep the change, live with the problem being re-introduced. @fofr and I aren't really sure if this is still as bigger problem as it was when we fixed it last time. This is something we'd like to talk to @alext about.
Keep the change and patch jasmine-rails to not automatically download phantomjs. @fofr would quite like to do this as a community spirited patch for rails-jasmine users as well as fixing this for us (here and in the other places we're using jasmine-rails)

For now, @fofr is going to spend 20 minutes looking at how difficult patching jasmine-rails would be
@alext if you have any opinions about option 2 here then please share them.
I'm no longer blocked and the tests I'm going to write now for my new component will work with jasmine or jasmine-rails so I'll continue as I was and leave it up to you to merge or not merge.

The branch was accepted and made it into jasmine-rails 0.10.6 so this doesn't need to point to a github branch anymore.


Add a flag to enable reactor enhanced stacktraces.

Document turning on client request/response logs
Fixes https://github.com/spring-cloud/spring-cloud-dataflow-server-cloudfoundry/issues/253
Fixes https://github.com/spring-cloud/spring-cloud-dataflow-server-cloudfoundry/issues/270

LGTM, also verified the changes in CF environment. Merging.


win: delay closing the socket when there are pending reads

Remove the optimization that allowed skipping the delaying when the socket was not shared - I don't see any reason why that was possible
https://docs.microsoft.com/en-us/windows/win32/winsock/graceful-shutdown-linger-options-and-socket-closure-2

#3034

Now that there is a real understanding of this subject, we know that it is not up to libuv to drain the reading side of a socket


Fix deseasonality transforms to handle integer timestamp

🚀 Feature Request
In #148 it was found that deseasonality transforms fail on data with integer timestamp. It could be fixed.
Proposal
Fix tests tests/test_transforms/test_inference/test_transform/TestTransformTrain for transforms:

STLTransform
DeseasonalityTransform

The error in STLTransform is caused by warning
statsmodels.tools.sm_exceptions.ValueWarning: An unsupported index was provided and will be ignored when e.g. forecasting.

We should check how it influences the result and suppress it if it doesn't.
The error in DeseasonalityTransform  is caused by seasonal_decompose, that doesn't want to work with integer timestamp. We could try to fix that. For example, seasonal_decompose doesn't use self.period, it could be the reason. We should also fix _OneSegmentDeseasonalityTransform._roll_seasonal

Fix determine_freq to recognize freq=None for integer timestamp
Fix determine_num_steps to work with freq=None for integer timestamp

Test cases

Move fixed tests in tests/test_transforms/test_inference/test_transform/TestTransformTrain from fail to success category
Move fixed tests tests/test_transforms/test_inference/test_transform/TestInverseTransformTrain from fail to success category

Additional context
Blocked by #148.

Closed by #174.


Generated output is missing Stubs (Routeguide.RouteGuide.Stub) blocking local test cases

Your great work with "Transcoding HTTP/JSON to gRPC" led me to this repository.
It works excellent with the exception that all module test fails du to missing Stub functions.
At the end of each generated file i would assume the following should be present:
defmodule Routeguide.RouteGuide.Stub do
  @moduledoc false
  use GRPC.Stub, service: Routeguide.RouteGuide.Service
end

Hint: Adding this manually fixes the problem.

That's was crazy quick, can confirm that it works great! 👍
I do get this warning, but it's fully operational!
warning: assign @module_doc? not available in EEx template. Please ensure all assigns are given as options. Available assigns: [:module, :service_name, :methods, :descriptor_fun_body, :version]
  (eex 1.15.7) lib/eex/engine.ex:140: EEx.Engine.fetch_assign!/2
  (stdlib <IP_ADDRESS>) erl_eval.erl:744: :erl_eval.do_apply/7
  (stdlib <IP_ADDRESS>) erl_eval.erl:323: :erl_eval.expr/6
  (stdlib <IP_ADDRESS>) erl_eval.erl:492: :erl_eval.expr/6
  (stdlib <IP_ADDRESS>) erl_eval.erl:136: :erl_eval.exprs/6
  (elixir 1.15.7) src/elixir.erl:375: :elixir.eval_forms/4


[BUG] Wrong type signature in gtk::Expression::bind (maybe?)

Bug description
Right now the signature of the method gtk::Expression::bind is as follows:
pub fn bind<T: IsA<Object>>(&self, target: &T, property_name: &str, this: Option<&T>) -> ExpressionWatch

I'd expect that the target and this objects are most of the time of different types. Because of the single generic type common to both objects, they have to be upcast to a common parent (usually glib::Object). My intuition tells me that there should be two different generic types declared with the same constraints for each argument.

Yes, this should have two generic types. Do you want to submit a PR?

Thanks!


feat: Mock API in frontend

Please implement the Mock API on the frontend and integrate it before backend complete.

Mock API Structure in Swagger Structure
Integrate Mock API in Frontend project.

Reference: https://juejin.cn/post/7205087401017655353

Another Mock Library: https://mswjs.io/


Issues in Chrome Version 76.0.3809.132 (Official Build) (64-bit)

Version
Latest in site demo : https://ui.toast.com/tui-image-editor/
Development Environment
MacOs 10.14.6 + Chrome Version 76.0.3809.132 (Official Build)
Current Behavior
Hi team,
I have these issues with tui image editor when using latest version of Chrome
76.0.3809.132 (Official Build) (64-bit)

Drawing a line to a position, after out focus mouse, the line that I draw moving to another position

Can't do anything when in MenuBar Position Top  mode

just found .tui-image-editor-container.top .tui-image-editor-submenu has bottom: inherit, which means 0 (from parent element).

Thanks @syjstc . That's issue. I've done a workaround for this
 .tui-image-editor-container.top .tui-image-editor-submenu {
        bottom: unset;
    }

and It works. thanks for your help!


Add url param for client during auth request

Currently for ios we're sending client=ios_secure, it'd be great to pass along something like client=android.

@aulneau Could you please add some more background? Custom parameters can be added with a custom auth request.

Currently, we rely on blockstack.js to redirect to signin. There is no logic to add additional parameters to the redirect to httpsURI.
Potentially addressing this in the future by pointing the AndroidSDK to a different path for auth e.g. browser.blockstack.org/auth_mobile


Model weights (for VG, PSG, OIv6)

Dear Authors,
Thank your for the amazing work! I am also working on this domain and was wondering if you could please share the model weights pretrained on VG,PSG and OIv6 to conduct qualitative error analysis of your model to better understand your model. Please let me know. Thanks again for the paper and code!

You can download model weight from: https://huggingface.co/rj979797/PGSG-CVPR2024/tree/main

I am not able to match the scores with the scores with those reported here. Heres the log file for eval run with config and scores, is this expected or am I missing something?
Here's the command I used for eval run:
python -m torch.distributed.run --master_port 13958 --nproc_per_node=4 evaluate.py --cfg-path lavis/projects/blip/eval/rel_det_vg_pgsg_eval_ov.yaml --job-name VG-pgsg_stdsgg-eval
Here are some of the assumptions I made, can you let me know if these are correct?

zeroshot_triplet_lavis.pytorch should point to zeroshot_triplet.pytorch
VG-SGG-*.h5 files point to VG-SGG-with-attri.h5
checkpoint: vg_ov_sgg.pth


Support using local time instead of utc for cron

add features cron_local to replace Utc with Local in schedule.upcoming(timezone) call
see issue:

#24
#41
#44
#47

@mvniekerk sorry to bother. Is this pr ok or not? I have same issue with timezone right now.

Hi @mvniekerk, have you had a chance to review this PR? I'm considering using this library for a future project, and it'll involve working with tasks in different time zones. Your feedback is valuable. Thanks!

Wait for review and merge this PR

Hi all
I'm busy on a branch Timezone, if you don't mind testing it. It allows per-job TZ setting.

Hi all
Thank you for the PR, again.
So on 0.10.0 I've added a builder API to have the TZ persisted with the other job data, and have it as part of the scheduling.
Please check if this works OK? Or are there other ideas in this PR that I need to incorporate somehow?

Hi @Dkwcs
Thanks for the PR. I'm closing this as I haven't received any feedback yet?


mock: upgrade and port from extended to core (including dependencies)

Merge Checklist

All boxes should be checked before merging the PR (just tick any boxes which don't apply to this PR)

[X] The toolchain has been rebuilt successfully (or no changes were made to it)
[X] The toolchain/worker package manifests are up-to-date
[X] Any updated packages successfully build (or no packages were changed)
[X] Packages depending on static components modified in this PR (Golang, *-static subpackages, etc.) have had their Release tag incremented.
[X] Package tests (%check section) have been verified with RUN_CHECK=y for existing SPEC files, or added to new SPEC files
[X] All package sources are available
[X] cgmanifest files are up-to-date and sorted (./cgmanifest.json, ./toolkit/scripts/toolchain/cgmanifest.json, .github/workflows/cgmanifest.json)
[X] LICENSE-MAP files are up-to-date (./LICENSES-AND-NOTICES/SPECS/data/licenses.json, ./LICENSES-AND-NOTICES/SPECS/LICENSES-MAP.md, ./LICENSES-AND-NOTICES/SPECS/LICENSE-EXCEPTIONS.PHOTON)
[X] All source files have up-to-date hashes in the *.signatures.json files
[X] sudo make go-tidy-all and sudo make go-test-coverage pass
[X] Documentation has been updated to match any changes to the build system
[ ] Ready to merge

Summary

Upgrades mock to a usable version that will run on Azure Linux 3.0 and upgrades it and its required dependencies to core from extended. Since the 2.0 -> 3.0 upgrade, the version of mock present in extended hasn't been able to run correctly.
Change Log

Upgrade mock and move to core
Upgrade mock-core-configs and move to core (part of mock)
Upgrade distribution-gpg-keys and move to core (required by mock)
Upgrade libuser and move to core (required by mock)
Add python-backoff (required by mock)
Upgrade python-pyroute2 and move to core (required by mock)
Add python-rpmautospec-core (required by mock)
Upgrade python-templated-dictionary and move to core (required by mock)
Upgrade usermode and move to core (required by mock)

Does this affect the toolchain?
No.
Test Methodology
Local build + buddy build.

@PawelWMS thanks for all the feedback on this PR--definitely some good learning for me along the way.
When you get a chance, would you please look at the updates I made to see if they address your questions and concerns? I know there's a conflict with the license map right now, but I'm inclined to hold off on (re-)resolving that / (re-)sync'ing until getting a general thumbs up from you on the meaningful changes herein.
(As a side note, is there something we could do to decrease conflicts on LICENSES-MAP.md? Even splitting up the giant table cells into multiple rows on multiple textual lines would likely decrease conflicts and enable auto-merging without sacrificing the actual contents. Would there be support for doing that?)


Unable to get nested objects.

I can't seem to get this to work for nested objects e.g.
{"isbn": "123-456-222",    "author":      {       "lastname": "Doe",       "firstname": "Jane"     }  }
e.g. my parent object can get Book but can't get the author, its always null
`public class Test
{
public Json Data
}
public class Book
{
public string isbn { get; set; }
public Json author  { get; set; }
}
public class Author
{
public string lastname { get; set; }
public string firstname  { get; set; }
}
`
I'm I doing something wrong?

There is no need for the second Json<> inside the Book class. Replace Json<Author> with Author
public class Test
{
     public Json<Book> Data
}

public class Book
{
     public string isbn { get; set; }
     public Author author { get; set; }
}

public class Author
{
     public string lastname { get; set; }
     public string firstname { get; set; }
}

I initially had it like this.. I removed the Json<> from Author and the author object is still null though. Is there something else that needs to be done?

How does SQL query look?

For me next query works as expected:
var connection = new SqlConnection(Config.ConnectionString);
var books = await connection.QueryAsync<Book>("""
                    SELECT
                        ISBN,
                        (SELECT FirstName, LastName FROM Authors a where a.Id = b.AuthorEntityId  FOR JSON PATH, WITHOUT_ARRAY_WRAPPER) AS Author
                    FROM Books b
                 """);

foreach (var book in books)
{
    Console.WriteLine(book.ISBN);
    Console.WriteLine(book.Author.Value!.FirstName);
    Console.WriteLine(book.Author.Value!.LastName);
}

Ahhh this was driving me crazy, the issue was I forgot to add the  access modifier for the author field so by default it was private :(. once changed to public it all worked. Thanks for the help....


IOS LightBlue disconnects immdeiately while interrogating

Hello Adam ,
while I am trying to test my peripheral using pybleno it connects ok from nrf Connect app but from lightblue it disconnects immediately while interrogating

Hi @sherifshsffa91 - have you met the Bleno prerequisites with regards to disabling bluetoothd?
https://github.com/noble/bleno#prerequisites

If so, this could be tricky to track down. Can you reproduce the issue using any of the Pybleno examples?

Ok, no I don't follow bleno prerequisites, So let me try it and  I will come back to you to inform you with update

may the problem in detail was the following :

may be the problem in detail was :

once sudo hciconfig hci0 up
iphone is able to connect only one time

and then unable to connect again SO I did ,

every disconnection , killing bluetooth hci thread then deleting stop advertising , then
doing 'sudo hciconfig hci0 reset' everytime before bleno.start()

so this solved my issue

Hi @sherifshsffa91 is your platform Pi/Raspbian?
What Raspbian version are you using? Raspbian <= 2008-11-13?

hello adam

Hi @sherifshsffa91 is your platform Pi/Raspbian? yes RPI model 3b+
What Raspbian version are you using? Raspian 9 (stretch)

Can you tell me exact build?
uname -a

here it is
pi@raspberrypi:~ $ uname -a
Linux raspberrypi 4.14.98-v7+ #1200 SMP Tue Feb 12 20:27:48 GMT 2019 armv7l GNU/Linux

Thanks - ok, you're not subject to the bluetooth bug.
I would suggest, if you want to keep investigating, reproduce the issue and then dump the output dmesg here.
Thanks.


PSCredentialinfo constructior with hashtable bugged ?

Prerequisites

[X] Write a descriptive title.
[X] Make sure you are able to repro it on the latest released version
[X] Search the existing issues.

Steps to reproduce
when I looked at the PSCredentialInfo.cs code to understand how to use it, I saw a possible bug
https://github.com/PowerShell/PowerShellGet/blob/8f6a237bdeb6915793a9cfecca19a0d8db35c120/src/code/PSCredentialInfo.cs#L52
seems this should be
- if (hashtable.ContainsKey("Credential") && hashtable["PSCredential"] is PSCredential psCred)
+ if (hashtable.ContainsKey("Credential") && hashtable["Credential"] is PSCredential psCred)

Expected behavior
-

Actual behavior
-

Error details
-

Environment data
-

Visuals
No response

By the way, what's the purpose of a hashtable constructor if PS has a parameter splatting via @hashtable ?


Implement #A10 for c-ares resolver, avoid SRV and TXT lookups for localhost

This extracts all changes from https://github.com/grpc/grpc/pull/16862 (c-ares as the default resolver) except for the actual flag flip that makes c-ares default. #16862 is not quite ready yet because of a flaking test, but this PR extracts out implementation of https://github.com/grpc/proposal/blob/master/A10-avoid-grpclb-and-service-config-for-localhost-and-ip-literals.md (avoid SRV and TXT queries for localhost targets).

****************************************************************

libgrpc.so

     VM SIZE                                                                                FILE SIZE
 ++++++++++++++ GROWING                                                                              ++++++++++++++
  +0.0%    +164 [None]                                                                               +5.40Ki  +0.1%
  +1.8%    +176 src/core/ext/filters/client_channel/resolver/dns/c_ares/grpc_ares_wrapper.cc            +176  +1.8%
       +13%    +178 grpc_dns_lookup_ares_locked_impl                                                        +178   +13%
  +0.8%     +36 src/core/ext/filters/client_channel/resolver/dns/c_ares/dns_resolver_ares.cc             +36  +0.8%
      [NEW]    +166 grpc_core::(anonymous namespace)::AresDnsResolver::MaybeStartResolvingLocked() [clon    +166  [NEW]
      [NEW]     +35 should_use_ares                                                                          +35  [NEW]
      +6.0%     +16 grpc_resolver_dns_ares_init                                                              +16  +6.0%
      +9.4%     +13 [Unmapped]                                                                               +13  +9.4%

  +0.0%    +376 TOTAL                                                                                +5.61Ki  +0.0%

****************************************************************

libgrpc++.so

     VM SIZE        FILE SIZE
 ++++++++++++++  ++++++++++++++

  [ = ]       0        0  [ = ]

****************************************************************

libgrpc.so

     VM SIZE                                                                                FILE SIZE
 ++++++++++++++ GROWING                                                                              ++++++++++++++
  +0.0%    +164 [None]                                                                               +5.40Ki  +0.1%
  +1.8%    +176 src/core/ext/filters/client_channel/resolver/dns/c_ares/grpc_ares_wrapper.cc            +176  +1.8%
       +13%    +178 grpc_dns_lookup_ares_locked_impl                                                        +178   +13%
  +0.8%     +36 src/core/ext/filters/client_channel/resolver/dns/c_ares/dns_resolver_ares.cc             +36  +0.8%
      [NEW]    +166 grpc_core::(anonymous namespace)::AresDnsResolver::MaybeStartResolvingLocked() [clon    +166  [NEW]
      [NEW]     +35 should_use_ares                                                                          +35  [NEW]
      +6.0%     +16 grpc_resolver_dns_ares_init                                                              +16  +6.0%
      +9.4%     +13 [Unmapped]                                                                               +13  +9.4%

  +0.0%    +376 TOTAL                                                                                +5.61Ki  +0.0%

****************************************************************

libgrpc++.so

     VM SIZE        FILE SIZE
 ++++++++++++++  ++++++++++++++

  [ = ]       0        0  [ = ]

[trickle] No significant performance differences

[trickle] No significant performance differences

Corrupt JSON data (indicates timeout or crash):
    bm_call_create.BM_IsolatedFilter_ClientChannelFilter_NoOp_.counters.new: 10
    bm_call_create.BM_IsolatedFilter_ClientChannelFilter_NoOp_.counters.old: 10

[microbenchmarks] No significant performance differences

Corrupt JSON data (indicates timeout or crash):
    bm_call_create.BM_IsolatedFilter_ClientChannelFilter_NoOp_.counters.new: 10
    bm_call_create.BM_IsolatedFilter_ClientChannelFilter_NoOp_.counters.old: 10

[microbenchmarks] No significant performance differences

****************************************************************

libgrpc.so

     VM SIZE                                                                                FILE SIZE
 ++++++++++++++ GROWING                                                                              ++++++++++++++
  +0.0%     +48 [None]                                                                               +5.55Ki  +0.1%
  +1.8%    +176 src/core/ext/filters/client_channel/resolver/dns/c_ares/grpc_ares_wrapper.cc            +176  +1.8%
       +13%    +178 grpc_dns_lookup_ares_locked_impl                                                        +178   +13%
  +0.7%     +32 src/core/ext/filters/client_channel/resolver/dns/c_ares/dns_resolver_ares.cc             +32  +0.7%
      [NEW]    +166 grpc_core::(anonymous namespace)::AresDnsResolver::MaybeStartResolvingLocked() [clon    +166  [NEW]
      [NEW]    +111 grpc_core::(anonymous namespace)::AresDnsResolver::MaybeFinishNextLocked() [clone .p    +111  [NEW]
      [NEW]     +84 grpc_core::(anonymous namespace)::ValueInJsonArray(grpc_json*, char const*) [clone .     +84  [NEW]
       +12%     +32 grpc_resolver_dns_ares_init                                                              +32   +12%

  +0.0%    +256 TOTAL                                                                                +5.75Ki  +0.1%

****************************************************************

libgrpc++.so

     VM SIZE        FILE SIZE
 ++++++++++++++  ++++++++++++++

  [ = ]       0        0  [ = ]

[trickle] No significant performance differences

[trickle] No significant performance differences

Objective-C binary sizes
*****************STATIC******************
  New size                      Old size
 2,020,870      Total (=)      2,020,870

 No significant differences in binary sizes

***************FRAMEWORKS****************
  New size                      Old size
11,177,124      Total (<)     11,177,126

 No significant differences in binary sizes

Corrupt JSON data (indicates timeout or crash):
    bm_call_create.BM_IsolatedFilter_ClientChannelFilter_NoOp_.counters.new: 10
    bm_call_create.BM_IsolatedFilter_ClientChannelFilter_NoOp_.counters.old: 10

[microbenchmarks] No significant performance differences

Objective-C binary sizes
*****************STATIC******************
  New size                      Old size
 2,020,870      Total (=)      2,020,870

 No significant differences in binary sizes

***************FRAMEWORKS****************
  New size                      Old size
11,177,122      Total (=)     11,177,122

 No significant differences in binary sizes

Corrupt JSON data (indicates timeout or crash):
    bm_call_create.BM_IsolatedFilter_ClientChannelFilter_NoOp_.counters.new: 10
    bm_call_create.BM_IsolatedFilter_ClientChannelFilter_NoOp_.counters.old: 10

[microbenchmarks] No significant performance differences

[trickle] No significant performance differences

Objective-C binary sizes
*****************STATIC******************
  New size                      Old size
 2,020,870      Total (=)      2,020,870

 No significant differences in binary sizes

***************FRAMEWORKS****************
  New size                      Old size
11,177,126      Total (<)     11,177,127

 No significant differences in binary sizes


Date Object Incompatibility with json-schema-to-ts Type Generation

Prerequisites

[X] I have written a descriptive issue title
[X] I have searched existing issues to ensure the bug has not already been reported

Fastify version
5.1.0
Plugin version
4.0.0
Node.js version
20.11.1
Operating system
macOS
Operating system version (i.e. 20.04, 11.3, 10)
24.1.0
Description
When working with fastify and its response serializer (fast-json-stringify), I noticed an inconsistency with how date objects are handled between fast-json-stringify and json-schema-to-ts.
The fast-json-stringify serializer allows me to directly provide a Date object, which is then correctly serialized to a date-time string format in the response. However, json-schema-to-ts requires the type definition to explicitly expect a string, not a Date, even though the JSON schema specifies a date-time format.
Example Schema:
response: {     200: {         type: 'object',         properties: {             createdAt: { type: 'string', format: "date-time" },         }     } }
Link to code that reproduces the bug
No response
Expected Behavior
It would be helpful if json-schema-to-ts could accommodate Date objects when a JSON schema property is set to a date-time format, matching the behavior of fast-json-stringify.

I do not have an idea on how this could be achieved, but a PR that implemented this would be amazing.

I think I added support for a fix/workaround in this PR: https://github.com/fastify/fastify-type-provider-json-schema-to-ts/pull/103
Using the deserialize type option on the serializer lets you return Date objects.

Wow @bcomnes - really firing on all cylinders today, this is the second issue I had with this plugin that you are fixing today.


Remove all execline configuration scripts

Its confusing best replace it with bash, and make the defaults more discover able and less 'scripty'.

This will probably also get covered as the system around confd is being overhauled https://github.com/Islandora-Devops/isle-dc/issues/119

wip: https://github.com/nigelgbanks/isle-buildkit/tree/bye-bye-execline

Resolved via https://github.com/Islandora-Devops/isle-buildkit/commit/25a016543cc324980f53e071120c39904b7619a1


Framework issues

Hi,
I added framework to my project manually but had some issues:

I had to add libxml2.tbd to framework

It had only macOS framework. There is not one for iOS, etc. Every os should have separate framework

It's not updated for Xcode 8.1 (recommended settings)

@amosavian  Hi, may I know what package manager are you using? Thanks

Hi, Thanks for response.
I manually added Fuzi.xcodeproj to my project.
I can make a pull request if it's okay.

@amosavian
https://github.com/cezheng/Fuzi#manually
As the README of this repo has stated, if you manually add it you do need to link libxml2 yourself(either adding libxml2.tbd or adding -lxml2 to Other Linker Flags)
As for the target, the current single Target should work for all platforms. It used to have 4 targets, but I reduced it to only 1 in this commit: https://github.com/cezheng/Fuzi/commit/21fec230924f56ec5288c576e68e51ba21caee67

When I can add xcodeproj easily why I should bother adding sources?
I will make a pull request to rectify this issue asap

@amosavian
I guess Fuzi is linking -lxml2 with this module map. https://github.com/cezheng/Fuzi/blob/master/libxml2/module.modulemap
And adding the project work pretty much the same as using Carthage to build the framework and then adding the framework. For Carthage's case, it would only need to add Header Search Path for libxml2, so I'm not really sure why you need to add libxml2.tbd.
If you look at the FuziDemo project, it has the same structure of your project, and it adds neither libxml2.tbd nor -lxml2 flag, so I guess the problem is else where.

I guess it's because you set Always Search User Paths to "NO". By the way that's not the standard way for a framework. As you mentioned we have either link it statically(-l flag) or dynamically(.tbd).

@amosavian What do you mean by the 'standard way for a framework'? Setting Always Search User Paths to 'YES' will just make '#include <...>' work for User Search Paths, but I don't think it is correct to mess User Search Paths with System Search Paths, and the libxml2's include directory is definitely in System Search Paths.

Hey @cezheng there is an issue for Info.plist copying in build phase

oh? What is that?

@amosavian can you show me the whole message?

Removing Info.plist from here would resolve issue

I tried to use this framework but failed in making it build with my project.  I followed the steps in manually installing it but then I get a compile error: 'libxml/xmlversion.h' file not found in xmlreader.h, Could not build Objective-C module 'libxml2'
When I followed the Carthage instructions the module simply could not be found.  Too bad, was looking forward to using xpath in swift.

I tried to use this framework but failed in making it build with my project.  I followed the steps in manually installing it but then I get a compile error: 'libxml/xmlversion.h' file not found in xmlreader.h, Could not build Objective-C module 'libxml2'
When I followed the Carthage instructions the module simply could not be found.  Too bad, was looking forward to using xpath in swift.

@tinygamefactory I don't think you did as the README says, since clearly the error message suggests that you didn't set the Header Search Path


ENH: Remove redundant tests on make_flash_bem

Describe the problem
mne.bem.make_flash_bem was tested in both mne/commands/test_commands.py and mne/tests/test_bem.py. Since the function is time-consuming, merge them into test_flash_bem in test_commands.py would reduce testing time (~200 sec).
The flash bem surfaces in the testing dataset are different from surfaces computed by mne/commands/test_commands/test_flash_bem in that test_flash_bem uses both mef05.mgz (FLASH5) and mef30.mgz (FLASH30) to create the flash bem surfaces while the surfaces in testing data were created from only flash5.mgz (FLASH5). Is it necessary to assure the generated flash bem surfaces are the exactly same as those in the testing data?
The coordinates (x from test_flash_bem, y from testing data) are different, reported by pytest:
AssertionError:
Not equal to tolerance rtol=1e-07, atol=0

Mismatch: 100%
Max absolute difference: 1.82610321
Max relative difference: 43.68559136
x: array([[  -1.028   ,   -0.8233  ,  115.167198],
  [  72.226601,   -0.7632  ,   67.861504],
  [  21.6248  ,   83.526398,   66.532303],...
y: array([[  -1.3635  ,   -0.8711  ,  115.845596],
  [  72.295403,   -0.5315  ,   68.657402],
  [  20.939199,   83.773201,   67.367401],...

Describe your solution
Maybe testing the shape of surfaces like in test_watershed_bem is enough?
Describe possible alternatives

Keep both tests
Increase the tolerance (the tolerance would be large)

nothing is necessary as long as we have tests to ensure that we don't break
things

+1 for updating mne-testing-data with the correct surfaces and using assert_allclose with something like atol=1e-5

+1 for updating mne-testing-data with the correct surfaces and using assert_allclose with something like atol=1e-5

So assert_close with kwargs = dict(rtol=1e-7, atol=1e-5) passed. The generated surfaces are compared to the assumed correct surfaces (I copied the output surfaces from pytest temp folder).
If only mne/tests/test_bem.py::test_make_flash_bem needs FLASH images in testing data, I think those could be removed to shrink the size of testing data. If that sounds reasonable to you I would look into that.

@larsoner your call here.

The files do not seem so large -- the .tri are ~200 kB each, .surf ~100 kB, so we'd only be talking about ~1 MB in a ~1 GB file. Not sure it's worth it. But if you're motivated @yh-luo we could hard-code a handful of values for a random subset of (5?) vertices and spot-check those.

@larsoner No I mean the T1 files from mne-testing-data #12 and #13, that's around 50MB. These files seems to exist solely for test_make_flash_bem to work?

We definitely want to keep some tests of make_flash_bem. I thought you were proposing to remove the output files, but now it looks like you're talking about the input files like flash5.mgz so we wouldn't be able to test at all ...? Or do you mean keep just flash5.mgz and flash30.mgz, delete all the COR-* files and let those be generated ...?

No I'm proposing to remove the T1 COR files from mne-testing-data because test_flash_bem does not use it.
test_flash_bem uses sample dataset to test while test_make_flash_bem from mne/tests/test_bem.py uses testing data, which was the reason that COR-* were uploaded.
The computed surfaces from these two tests do not agree with each other. Because test_flash_bem uses both mef5d.mgz and mef30d.mgz from sample dataset, while test_make_flash_bem uses only flash5.mgz in the testing dataset.
I think if we merge the two tests, it would be odd to keep those COR files if they would not be used.
But I'm not sure if other tests use these COR-* files, so I would need to look into that.
mne/commands/tests/test_commands.py
@pytest.mark.timeout(300)  # took 200 sec locally
@pytest.mark.slowtest
@pytest.mark.ultraslowtest
@requires_freesurfer
@sample.requires_sample_data
def test_flash_bem(tmpdir):
    """Test mne flash_bem."""

mne/tests/test_bem.py
@requires_nibabel()
@requires_freesurfer('mri_convert')
@testing.requires_testing_data
def test_make_flash_bem(tmpdir):
    """Test computing bem from flash images."""

test_flash_bem uses sample dataset to test while test_make_flash_bem from mne/tests/test_bem.py uses testing data

The ultraslowtest does not run on CIs and does not run when people do make pytest so we should not rely on it. If I had to guess, anything marked ultraslowtest probably gets run a few times a year by me and maybe a couple others by accident and that's about it...

while test_make_flash_bem uses only flash5.mgz in the testing dataset.

The solution sounds like it should be to add the the flash30.mgz file to the testing data, update the testing surfaces if necessary to be the correct ones, and then get rid of any testing files we no longer need.
BTW it's possible that the flash5.mgz file is actually a resampled (to 3mm isotropic, probably?) version of the original data to keep size down and make things process faster. I know we did this with some MRIs, not sure if we did it with that one. If we did, we should do the same with the flash30.mgz, and locally compute the "correct" surfaces for the 3mm isotropic MRIs, and either add spot-check values to the testing script, or upload the correct surfaces.

The solution sounds like it should be to add the the flash30.mgz file to the testing data, update the testing surfaces if necessary to be the correct ones, and then get rid of any testing files we no longer need.

I agree with this solution. I would run some tests to see if that works.

BTW it's possible that the flash5.mgz file is actually a resampled (to 3mm isotropic, probably?) version of the original data to keep size down and make things process faster. I know we did this with some MRIs, not sure if we did it with that one. If we did, we should do the same with the flash30.mgz, and locally compute the "correct" surfaces for the 3mm isotropic MRIs, and either add spot-check values to the testing script, or upload the correct surfaces.

I'm not sure about flash5.mgz but would check this as well. May I just keep this issue open and gather more information?

Yeah no rush to fix this

So T1.mgz in testing dataset was resampled to 3mm voxel size while T1.mgz in sample dataset was not.
Because of the difference of T1.mgz and whether to use flash30.mgz, mne/commands/tests/test_commands.py::test_flash_bem and mne/tests/test_bem.py::test_make_flash_bem compute different surfaces.
But as you indicated in previous comment, test_flash_bem is decorated as ultraslowtest and does not run on CIs, test_make_flash_bem on the other hand does. I'm not sure if merge the two tests would be ok... Keep both tests may be fine for now.
If that's reasonable, I would close the issue.

It's okay to merge the two tests into one that only uses the testing data with the 3mm resampled MRI. The surfaces to test against can just be ones that you create now from those testing data knowing/assuming that our current code is correct.

The PR (#7663) is almost ready. After using resampled T1.mgz from mne-testing-data, test_flash_bem takes ~70 sec locally (current test costs ~ 200 sec). Does test_flash_bem still counts as ultraslowtest? Or should I remove that decorator in the PR?
Also, for the PR to work, mne-testing-data needs to update the flash bem surfaces as in the commit. Because test_flash_bem tests both convert_flash_mris and make_flash_bem, the COR* files in subjects/sample/mri/T1/ and subjects/sample/mri/brain/ are no longer needed. After the clean-up, the size of mne-testing-data/subjects/sample will go down to 193M (currently 216M).
I'm currently running a thorough local test to make sure nothing is broken due to the changes of the testing dataset. Is it possible to run CIs on a different branch of mne-testing-data to assure nothing would be broken due to the changes?

Does test_flash_bem still counts as ultraslowtest? Or should I remove that decorator in the PR?

Yes that's still too long for something like this I think. A better option is probably to add an Azure run that only runs the tests marked ultraslowtest. But we should do that separately.

Also, for the PR to work, mne-testing-data needs to update the flash bem surfaces as in the commit.

Let's follow the procedure here:
https://github.com/mne-tools/mne-testing-data#add-or-change-files-in-the-repo-for-use-with-mne

Is it possible to run CIs on a different branch of mne-testing-data to assure nothing would be broken?

No, but I can run tests locally on your branch before merging the mne-testing-data PR. pytest mne/ works for you and me then it should give us some confidence we haven't broken any other tests. Note that pytest mne/ will run all tests including the ultraslow ones, make pytest and CIs run pytest -m "not ultraslowtest" IIRC

No, but

Actually I take that back, you could do a lot of messing with mne/datasets/utils.py to get it to test the commit from your branch, but it's probably not worth it

No, but I can run tests locally on your branch before merging the mne-testing-data PR. pytest mne/ works for you and me then it should give us some confidence we haven't broken any other tests. Note that pytest mne/ will run all tests including the ultraslow ones, make pytest and CIs run pytest -m "not ultraslowtest" IIRC

Since test_bem.py kept failing, I figured that a bunch of bem stuff in testing dataset (e.g, sample-1280-1280-1280-bem.fif) would not match the model computed from the newly created surfaces (i.e., using both flash5 and flash30). Even when I passed -3 to mne flash_bem to skip 30-degree flip angle data, the computed surfaces are still different from the current surfaces in the testing dataset.
Then I found that flash5.mgz and flash5_reg.mgz are the same in sample dataset and testing dataset; however, flash5.mgz and flash5_reg.mgz converted by convert_flash_mris with mef05.mgz are different from the above and probably results in the discrepancy in the bem stuff. It's not clear to me why flash5.mgz provided by convert_flash_mris are different. There are too many steps/options in convert_flash_mris could produce different flash5.mgz.
In short, to compare the generated surfaces to the correct surfaces would cause too many changes in the mne-testing-data. I think the test would still be good enough after dropping the comparison of surfaces?
    kwargs = dict(rtol=1e-5, atol=1e-5)
    for s in ('outer_skin', 'outer_skull', 'inner_skull'):
        rr, tris = read_surface(op.join(subject_path_new, 'bem',
                                        '%s.surf' % s))
        assert_equal(len(tris), 5120)
        assert_equal(tris.min(), 0)
        assert_equal(rr.shape[0], tris.max() + 1)
        # Drop this part:
        # rr_c, tris_c = read_surface(op.join(subjects_dir, 'sample', 'bem',
        #                                     '%s.surf' % s))
        # assert_allclose(rr, rr_c, **kwargs)
        # assert_allclose(tris, tris_c, **kwargs)

I figured that a bunch of bem stuff in testing dataset (e.g, sample-1280-1280-1280-bem.fif) would not match the model computed from the newly created surfaces (i.e., using both flash5 and flash30). Even when I passed -3 to mne flash_bem to skip 30-degree flip angle data, the computed surfaces are still different from the current surfaces in the testing dataset.

It's likely/possible that the 1280-bem files were produced using the 1mm MRI data, which is fine. We can keep them that way. We don't need everything to be created from the same set of files -- e.g., the 1280-bem's can be created using sample data and be in the same folder with inner_skull.surf files that came from the 3 mm MRIs in testing -- we just need to know and document where they all came from. Make sense?
With that in mind:

In short, to compare the generated surfaces to the correct surfaces would cause too many changes in the mne-testing-data.

I don't think this has to be the case. The question is, what minimum set of files in mne-testing-data need to be updated to make it so that we can compare surfaces with some meaningful tolerance such that, in the future if we do something wrong / break mne_flash_bem, the test will catch it?

Actually, not that many files are influenced by this PR, which is a good news.
Aside from flash bem surfaces, only sample-320-320-320-bem.fif, sample-320-bem.fif, sample-320-320-320-bem-sol.fif and sample-320-bem-sol.fif require updates.
Since the surfaces are reconstructed from both flash5 and flash30 now, I recreate these files using the new surfaces with make_bem_model and make_bem_solution (codes below).
test_make_bem_model needs some modification because the testing values are a bit different, fixed in this PR.
Local full tests passed and CI results only showed the expected failure of test_make_bem_model. The testing dataset is branch test_flash.
BTW I did not rebase the commits for now, hoping to clarify changes.
# 3-layer
fname_bem_3 = op.join(subjects_dir, 'sample', 'bem',
                      'sample-320-320-320-bem.fif')
fname_bem_sol_3 = op.join(subjects_dir, 'sample', 'bem',
                          'sample-320-320-320-bem-sol.fif')
fname_bem_1 = op.join(subjects_dir, 'sample', 'bem',
                      'sample-320-bem.fif')
fname_bem_sol_1 = op.join(subjects_dir, 'sample', 'bem',
                          'sample-320-bem-sol.fif')
model_3 = make_bem_model('sample', ico=2, subjects_dir=subjects_dir, verbose=True, conductivity=[0.3, 0.006, 0.3])
write_bem_surfaces(fname_bem_3, model)
solution_3 = make_bem_solution(model_3, verbose=True)
write_bem_solution(fname_bem_sol_3, solution_3)

# 1-layer
model_1 = make_bem_model('sample', ico=2, subjects_dir=subjects_dir, verbose=True, conductivity=[0.3])
write_bem_surfaces(fname_bem_1, model)
solution_1 = make_bem_solution(model_1, verbose=True)
write_bem_solution(fname_bem_sol_1, solution_1)

Sounds reasonable to me, feel free to make a PR to mne-testing-data with the updated files and then a PR to MNE to use them

Thanks for the patience! I've made PRs to mne-testing-data and mne-python.

closed by #7663


[Flutter GPU] Design a mechanism to force compatibility between Flutter GPU's Dart runtime and the engine binary.

Part of https://github.com/flutter/flutter/issues/130921

Triage: This is describing a problem that is similar to the one solved by https://github.com/flutter/flutter/issues/131711.

This is mostly an engine/Flutter GPU development concern rather than an end-user concern for Flutter GPU. Once https://github.com/flutter/flutter/issues/131711 is in place and end-users of Flutter GPU are importing it from the SDK/getting it pulled from the artifacts, the version will always be compatible with the Engine build.
However, it'll still be easy to wind up with the wrong version while running an app that uses Flutter GPU against the local engine. When doing a local engine build, the flutter_gpu package needs to be given an explicit path into the local engine directory.
One way to implement something like this:

Have a Dart file in the Flutter GPU package called e.g. _version.dart, which contains something like this by default:
const String _kFlutterGPUVersion = "DEVELOPMENT";

After GN copies the Flutter GPU package into the artifacts, this file can be overridden to contain a commit hash:
const String _kFlutterGPUVersion = "a236b8462a230d004d3ba1359376688f3c4a9c67";

Always compile a const char* string symbol containing the commit hash into the engine binary.

Add a parameter to GpuContext._initializeDefault() to take the kFlutterGPUVersion string.

Compare it to the engine string in InternalFlutterGpu_Context_InitializeDefault. If the version string is DEVELOPMENT, don't perform the check. If the versions don't match, return Flutter GPU version "%s" mismatches the Flutter Engine build commit "%s"!, causing it to throw an exception.


⚠ Bofrost.at has degraded performance

In 589f94c, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 875 ms

Resolved: Bofrost.at performance has improved in 52feeb9.


Podspec

It'd be great if you published to Cocoapods

Thank you for the request.
https://cocoapods.org/pods/Kml.swift

Thank you


Fix Python 3.4 NumPy Accelerate polyfit error

Trying to work around the Travis CI failure for Python 3.4 on MacOS with Accelerate NumPy by skipping the test.

Ready for review, PTAL. Verified on Travis by temporarily enabling the Python 3.4. PR build.

Simplified, PTAL.

LGTM.


Proxy classes/attrs to the stub element in SSR scenarios

Fixes #34

After taking a closer look I'm not sure if this is going in the right direction.
<LazyHydrate :triggerHydration="hydrated" class="lazy-class-outer">

    <button @click="onClick">
      Click me
    </button>

</LazyHydrate>

I agree that the renderless nature of <LazyHydrate> makes this example confusing for somebody who expects <LazyHydrate> to render a wrapper
. But I think, because <LazyHydrate> is renderless it makes no sense to apply lazy-class-outer onto <LazyHydrate>.
In my opinion there are two ways how to deal with it:

Ignoring lazy-class-outer class.
Proxying lazy-class-outer to
.

Both ways are wrong in my opinion. I think there is no right way how to handle this gracefully.
Why do I think both ways are wrong: as I see it, the only reason why to put a class on <LazyHydrate> is because the developer who does it thinks that <LazyHydrate> does render a
.
The expected output in such case is the following:

    <button>
      Click me
    </button>

But this is not what <LazyHydrate> is actually rendering. But a developer who applies lazy-class-outer onto the outer element most likely does this because they want to apply CSS styles which may rely on a HTML structure like you see above. Otherwise, again, it makes no sense to apply lazy-class-outer onto <LazyHydrate> in the first place.

I think applying a class on <LazyHydrate> is an error and should not be encouraged.
I think there is no right way how to handle this so everybody would get the outcome they'd expect.

Possible solutions for this project:

Log a console warning when attributes or classes are applied onto <LazyHydrate>.
Add a chapter in the README explaining that attributes and classes do not work on <LazyHydrate>.

Possible solutions for your use case:
If the renderless nature is confusing to your team, you can use https://github.com/znck/lazy-hydration It works pretty much the same as this package (in fact most of my code is based on the work of @znck) with the exception that this lazy-hydration is not renderless and renders a wrapper
 which means applying classes on it should work as expected (although I've not tested it).
Thanks for your contribution!

Thank you for the thorough response.  I see your point and it makes sense when viewing LazyHydrate as a true renderless component that effectively disappears upon hydration.  So I agree that both of the solutions, when viewing it this way do feel wrong.
I think both of your solutions make sense, logging a console warning when LazyHydrate is being used incorrectly, and adding a small section to the README.  I can update this PR with those 👍

@maoberlehner Updated with a console warning and a new section in the README 👍


Update "Error Handlers" part in usage.rst

Update "Error Handlers" part in usage.rst because of https://github.com/silexphp/Silex/commit/e96f9be8fda96193313bb655d63b061d6d4d7c4d#diff-9460b640f6466d5890f37f7caf262024R52

Thank you @freepius.


INTERNALERROR: KeyError: 'startdir'

Hi, I'm using py.test and django. Py.test seems to use pluggy behind the scenes.
Can anyone shed some light on this error?
$ py.test
Test session starts (platform: darwin, Python 3.5.2, pytest 3.0.2, pytest-sugar 0.7.1)
INTERNALERROR> Traceback (most recent call last):
INTERNALERROR>   File "/Users/jon/.virtualenvs/webapp/lib/python3.5/site-packages/_pytest/main.py", line 94, in wrap_session
INTERNALERROR>     config.hook.pytest_sessionstart(session=session)
INTERNALERROR>   File "/Users/jon/.virtualenvs/webapp/lib/python3.5/site-packages/_pytest/vendored_packages/pluggy.py", line 724, in __call__
INTERNALERROR>     return self._hookexec(self, self._nonwrappers + self._wrappers, kwargs)
INTERNALERROR>   File "/Users/jon/.virtualenvs/webapp/lib/python3.5/site-packages/_pytest/vendored_packages/pluggy.py", line 338, in _hookexec
INTERNALERROR>     return self._inner_hookexec(hook, methods, kwargs)
INTERNALERROR>   File "/Users/jon/.virtualenvs/webapp/lib/python3.5/site-packages/_pytest/vendored_packages/pluggy.py", line 333, in <lambda>
INTERNALERROR>     _MultiCall(methods, kwargs, hook.spec_opts).execute()
INTERNALERROR>   File "/Users/jon/.virtualenvs/webapp/lib/python3.5/site-packages/_pytest/vendored_packages/pluggy.py", line 596, in execute
INTERNALERROR>     res = hook_impl.function(*args)
INTERNALERROR>   File "/Users/jon/.virtualenvs/webapp/lib/python3.5/site-packages/pytest_sugar.py", line 217, in pytest_sessionstart
INTERNALERROR>     lines = self.config.hook.pytest_report_header(config=self.config)
INTERNALERROR>   File "/Users/jon/.virtualenvs/webapp/lib/python3.5/site-packages/_pytest/vendored_packages/pluggy.py", line 724, in __call__
INTERNALERROR>     return self._hookexec(self, self._nonwrappers + self._wrappers, kwargs)
INTERNALERROR>   File "/Users/jon/.virtualenvs/webapp/lib/python3.5/site-packages/_pytest/vendored_packages/pluggy.py", line 338, in _hookexec
INTERNALERROR>     return self._inner_hookexec(hook, methods, kwargs)
INTERNALERROR>   File "/Users/jon/.virtualenvs/webapp/lib/python3.5/site-packages/_pytest/vendored_packages/pluggy.py", line 333, in <lambda>
INTERNALERROR>     _MultiCall(methods, kwargs, hook.spec_opts).execute()
INTERNALERROR>   File "/Users/jon/.virtualenvs/webapp/lib/python3.5/site-packages/_pytest/vendored_packages/pluggy.py", line 593, in execute
INTERNALERROR>     args = [all_kwargs[argname] for argname in hook_impl.argnames]
INTERNALERROR>   File "/Users/jon/.virtualenvs/webapp/lib/python3.5/site-packages/_pytest/vendored_packages/pluggy.py", line 593, in <listcomp>
INTERNALERROR>     args = [all_kwargs[argname] for argname in hook_impl.argnames]
INTERNALERROR> KeyError: 'startdir'

Could you provide some more information, such as whcih pytest version are you using and how are you invoking pytest? That might shed some light into the matter.

Sure, sorry about that! I've updated the stacktrace accordingly.

Hmm it seems there's a mismatch somewhere between a hook declaration and a hook implementation... the only pytest builtin hook with a startdir parameter is pytest_report_header. Any chance there's a pytest_report_header hook somewhere in this code?
Is this code published somewhere so people can try to reproduce it?

Here's an example, sorry it's such a big project but it's the quickest way to get where I am now.
It appears to start after the addition of either python-selenium or pytest-cov...

Okay, after further testing it's definitely after the addition of pytest-selenium. Thanks for the help thus far, cheers!

OK, glad you found it!


Update 40-Combination-Sum-II.py

File(s) Modified: 40-Combination-Sum-II.py
Language(s) Used: python
Submission URL: https://leetcode.com/problems/combination-sum-ii/

Thanks, @GraydenH!


Add Diagonal of R Plot

Like the Bokeh plot, add a Diagonal of R graph that will show how quickly each cluster's rank falls. Make it an option that can be toggled on and off, with the default being off.

Closed by #16.

The Diagonal of R plot needs a semilogy scale for the y-axis.
Here is the link to adding log-axes in plotly: https://plot.ly/javascript/log-plot/

Reference Commit:https://github.com/tsonthalia/spaND-Vis/commit/0a04ce243c478c3a7b506ac526842463984ae538
New Features

Semilogy Scale for Y-Axis (Log-Axis)
Click on Line in Diagonal of R plot to isolate that cluster in the main Cluster plot
Double Click on Diagonal of R plot to reset


Added syntax for the structurizr DSL

structurizr DSL is used in structurizr, which is a tool that allows to
model your software architecture according to the c4 model
(https://c4model.com/)
The default file extension is .dsl but it clashes with an existing (but
non-compatible) filetype.
I've added the following test, but I'm not expert in vimscript:
" dsl
au BufNewFile,BufRead *.dsl
	\ if getline(1) =~ '^<\!' |
	\   setf dsl |
	\ else |
	\   setf structurizr |
	\ endif

we test if the .dsl file starts with <!, in which case it would be a dsl file, otherwise it would be structurizr
The language reference can be found here:
https://github.com/structurizr/dsl

Shouldn't the dsl filetype really be dsssl?  Is it worth changing at the same time?

Shouldn't the dsl filetype really be dsssl? Is it worth changing at the same time?

I think yes, but I'm no expert on that matter. In any case, I guess that should go into a separate PR then.

Hi @brammool is there anything left for me to do in order to get the missing syntax file merged?
Cheers!

Hi @brammool is there anything left for me to do in order to get the
missing syntax file merged?

It will be included in the next runtime files update.
--
Sometimes I think the surest sign that intelligent life exists elsewhere
in the universe is that none of it has tried to contact us.     (Calvin)
/// Bram Moolenaar -- @.*** -- http://www.Moolenaar.net   \
///                                                                      \
\\        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

It seems that the patch that have been applied on master does not include the syntax file @brammool .

It was included with 89a9c159f23fb7b3e24e6d09068adfc24a73afcb
Runtime files get updated periodically in batches.

My bad, I have found it first time I searched for it. Thanks!


Update MinIO doc for 2.0

Docs were straightforward. I had to follow MinIO's getting started page to get everything setup.

Changes are mainly small typos and changing 'Minio' to 'MinIO' to match their spelling

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/4102/
Test FAILed.

jenkins, test this please

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/4103/
Test FAILed.

jenkins, test this please

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/4107/
Test FAILed.

jenkins, test this please

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/4108/
Test FAILed.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/4109/
Test FAILed.

jenkins, test this please

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/4130/
Test PASSed.

@ZacBlanco PTAL, thanks

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/4141/
Test FAILed.

jenkins, test this please

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/4143/
Test PASSed.

alluxio-bot, merge this please

Don't forget to cherry pick this

alluxio-bot, cherry-pick this to branch-2.0 please.


doc: add more docs to Init.Prelude

I'm not done yet, but seeing as I managed to set up a race condition with Leo's docs I thought I would put what I have so far and update it as I go.

@digama0 Could you please fix the tests?


convert properties in set selected label from snake-cased to camel-cased

What changes are proposed in this pull request?
convert properties in set selected label from snake-cased to camel-cased
How is this patch tested? If it is not, please explain why.
Using a test operator to set label of a sample
Release Notes
Is this a user-facing change that should be mentioned in the release notes?

[ ] No. You can skip the rest of this section.
[x] Yes. Give a description of this change to be included in the release
notes for FiftyOne users.

Fix built-in operator set selected label not working when label properties are snake-cased
What areas of FiftyOne does this PR affect?

[x] App: FiftyOne application changes
[ ] Build: Build and test infrastructure changes
[ ] Core: Core fiftyone Python library changes
[ ] Documentation: FiftyOne documentation changes
[ ] Other

Summary by CodeRabbit

Bug Fixes

Improved label formatting in the SetSelectedLabels function to handle null values and ensure consistent data structure.

Re-opened https://github.com/voxel51/fiftyone/pull/4269 with the different base as the original base no longer exists


Swagger generation should be automatically part of the build if swagger annotations are included?

Description:
If we have kubernetes or docker annotations in .bal files, then the k8s or dockerfile is automatically generated as part of the compilation. However, the same behaviour doesn't seem to happen with Swagger, and it is necessary to run "ballerina swagger export". It would be more consistent if the annotations caused the generation to happen
Steps to reproduce:
Add a swagger annotation to .bal and build.
Affected Versions:
All
OS, DB, other environment details and versions:
Any
Related Issues (optional):
Suggested Labels (optional):
Suggested Assignees (optional):

The current tool supports several approaches for generating OpenAPI specifications. Providing annotation for generating swagger files will interact with several uses in the tool, which leads to making the tool depend on other Ballerina commands ex: bal run and it will more complex. Therefore closing this issue since we already provide options to generate spec without using the CLI command.


Kubernetes Support

So I've been spending quite some time trying to deploy on kubernetes. It works and all nodes have persistent volumes with stateful sets deployment. Now only problem is that upon a pod restart, its data is preserved but the pod IP is changed. With stateful deployments, all pods replicas  would have a unique static hostname tied to the cluster ip that never change till you delete the whole cluster. So I tried using it and it successfully encodes it and joins a network under that hostname but when the nodemanager is launched it throws an exception saying nat encountered an invalid ip. so it never ends booting up
Any thought on where in the code I can change this so it doesn't throw this error when it encounters a hostname rather than an ip?

@majd1239 Quorum started providing DNS support from v2.1.1 onwards. Can you check with versions of Quorum Maker supporting v2.1.1+


SetRequestInterceptionAsync causes GoToAsync to hang

Using version 1.14.
When setting SetRequestInterceptionAsync(true) before GoToAsync, the browser hangs.  The page does not even attempt to load and a timeout error occurs.  The Request event never fires.
Related Issue:
https://github.com/kblok/puppeteer-sharp/issues/657

Appears to be user error.  Not failing now.


Updated management with insecure runtime reqs

Added images and steps to allow content for insecure runtime

[CI] Staging environment is at http://cap-staging-docs.codefresh.io.s3-website.us-east-1.amazonaws.com/cap-insecure-runtime/docs/


Support using the EC2 GetPasswordData API as a means of getting the WinRM password

Today, when provisioning a Windows AMI, the WinRM username/password needs to be hard coded and well known prior to performing a vagrant up.
It'd be nice if there was a way to have the vagrant-aws plugin dynamically fetch the EC2-generated administrator password (via GetPasswordData) to be used to authenticate to Windows AMIs via WinRM.
It seems like with this functionality, Windows AMIs would have some parity with Linux AMIs with respect to shell authentication.

Here is my attempt, I'm having trouble with WinRM timing out and not being able to establish a connection with the booted instance on EC2
I have created a security group called 'vagrant' which opens WinRM ports
# -*- mode: ruby -*-
# vi: set ft=ruby :
Vagrant.configure("2") do |config|
  # Enable dotEnv
  config.env.enable

  # Set default communicator
  config.vm.communicator = 'winrm'

  config.winrm.username = 'Administrator'

  config.vm.provider :aws do |aws, override|

        aws.security_groups = ['vagrant']
        aws.access_key_id = ENV['AWS_ACCESS_KEY']
        aws.secret_access_key = ENV['AWS_SECRET_KEY']
        aws.keypair_name = "vagrant-ec2"

        # windows server 2012 with SQL Server Web
        aws.ami = "ami-41fca024"
        aws.instance_type = "m3.medium"

        aws.tags = {
            "Name" => "EC2 Windows 2012 R2 Instance",
        }

        override.vm.box = "dummy"
        override.vm.box_url = "https://github.com/mitchellh/vagrant-aws/raw/master/dummy.box"

        # Figured this was an easy way of getting the instance ID
        instance_id = File.open(".vagrant/machines/default/aws/id", "r").first

        override.winrm.username = 'Administrator'

        # using the ec2 cli i can get the password for the instance
        override.winrm.password = exec "ec2-get-password -k ./vagrant-ec2.pem #{instance_id}"

    end
end

@shaned24 Cool!
I'd love this functionality to be built in to the vagrant-aws plugin.
Towards this end, here's my attempt at augmenting the vagrant-aws plugin with another plugin (I wrote it yesterday and published it this morning): https://github.com/rafd123/vagrant-aws-winrm
I'd love any feedback (particularly since I'm new to Ruby, let alone vagrant plugin development).
If this holds water, the next action would be to submit a vagrant-aws pull request with the same functionality.


refactor(config): Add build_only_locale option

Closes #262
As discussed, I added a different option that allows to lock the build to a single language using environmental variables.
It's validated in the config class.
I added documentation about it too, I hope it's in the correct place.

version 1.2.0 is out!


Adding new rule for enforcing new lines at the end of file, fixes #89

Adding new rule MD046 to check for files not ended with new line. Trying to implement new rule issue #89. I also adjusted tests and .md sample files to conform with this rule where necessary.
Please have a look and check if this would be good to merge in. I am happy to get feedback and suggestions.

Coverage remained the same at 100.0% when pulling 12a51da282b7f365a6790dc6f9529fce4794865d on KitoW:master into 827e1acb5612ae2b02ec5b6fa799fd3a2421b2b4 on DavidAnson:master.

Coverage remained the same at 100.0% when pulling 12a51da282b7f365a6790dc6f9529fce4794865d on KitoW:master into 827e1acb5612ae2b02ec5b6fa799fd3a2421b2b4 on DavidAnson:master.

Coverage remained the same at 100.0% when pulling 12a51da282b7f365a6790dc6f9529fce4794865d on KitoW:master into 827e1acb5612ae2b02ec5b6fa799fd3a2421b2b4 on DavidAnson:master.

Coverage remained the same at 100.0% when pulling 12a51da282b7f365a6790dc6f9529fce4794865d on KitoW:master into 827e1acb5612ae2b02ec5b6fa799fd3a2421b2b4 on DavidAnson:master.

Thanks, I’ll review this tonight! One quick first bit of feedback: could you please change to MD047 to avoid conflict with an unmigrated MD046 from the Ruby version?

I left one more comment to clarify something I was vague about. If you don't get to it, don't worry. I'm in the middle of a set of changes to next branch now, but will merge this PR once I'm done with that in a few days. Thanks very much for all the work here!

Thanks! I’ll get to this shortly.

I've rebased this into next branch as a977d0dcbcbf8af5a60c003bb565ab43e65cd82b. Thanks again!


Istio 1.4.7 release does not contain ISTIO-SECURITY-2020-004 fix

The release notes for Istio 1.4.7 state that the security vulnerability relating to Kiali has been fixed; however, the commit to fix this is not present in the release.
I have installed Istio 1.4.7 using Helm with Kiali 1.15.2 (and other compatible Kiali versions) but the error seen in this issue remains: https://github.com/kiali/kiali/issues/2624
see commit: https://github.com/istio/istio/commit/38a90fd6760144382cf93611524b144afac4c47e
Which is present in the 1.5.1 release:
https://istio.io/news/releases/1.5.x/announcing-1.5.1/
https://github.com/istio/istio/compare/1.5.0...1.5.1
but not the 1.4.7 release:
https://istio.io/news/releases/1.4.x/announcing-1.4.7/
https://github.com/istio/istio/compare/1.4.6...1.4.7
Have I made a mistake, or has the security fix been accidentally left out of the 1.4.7 Istio release?

The istioctl installer was fixed. If you installed with the old helm charts, then it wasn't fixed there. I thought the helm charts were deprecated. In any event, add these two lines to the kiali configmap template in the helm chart:
login_token:
  signing_key: {{ randAlphaNum 10 | quote }}

I don't know where these helm charts are now - they appear to have been deleted from the install/ directory which is where they used to be.

Thanks for the response. I see, we haven't tested using Istioctl but I can't see any commit between 1.4.6...1.4.7 which whould have resolved the issue?
I can see from the docs that Istio is in the process of deprecating using helm to install, but some pages refer to this as a work in process and others say it will happen in future, so we expected the security fix to be added there as well.
I understand that these things change quickly though; thank you for offering a potential solution. We will be migrating to use Istioctl shortly to avoid any future issues.
Thanks,
Elliot

Fixed by #23445
And https://istio.io/latest/news/support/announcing-1.4-eol-final/


chore: added new walkingPal logo and mockup changes

added new walkingPal logo and mockup changes
Proposed Changes
frontend screenshots

added: new walkingPal logo
changed: mockups


[5.10] Support resolving links in @DeprecationSummary content (#784)

Cherrypick of #784
Explanation: This adds support for resolving links in a symbol's @DeprecationSummary content.
Scope: Local and external links in content in inside symbol's optional @DeprecationSummary directive.
Issue: rdar://120374614
Risk: Low.
Testing: Added tests and ran the existing automated tests.
Reviewer: @sofiaromorales

@swift-ci please test

The CI failed because we haven't cherry-picked the change that updated the allowed years in the check-source script for the 5.10 release. #791 fixes this.

@swift-ci please test


How to deselect the active state of mat tab angular material 2

When having tabs, always the first tab is active.
Hi is there any way to have tabs without the active state in the beginning. I would like the active state to be added once cliked. can we overwrite the default behavior?  I am working with angular material 2 and angular 4.
I tried so far the selected index but it did not work.

@crisbeto

Thank you for your answers. however I have another questions related to the tabs.  I have a strange behavior in my tabs. let me give you a picture of what i meant. I have  a tabs component  which i am using for both view mode and add mode. the strange thing is that when i am in view mode i can see the content of my first default active tab but when i navigate to the add mode , i am not able to see the content although the tab is active  and i can see that content is loaded but just not showing. the strangest part is that after i navigate to the second tab and come back to the original first tab , now my content is showing. do you know why? I am assuming that because i am using the same tab and only views change. do you agree with me? it is  a strange behavior? Thank you.


fix bug in calculate_bond_data function

previous version used a dr_cutoff of 1 regardless of what was passed.
Thanks to @MaxiLechner for pointing this out!

Awesome, thanks for noticing this! Sorry about the delay :P.


Add logic to retrieve server current version

While studying the lib I took the opportunity to implement a helper method so we can "easily" track version changes. I believe this can be useful if one use this lib in production and cannot afford long downtimes during operation regarding to this version changes.

You import ("github.com/joaopaulosr95/go-whatsapp") is from a different domain

You import ("github.com/joaopaulosr95/go-whatsapp") is from a different domain

Thanks for pointing this out @Deewai, I actually didn't notice it 😞

You import ("github.com/joaopaulosr95/go-whatsapp") is from a different domain

Thanks for pointing this out @Deewai, I actually forgot to change it back after testing 😞


Native style prop clashes with FormattedNumber's style

The style property passed to all wrapped components within app/components clashes with FormattedNumber from react-intl as the latter expects an style property that specifies how to handle the number formatting (see: https://github.com/yahoo/react-intl/wiki/Components#formattednumber).

Pull request?

I'm not sure how to fix it. This is an edge case so I'm assuming we'd prefer having style for actual style as opposed to renaming it. The other option would be to make a custom component (not wrapped by native() for FormattedNumber.

ok