Fix incorrect types in the configuration of ThrottledTaskRunnerImpl

which are since the switch to OSGI r6 annotations and configuration; report in #1652 by @Sc0rpic0m

Pull Request Test Coverage Report for Build 3593

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

Totals

Change from base Build 3563:
0.0%

Covered Lines:
10076

Relevant Lines:
22997

💛  - Coveralls


Update README.md

hi eddie i want to participate in hacktoberfest so i watched your videos and before participating i want to pratice here and also thanks for the valuable information
Related issue

What changes does this PR do?
Screenshots (If any)
Questions

Hi Eddie i want to participate in hacktoberfest so i watched your videos and before participating i want to practice here and also thanks for the valuable information


WorkaroundKeyError message should tell you how to debug your import

From pairing w/ @juliasilge, Users can experience a WorkaroundKeyError message for two cases:

The path is incorrect (e.g. nothing to import)
Some kind of static analysis issue occurred

For case (1), let's ensure the error message gives exactly what it tried to import (and mentions it couldn't find it). For (2) let's mention this will be the issue if you are able to import the object.

implemented in https://github.com/machow/quartodoc/releases/tag/v0.3.5


Question about releases

This is not an issue, just a question so I can understand Go better.
In the Releases the most recent release is 3.7.2.
If I do
go get github.com/BTBurke/caddy-jwt
Go gets v3.7.1.

<EMAIL_ADDRESS>
Why is that?

Actually I think I screwed up and 3.7.1 and 3.7.2 point to the same commit.
On Jul 17, 2019, 14:13 -0400, xombiemp<EMAIL_ADDRESS>wrote:

This is not an issue, just a question so I can understand Go better.
In the Releases the most recent release is 3.7.2.
If I do
go get github.com/BTBurke/caddy-jwt
Go gets v3.7.1.

<EMAIL_ADDRESS>Why is that?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.


MAINT, CI: new Cython issue

Observed in the Travis CI of #12036 with bleeding edge Cython the cause based on my local reproducer. Locally, I did python -m pip install --pre cython==3.0a4 then build SciPy and observe something similar to CI:
Processing scipy/ndimage/src/_cytest.pyx
Processing scipy/ndimage/src/_ni_label.pyx
Processing scipy/optimize/_bglu_dense.pyx

Error compiling Cython file:
------------------------------------------------------------
...

        with nogil:
            while PyArray_ITER_NOTDONE(iti):
                # Optimization - for 2D, line_buffer becomes next iteration's
                # neighbor buffer
                if output.ndim == 2:
                        ^
------------------------------------------------------------

_ni_label.pyx:313:25: Calling gil-requiring function not allowed without gil
Processing scipy/optimize/_group_columns.pyx
Traceback (most recent call last):
  File "/mnt/c/Users/treddy/github_projects/scipy/tools/cythonize.py", line 305, in <module>
    main()
  File "/mnt/c/Users/treddy/github_projects/scipy/tools/cythonize.py", line 301, in main
    find_process_files(root_dir)
  File "/mnt/c/Users/treddy/github_projects/scipy/tools/cythonize.py", line 290, in find_process_files
    for result in pool.imap_unordered(lambda args: process(*args), jobs):
  File "/mnt/c/Users/treddy/github_projects/spack/opt/spack/linux-ubuntu16.04-broadwell/gcc-6.5.0/python-3.7.4-65ohvllfnv7y2kaul5mcz3hg7cppcbby/lib/python3.7/multiprocessing/pool.py", line 748, in next
    raise value
  File "/mnt/c/Users/treddy/github_projects/spack/opt/spack/linux-ubuntu16.04-broadwell/gcc-6.5.0/python-3.7.4-65ohvllfnv7y2kaul5mcz3hg7cppcbby/lib/python3.7/multiprocessing/pool.py", line 121, in worker
    result = (True, func(*args, **kwds))
  File "/mnt/c/Users/treddy/github_projects/scipy/tools/cythonize.py", line 290, in <lambda>
    for result in pool.imap_unordered(lambda args: process(*args), jobs):
  File "/mnt/c/Users/treddy/github_projects/scipy/tools/cythonize.py", line 229, in process
    processor_function(fromfile, tofile, cwd=path)
  File "/mnt/c/Users/treddy/github_projects/scipy/tools/cythonize.py", line 94, in process_pyx
    raise Exception('Cython failed')
Exception: Cython failed

There's another one here too, and possibly a few more in the code base:
Error compiling Cython file:
------------------------------------------------------------
...
                if facet.coplanarset:
                    for i in range(qh_setsize(self._qh, facet.coplanarset)):
                        point = <pointT*>facet.coplanarset.e[i].p
                        vertex = qh_nearvertex(self._qh, facet, point, &dist)

                        if ncoplanar >= coplanar.shape[0]:
                                               ^
------------------------------------------------------------

qhull.pyx:654:48: Calling gil-requiring function not allowed without gil

Yep, those two Travis CI entries are using cython==3.0a4 as well. Anyway, at least the local reproducer is pretty fast/at start of build process.

I'm not planning to work on this this evening, so someone else should feel free of course.

Cc @mattip here as well, since he probably can point out the right fix easily


filtering a float with decimal point does not work

Filtering should work like the following:
All data: 5.233, 5, 3.2, 5.25
Input 5.233: 5.233
Input 5.2: 5.233, 5.25
Input 5:  5.233, 5.25

For now we will support exact match. We will introduce range queries as a separate feature.


Inferring annotated lambdas

What would be a good way to infer annotated lambdas?
Currently I am doing the following, using DeBruijn indeces/levels (in TypeScript, I hope it's still readable):
if (tm.tag === 'Abs') {
    // 1. check that the parameter type is valid
    check(ts, vs, k, tm.type, VType);
    // 2. evaluate the parameter type
    const type = evaluate(tm.type, vs);
    // 3. typecheck the body
    const rt = synth(extendV(ts, type), extendV(vs, VVar(k)), k + 1, tm.body);
    // 4. check that the parameter is not used in the body (if the parameter is erased)
    if (tm.meta.erased && erasedUsed(0, tm.body))
      return terr(`erased argument used in ${showTerm(tm)}`);
    // 5. return the Pi type, (parameter type) -> body type
    return evaluate(Pi(tm.meta, tm.type, quote(rt, k + 1, false)), vs);
}

This works great, but I am concerned about the quoting when constructing the pi type. How would you type check annotated lambdas? To avoid quoting I'd have to turn the return type rt in to a closure for the Pi, can that be done?

I see in https://github.com/AndrasKovacs/icfp20sub/blob/master/fcif/Elaboration.hs that you also quote the body of the pi when elaborating an annotated lambda, so I assume you don't know a better way.

liftVal is not efficient, you're right about that. In fcif I didn't optimize performance. The fastest way I know is to use local eval/quote with glued evaluation, and also do inference for n-ary lambdas, so that we don't have to liftVal on each lambda, and only do one lifting over multiple binders.

I see. So there's no way to avoid the quote, but there are ways to minimize the impact. Thanks!


Configure DNS routing domains when using systemd-resolved on Linux

ziti-edge-tunnel currently sets itself up as a DNS server with systemd-resolved, but it doesn't set the "routing domains" to the specific domains that are being intercepted. This means that:

systemd-resolved sends DNS queries for ziti domains to all DNS servers that are configured with systemd-resolved

corollary: if a ziti domain happens to be available in public DNS, systemd-resolved may choose the public DNS server's response over the one that ziti-edge-tunnel provides

systemd-resolved sends all DNS queries to ziti-edge-tunnel's DNS server, even though ziti-edge-tunnel probably won't have an answer

this can make a decent amount of busy work for ziti-edge-tunnel, which does all of its processing in a single thread

Setting the routing domains for the zitiN interface to the list of intercepted domains would solve these problems. This would also match the behavior that we see with the Desktop tunnelers.

We could hard code that behavior in ZET and it would be useful. Still, if ZET provided a configuration hook or plug-in runner for this, then I can imagine how useful that would be for both:

configuring systemd-resolved's routing domains
configuring CoreDNS's forwarding namespaces

For example, if a domain name is added or removed to ZET's list of intercepts, it could sort and run the scripts in /opt/openziti/etc/domain-hooks.d/ with a parameter scheme like {include_hook} [add|del] DOMAIN.


Scrabble Score Test

One of the tests for the Scrabble Score exercise looks like this:
  def test_scores_are_case_insensitive
    assert_equal 41, Scrabble.new('oxyphenbutazone').score
  end

If this is testing it will still calculate scores for words with uppercase and lower case letters, then shouldn't the test look something like this?
  def test_scores_are_case_insensitive
    assert_equal 41, Scrabble.new('OxypHenButazoNe').score
  end

Ah, I think we used to have an all-caps word that was impossible in the regular Scrabble game. We swapped it out with a word that does exist, but forgot to make it all caps.
@kotp What do you think, should we change this to 'OXYPHENBUTAZONE'? (We don't need any lowercase letters, since the other tests verify that).

The old word was capitalized, and an illegal length.  This test uses a valid length word, but no test specifically actually addresses the illegal length that I noticed.
#273 should be more applicable to the actual intent of the test.

Thanks @durrellchamorro for bringing this to our attention.

No problem.


fs: shell: add dump file command

Add command to dump the content of a file.
Signed-off-by: Shlomi Vaknin<EMAIL_ADDRESS>

@shlomow Can you summ-up how this differ from fs read command?

Only the format of the printing, as fs read print also hex and ascii. As @de-nordic suggested, it makes sense to call this cat. I am planning to extend the implementation to support receiving multiple paths and printing them, so it will be more close to cat. Maybe the read command should be renamed to hexdump

@shlomow Then I thin it make sense to extend current fs read command and parametrize it more.

@shlomow Then I thin it make sense to extend current fs read command and parametrize it more.

IMHO we should keep them separate. This way we can, in the future, add kconfig menu to enable/disable commands and shred some unused functions off the binary; someone may want to use cat to view logs or some text output from something, but may not need read/write.
The cat, on the other side, could altered operate on lines, in which case it could get additional options, in the future, like starting line, etc.

@nvlsianpu @de-nordic I updated this pr following the discussion above. Can you please review the changes?

@nvlsianpu @de-nordic ping

@nvlsianpu Can you please review this PR? :)


Does this actually work at all with react-router 4?

Just curious. It took incredible effort to figure out how to properly implement react-router, and more specifically, react-tap-event-plugin. The documentation is trash. Yours is sufficient, but just barely.
Has anyone used this with react-router 4 successfully?
Am almost at the point of scrapping all these user created systems, and just implementing the whole thing myself from ground up. Can't find a single working system that just straight up works.

Subscribing

FYI I was able to get it working. Man the documentation on all of these packages makes this tough.
There are tons of issues I had going on.  But I'll see about working up a repo for anyone interested , with a working sample. It will rely upon modified accounts-ui and accounts-material-ui forks in my profile, which are comprised of merged non-existing pull requests from existing forks of all the people that forked these repos already to fix issues the author won't. Will reply back once I have that prepped and upped.

Hey, I would be interested 😊

The client we were hired by to develop a project for, ended up scrapping their ambition/funding before we got anywhere significant.
So this boilerplate is about a year old project that we briefly worked on for a couple weeks.
It's not production level quality, definitely dev sandbox only.
Nevertheless, here it is:
https://github.com/ensemblebd/meteor-react-boilerplate-devops
The adjusted repo's for a functional auth system
You'll notice the usage of the local "packages" folder in root, as per meteor's recommendation for overriding packages published to atmosphere.
And so the modified packages are (as per readme usage, and git submodules):
https://github.com/ensemblebd/accounts-ui
https://github.com/ensemblebd/accounts-material-ui
I won't be able to provide any support, but hope it helps.
Just now gave it a good once-over (fresh install from nothing to boot) before pushing up to public repo. And it works still.
Please note:
It uses smtp for email, and can only register on mobile app (per it's original intended app design).
Use Robo3T to modify user role post-registration to become an admin (or register<EMAIL_ADDRESS>which it checks for, and then you can use the website login (server side admin area).  Grep/replace "mycompany.com" to your own intended domain.
Or just edit the settings.json and switch the flag for "forceMobileInDev" to true..  then open up http://localhost:3000  and chrome scale it down to look like a phone.
Side notes
FYI I was using the JetBrains IDE for this (Webstorm). **On Windows. ** If you don't, the npm commands work fine too..  On windows.
Last I touched this, it compiled fine, ran fine, and tested fine on Android and web. And supports building to APK for publishing on app store if you have you ssh keys configured.
 Check the ./buildrun/ folder.
IOS was on the todo list, but I don't see why it wouldn't work for it.
The facebook and google oauth is barely functional, so you might need to tweak the local repo's a bit. But database auth works fine.
Just fork those, and replace the git submodules in your project. Tweak way.
Retrospect
Am honestly pretty underwhelmed by the accounts-ui system. Going forward I'd probably choose to use something else.
Hopefully i nuked/sterilized all the company and client stuff in there. Think i got it all.

Thanks for sharing!


How to use syzygy?

I referred to https://github.com/googleprojectzero/winafl/blob/master/readme_syzygy.md ,but an error occurred:
D:\FuzzTools\winafl\bin32>instrument.exe --mode=afl --input-image=test_static.exe --output-image=test_static.instr.exe --force-decompose --multithread --cookie-check-hook
[0824/142620:INFO:application_impl.h(46)] Syzygy Instrumenter Version <IP_ADDRESS> (190dbfe).
[0824/142620:INFO:application_impl.h(48)] Copyright (c) Google Inc. All rights reserved.
[0824/142620:INFO:afl_instrumenter.cc(116)] Force decomposition mode enabled.
[0824/142620:INFO:afl_instrumenter.cc(122)] Thread-safe instrumentation mode enabled.
[0824/142620:INFO:afl_instrumenter.cc(128)] Cookie check hook mode enabled.
[0824/142620:INFO:pe_relinker_util.cc(336)] Input PDB not specified, searching for it.
[0824/142620:INFO:pe_relinker_util.cc(362)] Using default output PDB path: D:\FuzzTools\winafl\bin32\test_static.instr.exe.pdb
[0824/142620:INFO:pe_relinker.cc(138)] Input module : D:\FuzzTools\winafl\bin32\test_static.exe
[0824/142620:INFO:pe_relinker.cc(139)] Input PDB    : .\test_static.pdb
[0824/142620:INFO:pe_relinker.cc(140)] Output module: D:\FuzzTools\winafl\bin32\test_static.instr.exe
[0824/142620:INFO:pe_relinker.cc(141)] Output PDB   : D:\FuzzTools\winafl\bin32\test_static.instr.exe.pdb
[0824/142620:INFO:pe_relinker.cc(57)] Decomposing module: D:\FuzzTools\winafl\bin32\test_static.exe
[0824/142620:ERROR:pe_file_parser.cc(1175)] Unknown version of the IMAGE_LOAD_CONFIG_DIRECTORY structure (160 bytes), might be because you're using a new version of the Windows SDK.
[0824/142620:ERROR:pe_file_parser.cc(381)] Failed to parse data directory load config.
[0824/142620:ERROR:decomposer.cc(1084)] Unable to parse PE image.
[0824/142620:ERROR:pe_relinker.cc(66)] Unable to decompose module: D:\FuzzTools\winafl\bin32\test_static.exe
[0824/142620:ERROR:instrumenter_with_relinker.cc(124)] Failed to initialize relinker.

how to solve this?

Syzygy is not supported anymore. This means it doesn't support new compilers. I think this is the problem in your case:

Unknown version of the IMAGE_LOAD_CONFIG_DIRECTORY structure (160 bytes), might be because you're using a new version of the Windows SDK.

There are two possible solutions - get syzygy code and add support for your SDK's IMAGE_LOAD_CONFIG_DIRECTORY (this should not be difficult if you understand PE file structure) or build your application with an older compiler and SDK.
But you can encounter errors that aren't easy to fix like I did - https://github.com/google/syzygy/issues/61.

Syzygy is not supported anymore. This means it doesn't support new compilers. I think this is the problem in your case:

Unknown version of the IMAGE_LOAD_CONFIG_DIRECTORY structure (160 bytes), might be because you're using a new version of the Windows SDK.

There are two possible solutions - get syzygy code and add support for your SDK's IMAGE_LOAD_CONFIG_DIRECTORY (this should not be difficult if you understand PE file structure) or build your application with an older compiler and SDK.
But you can encounter errors that aren't easy to fix like I did - https://github.com/google/syzygy/issues/61.


Can not run quantization with Hardswish operator on v2.5

I created simple model to test quantization with hardswish, like this:
class Test_Model(nn.Module):
	def __init__(self):
		super().__init__()
		self.conv1 = nn.Conv2d(3, 32, 3)
		self.hard_swish = nn.Hardswish()
	def forward(self, x):
		x1 = self.conv1(x)
		x2 = self.hard_swish(x1)
		return x2

I got this error when run quantization- mode calib

It seams a bug in pytorch_nndct/nn/modules/hardswish.py. So please fix it. Thanks

@SuHuynh:
This is really a bug. You can remove that line pytorch_nndct/nn/modules/hardswish.py:40 for work around.
The fix will be in next release pakage.

I had the same issue and commented line 40 of pytorch_nndct/nn/modules/hardswish.py, but then there are two arguments missing in line 53:
output = fake_quantize_per_tensor(output, scale_inv=128, zero_point=0, quant_min=-128, quant_max=127)
method and inplace arguments are required. What should be passed here?
This seems to be a bug too and I expect the OP will have the same problem.

@lino-alves :
You can set method=2, inplace=self.quantizer.inplace


Get Cannot find module 'astro-seo' or its corresponding type declarations.ts(2307)

Hey, love your Astro integration! Does it/can it support typescript out of the box or by doing npm install @types/astro-seo? I get the following error when importing it into a page like so:
---
import { SEO } from "astro-seo";
---

Gives:  Cannot find module 'astro-seo' or its corresponding type declarations.ts(2307)
I am fairly new to typescript, but pretty sure it can be added to the DefinitelyTyped repo, it's just a bit past my expertise how to.
At the moment I am supressing the typescript warning by using // @ts-ignore
Thanks for your contributions!

Same here. I am adding this line to env.d.ts as another workaround:
declare module 'astro-seo'

But it would be better to have types out of the box.

Hey @LushawnDev and @madrus. I can't seem to reproduce this in a newly created astro project with TS rules set to "strictest". Any stept to reproduce?

Same here. I am adding this line to env.d.ts as another workaround:
declare module 'astro-seo'

But it would be better to have types out of the box.

That worked for me too (also had the same error msg)

Try restarting TS Server or VSCode, that fixed it for me. I didn't have to add any new declarations in env.d.ts.

Using Zed editor and have the same issue, but solve it by adding
declare module 'astro-seo'

to env.d.ts


Search results-list truncation

Searches with lots of results would create a list that overflowed the bottom of the page.
This change forces the results list to only ever show a maximum of 10 results at once.
Adds a "plus {N} more..." message to show how many results a search has found.
For this PR, MAX_RESULTS const is hardcoded to be 10, but the plan is to expose this into the options settings for the plugin (coming in a future PR)

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

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

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
1239

Relevant Lines:
1723

💛  - Coveralls

Are the results ordered by relevance, so the hidden ones will be less useful?

Are the results ordered by relevance, so the hidden ones will be less useful?

Yep - already ordered by relevancy. 👍


fix file path of commands in  content_zh/docs/tasks/security/https-overlay/index.md

修正demo中的文件路径，改为最新版本里的路径

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

Needs approval from an approver in each of these files:

content_zh/OWNERS

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

Hi @wangkirin. Thanks for your PR.
I'm waiting for a istio member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.
I understand the commands that are listed here.

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


[SPARK-6555] [SQL] Overrides equals() and hashCode() for MetastoreRelation

Also removes temporary workarounds made in #5183 and #5251.

Test build #29472 has started for   PR 5289 at commit cfafeeb.

Test build #29474 has started for   PR 5289 at commit d0095ac.

Test build #29472 has finished for   PR 5289 at commit cfafeeb.

This patch passes all tests.

This patch merges cleanly.

This patch adds the following public classes (experimental):

case class AtLeastNNonNulls(n: Int, children: Seq[Expression]) extends Predicate

This patch does not change any dependencies.

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

Test build #29474 has finished for   PR 5289 at commit d0095ac.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.
This patch does not change any dependencies.

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

Thanks!  Merged to master and 1.3


Use WinUI shadow border with selected TabViewItems

(After vs Before) We switch away from adding a drop shadow panel to every tab and instead use a border which simulates elevation.
Will remove commented markup shortly...

@duke7553 Is this ready for review?


System Requirements

Hi,
Can I know the recommended system requirements (e.g. CPU, Memory) for running this tool for load testing?

0xee478ecD4469e19a41f5b3aC78F2C864D932B5D7


payment webview not working with ios

Hello,
I have a store application and I have integrated a payment gateway and everything works fine in Android, but when I ran the version on the iPhone, it does not work
There is a video explaining the problem
video

Closing this as a duplicate of https://github.com/flutter/flutter/issues/93425


Explain how to try a PR

On some case any use would be try a PR. Is no so complicate when is explained :)
Please check the following:

Make sure you are targeting the master branch, pull requests on release branches are only allowed for bug fixes.
Read contributing guidelines: https://github.com/go-gitea/docs/blob/master/CONTRIBUTING.md
Describe what your pull request does and which issue you're targeting (if any)

You MUST delete the content above including this line before posting, otherwise your pull request will be invalid.

LGTM

LGTM

make L-G-T-M work


Added browser lang. detection and cookie storage

also added cookie storage dependency for unit tests

Reviewed 1 of 2 files at r1.
Review status: 1 of 2 files reviewed at latest revision, all discussions resolved, all commit checks successful.

Comments from the review on Reviewable.io

Reviewed 1 of 1 files at r2.
Review status: :shipit: all files reviewed at latest revision, all discussions resolved, all commit checks successful.

Comments from the review on Reviewable.io


Unstack instead of average?

The pooling layers are averaged together, converting a 3d B x N x K tensor (where B is batch size, N is the number of layers being pooled, and K is the number of "features" we get from the encoder) to a 2d B x K tensor. We can imagine an alternative in which they're instead unstacked with torch.unbind and torch.concat and then the result is a 2d B x N * K tensor. It's worth experimenting with this, if you haven't already @DanielYakubov. The result would be a slightly heavier classifier, but the classifiers are quite small compared to the encoder.

Closing as it doesn't seem to help.


ACCUMULO-4446 Making changes to 1.7

These changes are the same as those in #195.
Edit: This commit adds log messages when acquiring Monitor, Master, ZK, and GC locks.

I recommend a better description for the git commit log. Something which describes the nature of the change, rather than simply referring to the ticket number and branch.

Just made the change for the commit message and added a description to the PR.

No sure what happened to the Jenkins checks, it failed before the Travis CI even finished, can someone help me find out what the problem was?

Looks like a jenkins issue.  I relaunched, but jenkins couldn't pull the
commit.  Not really sure what happened.  Can you push another commit to see
if runs again?
On Mon, Jan 30, 2017 at 8:55 AM lstav<EMAIL_ADDRESS>wrote:

No sure what happened to the Jenkins checks, it failed before the Travis
CI even finished, can someone help me find out what the problem was?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/apache/accumulo/pull/207#issuecomment-276068019, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAJJvrh8vfkw8IekJ69CzfbMuPFoaYyks5rXevNgaJpZM4Lus-G
.

Sure, will do

merged in, please close this PR


dts: riscv: pulpino: Fix warning for itim unit address

dtc produces the following warning:
Warning (simple_bus_reg): /soc/itim@8000000: simple-bus unit address
format error, expected "0"
We had the wrong unit address in the dtsi file, should be 0.
Signed-off-by: Kumar Gala<EMAIL_ADDRESS>

Codecov Report

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

@@           Coverage Diff           @@
##           master   #11445   +/-   ##
=======================================
  Coverage   48.37%   48.37%
=======================================
  Files         265      265
  Lines       42192    42192
  Branches    10137    10137
=======================================
  Hits        20412    20412
  Misses      17703    17703
  Partials     4077     4077

Continue to review full report at Codecov.

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


Can't compile with your fork of Audio lib due to missing methods in Resampler

Hi, I'm trying to build on platformIO to get your example to work, which led me to this repo maybe a year ago (full story for context here and here. I had it working for a while, but unrelated issues made me wipe the pio libs and now I can't compile anymore. It seems like there are missing declarations in https://github.com/alex6679/Audio/blob/master/Resampler.h (fixIncrement, setPos, updateIncrement) among other mismatches between the cpp and h files in your fork.
Are these up to date? Or is there a more recent way to get ESP32 I2S input into a T4 ?
Thanks!

Hi, sorry for that. I reverted the last changes I made to async_input.h. Now you should be able to use Paul's original Audio library again. It's quite some time since I pulled from the audio library main branch and my fork is currently not up-to-date. So it's better to use the original audio library.
Hope that solves your problem.

Indeed it compiles again now! Thanks a lot for the quick response :)
I did have to remove the example1 folder for the project to build though (if I remember correctly I am using the example I found in https://github.com/JayShoe/esp32_T4_bt_music_receiver/blob/main/Teensy4/output_i2s2_16bit.cpp)


Vendor Folder required not found

Hello
TB ok when I was in v0.27.
I downloaded v0.30 and replace old files (except .db). I have now this following error.
Apache2 error logs : PHP Fatal error:  require_once(): Failed opening required
'C:\Users\ME\Server\Bitnami\wordpress-4.2.2-2\apps\taskboard\htdocs\api/../vendor/autoload.php' (include_path='.;C:/Users/ME/Server/Bitnami/wordpress-4.2.2-2/php/PEAR') in C:\Users\ME\Server\Bitnami\wordpress-4.2.2-2\apps\taskboard\htdocs\api\api.php on line 3, referer: http://localhost/taskboard/
Vendor folder is indeed missing.
Windows 7 Pro SP1
Apache2 under Bitnami
Thank you
Regards
EJB

Did you try to run the command "composer install" to get all dependencies ?
Help for composer

@camael24 has answered this. Closing unless you have more to add.

Hi
Did this but my Companie network prevents something somewhere...
With my shared connection (phone) everything is OK (just do it).
Thanks a lot and sorry for the delay (need holidays...)
Regards
E.J.BAYSSETTE
mob : 06 28 84 16 70
fix : 095 123 26 36
http://www.bayssette.fr
http://fr.viadeo.com/fr/profile/eric-james.bayssette
http://fr.linkedin.com/in/ericjamesbayssette
2015-11-30 19:06 GMT+01:00 Matthew Ross<EMAIL_ADDRESS>
@camael24 https://github.com/camael24 has answered this. Closing unless
you have more to add.
—
Reply to this email directly or view it on GitHub
https://github.com/kiswa/TaskBoard/issues/233#issuecomment-160708990.


Upgrade to mxnet 1.6

Issue #, if available: fixes #583, fixes #671
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

One issue is that test cases using this HybridBlock fail since one of the inputs (x2[1]) is not used by the network. I would need the opinion of @canerturkmen on whether this is a problem, or we can remove/modify those test cases.

Seems like jitter Cholesky tests need to be disabled on Linux because potrf just segfaults on mxnet 1.6 when the matrix is not positive definite symmetric

This is going to break: https://github.com/awslabs/gluon-ts/pull/678, but overall the images provided in sagemaker sdk too, since the MXNet images are 1.4.1 based. The pull request is open and ready to merge for a while now, but since it hasn't been committed it wont show up in the tests.

This is going to break: #678, but overall the images provided in sagemaker sdk too, since the MXNet images are 1.4.1 based. The pull request is open and ready to merge for a while now, but since it hasn't been committed it wont show up in the tests.

Its potentially an easy fix though, once #678 is merged, since we would essentially rely on the pre built SageMaker images, so we could just choose one with an appropriate MXNet version, if there is one.

Codecov Report

Merging #709 into master will increase coverage by 43.86%.
The diff coverage is 100.00%.

@@             Coverage Diff             @@
##           master     #709       +/-   ##
===========================================
+ Coverage   40.83%   84.69%   +43.86%
===========================================
  Files         180      181        +1
  Lines       10557    10574       +17
===========================================
+ Hits         4311     8956     +4645
+ Misses       6246     1618     -4628

Impacted Files
Coverage Δ

src/gluonts/model/seq2seq/_forking_network.py
100.00% <100.00%> (+65.11%)
:arrow_up:

...gemaker_sdk/entry_point_scripts/run_entry_point.py
47.05% <0.00%> (ø)

src/gluonts/dataset/artificial/_base.py
35.96% <0.00%> (+0.87%)
:arrow_up:

src/gluonts/core/exception.py
62.50% <0.00%> (+2.08%)
:arrow_up:

src/gluonts/model/trivial/constant.py
76.92% <0.00%> (+11.53%)
:arrow_up:

src/gluonts/dataset/artificial/recipe.py
73.88% <0.00%> (+12.68%)
:arrow_up:

src/gluonts/kernels/_kernel_output.py
87.09% <0.00%> (+12.90%)
:arrow_up:

src/gluonts/model/npts/_estimator.py
100.00% <0.00%> (+14.28%)
:arrow_up:

src/gluonts/dataset/stat.py
96.32% <0.00%> (+15.44%)
:arrow_up:

src/gluonts/block/enc2dec.py
91.66% <0.00%> (+16.66%)
:arrow_up:

... and 121 more


Handle RCS messages properly, and improve group MMS

Fixes #1055 and #1027
This ought to be polished up, but this fixes RCS importing 🎉
It also improves how group MMS threads are imported. Basically it includes all the recipients in the "to" field, and puts everyone's name in the subject, so that gmail does a much better job mimicking the group threads on your phone.
I've been toying around with it on my Pixel 3a running Android 10. I've tested with my 100 most recent messages - a mix of SMS, group MMS chats, and RCS chats.
I'm completely open to the idea that I was a little heavy-handed with my refactor. I ran with what made sense. I'm fine if someone else wants to take this as as proof-of-concept and run in a slightly different direction to make this mergeable.
TODO

[ ] See if there are any unit tests that have been broken
[ ] Probably some new unit tests (to be honest..... I really don't want to build these out).
[ ] Give this another look over for general code quality. The old version of Java (and me being a bit rusty with Java) made some things like sets/arrays/uniq/etc a bit clunky.

@locofocos Thank you so much for doing this; it will close a large number of outstanding tickets.
I will review in detail shortly.
(It will still be up to @jberkel to publish to Google Play.)

I'm really happy with the separation of records into sender and recipients.
This will fix not just RCS, but almost every issue in the "half missing" category.
Again, many thanks.

@kurahaupo you're welcome! Thanks for the initial review. I'll get this cleaned up and tested further some time soon, I hope.

@kurahaupo I've given this some solid testing on my phone, and I'm happy with the result.
Is the travis CI build running against this PR? I was looking for the build output so I could at least see which tests I need to update.

I'll check on the CI when I get home to my PC

Hi
I tried to compile from source but it keeps failing. Can someone post an APK please

@hubono I debated whether I should post a copy of my latest APK build, just in case life happens and we don't get this PR merged.
Caveats, if this wasn't obvious:

This code hasn't been well reviewed
It's code that some stranger on the internet wrote
It's built in debug mode, with a self-signed certificate (something like that). So android won't allow you to upgrade your existing app with this. Android is rightly protecting you from installing an APK built by someone other than the author. So you'll have to uninstall your existing app first.

However, I've been using it for months. No promises, but I'm happy with the results. So here is the APK I built locally from ac71d552e62
SMS backup plus with RCS fix v2.apk.zip

@locofocos Question: I am currently running 1.5.11 from the app store. I want to try your improved version to see if it will fix the GMail threading issues I had. I am unclear what the upgrade path is. Since I am sideloading, do I need to uninstall 1.5.11 first? Also, you mention the "backup state" multiple times above but since this is technically a new app sideloaded, does that mean that by default, all my messages on my phone will get backed-up again into GMail?

@chadcancode Since you're sideloading, yeah, Android will force you to uninstall 1.5.11 first.
I made some clarifications to the upgrade path under Adopting this new version above.  IIRC this app will ask "Do you want to backup and skip all existing messages on this phone" the first time you launch it.
It's really up to you. If you want a perfect seamless state, do "the harder way". If you don't care about duplicates, use "the lazy way".

@hubono I debated whether I should post a copy of my latest APK build, just in case life happens and we don't get this PR merged.
SMS backup plus with RCS fix v2.apk.zip

May I humbly request that you (or some other kind soul) provide a version compiled in 64-bit, please?
On my Pixel 8 Pro I get the error "you can't install the app on your device" when installing. My understanding is that newer phones or Android versions no longer support 32-bit apps. I did uninstall the old app first.

@hubono I debated whether I should post a copy of my latest APK build, just in case life happens and we don't get this PR merged.
SMS backup plus with RCS fix v2.apk.zip

@locofocos may I humbly request that you (or some other kind soul) provide a version compiled in 64-bit, please?
On my Pixel 8 Pro I get the error "you can't install the app on your device" when installing. My understanding is that newer phones or Android versions no longer support 32-bit apps. I did uninstall the old app first.

I made a few changes to get this compiling again - I think Google removed some library versions from their maven repo (thanks Google...).
I think we can compile it against 64 bit, but I'm not sure what all is required. I added ndk.abiFilters 'armeabi-v7a','arm64-v8a' to app/build.gradle following https://developer.android.com/google/play/requirements/64-bit#android-studio-gradle. Maybe that's sufficient to get it working. Or maybe someone needs to audit and upgrade every library/dependency to make sure those are using 64-bit-compatible versions.
@kranix0 See if this works on your Pixel 8: SMS.backup.RCS.maybe64bit.cb3a97f.apk.zip

Actually I think 64 vs 32 bit might not be the issue. Stackoverflow says

If there is no directory lib, it supports all architectures.

and the APK doesn't have any lib folder. So I think it already supported 64 bit phones.
This looks much more promising: https://www.reddit.com/r/GooglePixel/comments/17bzbcy/install_failed_deprecated_sdk_version_any_way/ This app uses minSdkVersion 14 and targetSdkVersion 29. I'm curious if you can get the full error message by using adb to install it.


Add Rust Lang Nursery

https://github.com/rust-lang-nursery has lots of popular rust crates and lots of issues for which mentors are available.

Thank you for raising this issue @palash25.
I see plenty of good first issues is projects like rust-clippy
https://github.com/rust-lang-nursery/rust-clippy/issues?q=is%3Aissue+is%3Aopen+label%3A"good+first+issue"
Definitely worth adding.

i would like to take this one if possible :)
just to be clear, you want to add a new card of rust lang nursery to the github page right,
with the link Roshanjossey provided? or it better be the main issues page? or the repo page?

@omer2500, great. Go with the link in my comment. I believe it's better to take users to good first issues.

Closing this as this was addressed in #4962


Setting up CrateDB for tackling issues

Pitch

Some Users have a hard time identifying root causes for issues.
They don't know what tools to use.
They don't know how to configure CrateDB to expose relevant metrics.
They have no strategy on how to tackle issues.
They don't know where to look at.
They don't know how to interpret stuff.

It would be helpful to educate users on how to successfully deal with CrateDB issues.
Launch checklist
Follow the launch checklist to get new content ideas from pitch to published. Use the comments on this issue to provide the information requested.
This issue will be assigned to the initial reporter, by default, as a request work on the launch checklist. You may want re-assign the issue to request that someone else works on it.

[ ] Provide context

Who is the audience for this content?

What problem should this content solve for the reader?

What is the best format for this content (e.g, blog post, docs tutorial, etc.)?

Why is this content important for the company?

How urgent is this content?

[ ] Identify an author
The ideal author knows the most about what has to be written about. Typically, this is a domain expert or someone with relevant hands-on experience.
The @crate/tech-writing team can help locate an author.
Alternatively, a @crate/tech-writing team member can author the content. Note, however, this may slow things down if the technical writer has to learn the topic before writing about it.
Once an author is identified, this issue should be assigned to the author.

[ ] Create an outline
You have a description of the content idea. Before writing starts, that description should be turned into an outline.
You can think of an outline as a set of bullet-point notes that summarizes the content structure. A good outline is the starting point for a draft.

[ ] Produce a first draft
The author should produce a first draft, using the outline as a guide.

Once the author has produced the first draft, editing can begin. If the author is not a technical writer, a member of the @crate/tech-writing team will provide editorial support and help the author bring the piece to fruition.

sounds like good content for the new troubleshooting section in the how-tos

@joemoe we changed the way @crate/tech-writing use GitHub labels. accordingly, I have re-triaged this issue
NOTE: I have edited the issue description to match the issue template for new content pitches
please review the launch checklist (above) and let me (or any @crate/tech-writing team member) know if you want help or have any questions


render label on the node

https://github.com/vasturiano/3d-force-graph/issues/458
https://stackoverflow.com/questions/59656856/3d-force-graph-node-and-sprite-text
https://github.com/vasturiano/three-spritetext
html

[ ] add a setting for user to choose show full path or just file name
[ ] add setting for user to choose whether it should show extension

we are continuely making progress!

done


Refactor code in _neon.less

In src/components/animated/_neon.less we need to remove the following code from lines 11 and 18:
transition: all 0.5s ease;

It's redundant as it is declared at the beginning of the file.

Hello @shahednasser, can I work on this?

Sure @SamD97 go ahead!


Bump version to 0.99.16

Checklist

[x] Used a fork of the feedstock to propose changes
[ ] Bumped the build number (if the version is unchanged)
[x] Reset the build number to 0 (if the version changed)
[x] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[ ] Ensured the license file is being packaged.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.
I do have some suggestions for making it better though...
For recipe:

Using toolchain directly in this manner is deprecated.  Consider using the compilers outlined here.

@conda-forge-admin, please rerender

This should replace #6. Somehow it'd be nice to build for OSX too.


added dependency for libxml2

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


Added support for testing apps that use rack.hijack.

This Pull Request brings in support testing Rack applications that use rack.hijack for streaming responses.
Feedback is very much so welcome. Thanks.

@markbates sorry for the huge delay. Please give this another look towards the current master branch, and make sure Travis runs without errors. Closing for now, thanks for your effort. (just create a new PR if/when you get it sorted out)


Unable to connect. Error code: 1002. The server returned status code '405'

Please provide us with the following information:

This issue is for a: (mark with an x)
- [x ] bug report -> please search issues before submitting
- [ ] feature request
- [ ] documentation issue or request
- [ ] regression (a behavior that used to work and stopped in a new release)

Minimal steps to reproduce

Followed the steps at https://docs.microsoft.com/en-us/azure/cognitive-services/speech-service/tutorial-voice-enable-your-bot-speech-sdk to add voice support to my bot. Only difference is I'm using bot sample 63 instead of 02 since it also contains a Twilio adapter.

I haven't been able to find any instances of others getting this particular status code.
Any log messages given by the failure

Error (ConnectionFailure) : Connection was closed by the remote host. Error code: 1002. Error details: The server returned status code '405' when status code '101' was expected. SessionId: ecf282bbb759438e8dd6fb93a6db3ac5
Expected/desired behavior

Voice Assistance Client connects successfully.
OS and Version?

Windows 7, 8 or 10. Linux (which distribution). macOS (Yosemite? El Capitan? Sierra?)

Windows 10
Versions

Voice Client v1.11.0
Mention any other details that might be useful

Thanks! We'll be in touch soon.

@sereilly , can you check if sample 63 was modified to suppor Direct Line Speech, as per this document? The Echo bot was updated to make sure it supports Direct Line Speech. I'm not sure the same applies to sample 63.
Darren

@sereilly I would also first make sure you get it to work with the Echo Bot, then try with another bot. Just want to make sure the instructions as they are work for you with the Echo bot before we discuss switching to another bot.

That was it! I added .UseWebSockets() to Configure and [HttpGet] to PostAsync in sample 63 and now it works.

@sereilly, that's good to hear. I'll make sure we update the voice-enable-your-bot tutorial to highlight what to do if you are using another bot. The link is mentioned at the very end at the "See also" section ("Build a Bot Framework bot. Register it with Direct Line Speech channel and customize your bot for voice"), but there should be a separate section before this one toward the end about this as it's easy to miss.


Got Invalid Content-Type header error

Hi sir,
I've got an Invalid Content-Type header error on OpenAIClient.images.edit() and OpenAIClient.images.variation().
This is the error msg: Invalid Content-Type header (application/json), expected multipart/form-data. (HINT: If you're using curl, you can pass -H 'Content-Type: multipart/form-data')
So, this is what I've tried:

lib>src>network>request.dart>Request>_createHeaders>
headers.addAll({
'Content-Type': 'application/json',
}); -->
headers.addAll({
'Content-Type': 'multipart/form-data',
});
Then I got another error: " 'image' is a required property "
I do not know much about HTTP response and request.. but I am trying to learn about it.
Can you give me any advice about fixing that issue?

Hello @KSH-KOR, could you share the snippet of the code giving you the error?

#8 this should fix the issue. Let me know!


Merge work from #837 into New metrics

Reference Issues/PRs

Completes #837.
What does this implement/fix? Explain your changes.

Finishes adding 2 new forecasting metrics (geometric mean error based metrics). This fixes the merge conflicts between the original PR #837 and sktime's main branch.
Does your contribution introduce a new dependency? If yes, which one?

No new dependencies.
What should a reviewer concentrate their feedback on?

Any other comments?

PR checklist

For all contributions

[ ] I've added myself to the list of contributors.
[ ] Optionally, I've updated sktime's CODEOWNERS to receive notifications about future changes to these files.
[ ] I've added unit tests and made sure they pass locally.

For new estimators

[ ] I've added the estimator to the online documentation.
[ ] I've updated the existing example notebooks or provided a new one to showcase how my estimator works.

Not sure how I got all these other changes in here (which I didn't actually make). Must have pulled changes from elsewhere or something. I'll get that fixed and re-open.


Push Stackstorm 3.2 to Docker Hub

SUMMARY
We need the stackstorm/stackstorm:3.2 image. The latest image is stackstorm/stackstorm:3.1
You may ask why don't you use stackstorm/stackstorm:latest image which is 3.2. Reason why is that it's not tagged and not suitable for a CI (latest means it can change at any point).
STACKSTORM VERSION
3.2
OS, environment, install method
Docker

Thanks for your message.
There is no stackstorm:3.2 image for the current all-in-one st2-docker and we don't plan to push one as that project relies on Ubuntu Trusty we just dropped support for.
An alternative to this is a replacement in st2-dockerfiles which is based on Ubuntu:Bionic and python 3. If you're motivated, try docker-compose with those StackStorm images, test and provide your feedback at https://github.com/StackStorm/st2-dockerfiles/pull/28

https://github.com/stackstorm/st2-docker project has been revamped and relies on https://github.com/StackStorm/st2-dockerfiles which have 3.2 images in Docker hub.


No support for 3 dimentional input space

I was trying to run an environment that has a input space with rank 3. Looking at the code,
https://github.com/google/dopamine/blob/76cdae1f858233a8501e2b61095cde54c6f8a214/dopamine/agents/dqn/dqn_agent.py#L189
If the input is of rank three, after the stack_size and batch are added it ends up being rank 5, which throws an error. Is there currently a way that you could have it use rank 3 inputs.  Would adding something like:
if len(self.observation_shape) == 3:
    state_shape = (1,) + self.observation_shape [:-1]+ (stack_size * self.observation_shape[2],)

be a valid way of allowing for rank three input shapes? (Assuming the stacking logic is also changed to accommodate for this)

Actually I see now that it is possible to have whatever type of input you want as long as you create your network function.


ESC key should exit pop-ups

Steps to reproduce:
go to /a11y-map/index.html
navigate area to pop-up
open pop-up
press 'esc'
Expected Behavior:
should close the pop-up
Supporting Info:
Google Chrome Version 68.0.3440.106
OS X High Sierra
localhost..././a11y-map/index.html

Look to 522a58e for solution


PL KB FAQ cleanup - copy edits, remove duplicates, move to applicable categories

Description

Please describe your changes: PL KB FAQ cleanup - copy edits, remove duplicates, move to applicable categories from line 1311 to the end of the file
Jira/GitHub Issue numbers (if any): N/A
Preview links/images (Internal contributors only): __________________

PR lifecycle
We aim to merge PRs within one week or less, but delays happen sometimes.
If your PR is open longer than two weeks without any human activity, please tag a code owner in a comment.
PRs must meet these requirements to be merged:

[x] Successful preview build.
[ ] Code owner review.
[x] No merge conflicts.
[ ] Release notes/new features docs: Feature/version released to at least one prod environment.

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://66172b32f1ca3405af56b26c--harness-developer.netlify.app


Support to test infinite Iterators and Iterables

Summary
It seems AssertJ doesn't handle infinite data structures well, which leads to "hanging" tests (probably when trying to determine the size of the data structure).
Real life use case / example
I tried to test an implementation of a cyclic iterator using assertThat(myIterator).startsWith(1,2,3,1,2,3), which hangs.
Java 8 specific ?
NO

AssertJ converts the iterator to a List as soon as it needs to be consumed, for example to check its size but in the case of startsWith, we should not perform the conversion as it is necessary.


Sock error with Nomad, since upgrade of juicedata/juicefs-csi-driver:v0.18.0

What happened:
Sock error with Nomad, since upgrade of juicedata/juicefs-csi-driver:v0.18.0
Error: CSI plugin failed probe: timeout while connecting to gRPC socket: failed to stat socket: stat /var/nomad/client/csi/plugins/082c4b7d-758f-6e59-5299-0ed23b872345/csi.sock: no such file or directory

What you expected to happen:
It was working with juicedata/juicefs-csi-driver:v0.17.4
How to reproduce it (as minimally and precisely as possible):
Switch from juicedata/juicefs-csi-driver:v0.17.4 to juicedata/juicefs-csi-driver:v0.18.0
Anything else we need to know?
Environment:

JuiceFS version (use juicefs --version) or Hadoop Java SDK version: v0.18.0
Cloud provider or hardware configuration running JuiceFS: Nomad
OS (e.g cat /etc/os-release):
Kernel (e.g. uname -a):
Object storage (cloud provider and region, or self maintained): S3 Bucket on OVH
Metadata engine info (version, cloud provider managed or self maintained): Redis
Network connectivity (JuiceFS to metadata engine, JuiceFS to object storage):
Others:

Hi @AlbanAndrieu , can you add env "POD_NAME" in controller and node service ? Referring to the doc: https://juicefs.com/docs/zh/csi/csi-in-nomad and issue: https://github.com/juicedata/juicefs-csi-driver/issues/619

Sorry, but Just wanted to comment, according to these docs https://juicefs.com/docs/csi/csi-in-nomad, the env variable is not capitalized but needs to be POD_NAME or else same error appears (didn't work for me until env name was all caps, I think that is how nomad works?). Anyways, thanks for at least providing nomad support :+1:

@azoller1 , so sorry for the mistake in doc. It should be POD_NAME. We will fix it asap.


Need more documention

Hi there,
I am working on a very important project for my company and we hare deciding whether to use Project Online for some functionality we need.
Just about the only useful documentation I can find on the internet is the following page:
https://learn.microsoft.com/en-us/dynamics365/project-operations/project-management/schedule-api-preview
Which is the bare minimum. I have got the sample code from this page working but I can't find anything on the following:

add custom field
update custom field
set label
attach file

There has got to be more information somewhere but it is impossible to find.
cheers
Russ

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

ID: f269741b-6823-92ab-066d-90e68ac3e418
Version Independent ID: e39d8b04-27e4-9345-5dc5-d752268d04a2
Content: Use Project schedule APIs to perform operations with Scheduling entities
Content Source: articles/project-management/schedule-api-preview.md
Service: dynamics-365-project-operations
GitHub Login: @sigitac
Microsoft Alias: sigitac

@russellmccloy Are you wanting to do those things using the API, or are you asking how to do it using the UI? For example, is this the information you are looking for: https://learn.microsoft.com/en-us/dynamics365/project-operations/pricing-costing/add-custom-fields-price-setup-transactional-entities?

Closing, no response from russellmccloy.


tracing/logs of all steps

Just ran surprise_trip.ts locally, and it worked! Very nice. While I see that all the steps are logged to the terminal, the final WorkflowState  only has the final messages array. Is there some way to get all the agents/tools executed, prompts, etc? While I could augment my tool functions with some way to log messages some place, I'm curious how I would do it for an agent. Maybe via the provider? Logging all workflow transitions would also be interesting.

Yeah, we don't have this per se right now. We have built-in logger, which gets previous and next state, and that's how he figures the steps out.
I am guessing one way to implement this as of today would be via custom logger, that keeps internal execution state, stores prev/next state. When done, you could read the log from its state. It could also print it to a log file automatically.
We do not log prompts yet, which is something to keep in mind as we work on the provider abstraction. We need to implement token usage and other metrics as well, so whatever is the solution, should do this too!
I was thinking we could add (or replace logger entirely) with a new property telemetry or something on the workflow object, but I quickly got rid of that, as passing workflow object around the entire codebase is definitely not something I like.
Definitely open to ideas and discussion, taking from your functional experience! I am sure there's clean and elegant way this can be done.

Related to: #110


Embrace Standardized Color Control

I was trying to get people to embrace this crate before as a unified way to control colors but it did not get far: https://crates.io/crates/clicolors-control (that crate also turns on ansi colors for the windows console as an added bonus)
The idea was that you have one common crate that turns on and off colors for the entire cli app.
I'm fine finding a different mechanism for this but right now controlling colored output is really not a particularly fun experience.
Anything got some thoughts on this matter?

Relevant internals thread: https://internals.rust-lang.org/t/terminal-platform-abstraction/6746

I've looked at clicolors-control before, but didn't use it for a variety of reasons on which reasonable people may disagree:

It doesn't look at the TERM environment variable. I personally don't really care about the clicolors standard, so I think it's fine to use it, but it shouldn't be used to the exclusion of other things. When people set TERM=dumb, for example, then people expect that to be respected. (I've even found that some environments that don't support colors will do this automatically, and if you don't respect it, you end up emitting a bunch of escape codes.)
Its tty detection on Windows is insufficient for my needs. I need it to work in MSYS2 terminals. The atty crate does this using a hack.
My termcolor crate (which predates clicolors-control, AFAIK) already did everything that clicolors-control does, and assimilates it with common end users inputs via the ColorChoice type. (With one exception: only recently did it acquire the ability to enable ANSI escapes on Windows 10.)

I would in principle support coalescing around one crate that just did color detection, but on that same token, I'd also like to see people coalesce around one crate for dealing with a Windows console for coloring, e.g., wincolor.

@BurntSushi for what it's worth I do not really want to defend either the crate nor the defaults. I mostly just want a crate that holds the state of color on/off with a sensible default.

My termcolor crate (which predates clicolors-control, AFAIK) already did everything that clicolors-control does

The reason I never ended up using termcolor was that it does not actually (to the best of my knowledge) store the state of color on/off. It just has the auto color choice which derives the default for the writers. You cannot query it and ask: does the user want colors.

The way I would like to see terminal colours work is a wrapper around std(out/err) that interperets ansi escape sequences. If we are on windows before windows 10, we have to use the win32 api to process escape sequences, but on most platforms we can just pass them through. There is also terminfo/cap that should be respected.
If we do this, everyone just uses ansi escape sequences, and the wrapper can choose to discard them based on anything (TERM, configuration, etc.).
Idea from this post.

There is also terminfo/cap that should be respected.

I explicitly chose to not respect this, at least for things like colors or other simplistic styling like underlining or bold. The reason why is because when I did use a library that respected terminfo, I got numerous bug reports where the wrong escape codes were being emitted. Instead, I chose to follow in the footsteps of GNU grep: just stick to the basics. GNU grep is widely deployed, and I never hear anyone complaining about whether its colors work or not, which is compelling evidence from my perspective that it has the right approach here.
For CLI tools that need to do more extensive manipulation of the terminal, then this may be the wrong calculus.
In general, I agree that an ANSI interpreter would be great, and it would, for example, slide nicely into termcolor's existing API (while simultaneously removing the need for the buffer and buffer writer types). It's nice-to-have IMO, and we can make progress without it. :-)

@BurntSushi what do you think are the most pressing issues in this area? Sorry if this question is answered elsewhere.

@derekdreery you still need to know if colors are on or off for other reasons. For instance I shell out to other processes which will typically not detect color correctly so I want to propagate my understanding of if color is on or off to that subprocess.
WRT to the wrapping stream: I agree that would be nice. Sadly right now there is only an undocumented API used by rusttest to intercept prints.

@derekdreery The hardest possible problem: getting people to agree on one library. It may be the case that you need an ANSI interpreter to do that, because termcolor's API today is not nearly as simple as crates that only handle ANSI formatting.
@mitsuhiko's idea about at least getting all of them to agree on whether colors are enabled or not (and permit the caller to control) is a really nice middle ground and possibly much easier to achieve. I would certainly be on board with doing that for termcolor (subject to my concerns listed above).

The idea of interpreting ANSI codes alarms me for a number of reasons:

The number of potential ANSI codes somebody might conceivably want to send is very large, and drawing any hard line will rule out some number of reasonble use-cases
What happens with things that look like ANSI codes but this crate doesn't know how to handle?

If they're passed through, you're likely to get output that works perfectly on some terminals and blurts ANSI goo in others
If they're silently ignored, that makes formatting problems difficult to debug
The library could raise an error, but is it worth killing the entire operation over an output formatting failure? Even if the culprit is just improperly-escaped user-input?

"half assed ANSI code handling" has caused problems before (although in that case the Rust program was the producer of such codes, not the consumer)
Even with helper functions with friendly names like make_green_text(), if your library's officially-supported API includes "put raw ANSI codes in your string literals", then people will do that, and raw ANSI codes are not an API surface that existing API tools like rustdoc are equipped to handle gracefully
The reason that raw ANSI codes are a popular API is because it's so easy to bang strings together, and so much more difficult to work with a more structured API. This is also the reason for the popularity of cross-site-scripting attacks and SQL injection vulnerabilities. ANSI codes probably aren't as security sensitive as those other things, but still worth considering.

All that said, it may still be the case that the ease and flexibility of a custom ANSI parser outweighs all the downsides, in which case fair enough.
However, taking a cue from the "cross site scripting" analogy, I'd be interested to see/use a terminal colour API based on the ideas of HTML templating libraries like Elm's HTML DSL, ScalaTags or rust-tags. That is, building up a type-safe data-structure that represents text and its formatting, which can be stored and later serialized to ANSI-codes or Windows console API calls or HTML with inline CSS or whatever. That would hopefully have all the thread-safety advantages of ripgrep, with a more ergonomic and teachable API.

@Screwtapello you raise a lot of good points I hadn't considered! Briefly, I will just respond to one thing here, and that's the idea of building up something more structured. In particular, for tools like ripgrep, printing output is a performance sensitive aspect of execution. It is likely that any overhead associated with emitting colors would need to be avoided, and I imagine execution templates probably wouldn't be acceptable. With that said, a convenient API doesn't need to solve every use case, so long as there are lower level APIs for when that is necessary.

The wider discussions a bout ansi, terminal abstractions etc. are quite complex which is why i thought about reducing this problem to initial color detection and control.
I think it might make sense to have a crate like clicolors control that just has a flippable global and then maybe various compile features to pick a sensible default (on, off, CLICOLOR, term detection etc.)
Then it should be easy for everybody to use it as a base and the rest of the discussion can be held separately.

@Screwtapello Thanks for explaining all that! I had not considered ideas like cross-site scripting.
What I'm trying to define is the most general, minimal level, and fast API that can do everything that's required.

The number of potential ANSI codes somebody might conceivably want to send is very large, and drawing any hard line will rule out some number of reasonble use-cases.

We would draw a line somewhere, probably text styling and cursor movement to start with. This line could be moved in future, and if people used the library it would show where the gaps are and what features are most missed. These could be prioritised.

What happens with things that look like ANSI codes but this crate doesn't know how to handle?

I think there are a few options here. I believe that in production (release mode) the correct thing to do is to strip out these sequences, but in debug mode it may be useful to log their presence.

If they're silently ignored, that makes formatting problems difficult to debug

If someone comes to you with a formatting issue, you can hand them a version of the program compiled to write out a warning when it comes across an unexpected sequence.

"half assed ANSI code handling" has caused problems before (although in that case the Rust program was the producer of such codes, not the consumer)

I'd argue this would just be a bug that should be fixed. Any implementation may have bugs.

Even with helper functions with friendly names like make_green_text(), if your library's officially-supported API includes "put raw ANSI codes in your string literals", then people will do that, and raw ANSI codes are not an API surface that existing API tools like rustdoc are equipped to handle gracefully

I agree. This library should not be for user consumption. An alternative library should be advertised that implements a programmatic API, using the type system to prevent invalid input. But we still need the implementation of that API, and I propose that this is the best way to do it, or at least that it is worth investigation.

This is also the reason for the popularity of cross-site-scripting attacks and SQL injection vulnerabilities.

I need to think more about this to fully understand the risks. I think it would be the role of the higher-level API to sanitize any input, so that escape sequences are only emitted from the API calls. This would need careful auditing.
So, in summary you would have 2 levels

(lower) escape sequences polyfill

fast (this is a guess because I imagine you could write a cache-friendly wrapper around the write calls, would need to check if its true or not)
flexible (can be sent over stream before being converted into platform-specific, pre-serialized)
complicated, and error prone if you write your own escape sequences

(higher) programmatic API

safe (type system and sanitization)
simpler, more ergonomic
slower (maybe, or will api calls just get inlined into string operations)
risky (sanitation needs to work, is there a difinitive list of escape sequences, or patterns of escape sequences that need to be stripped).

If you went straight for a higher level API you still have the issue of what to do with escape sequences in the input. Should you remove them, or leave them in? If you remove them, how do you know you are getting them all?
@mitsuhiko what are the specific things that are missing now that you would like to see as a minimum?

@derekdreery there needs to be an agreed upon way to turn color on and off. clicolors-control exists but nobody uses it and @BurntSushi outlined some of his reasons for not doing it. So what I can propose right now is to take that crate, incorporate his suggestions but I won't be able to force the rest of the community to use it :)

Could you simplify it to:

If CLICOLOR == '0' force disable color
If CLICOLOR != '0' force enable color
If CLICOLOR is unset, make a guess (using TERM etc.)

FYI: There is an attempt to make standard with NO_COLOR environment variable.
http://no-color.org/

I've played with this a bit, reading the xterm guide. I've also been reading the standard. My plan is to implement the ansi standard, at least to recognise all escape sequences specified there. Then I can process a subset of them and skip the rest.
For the issue with hostile escape sequence injection, any utf-8 sanitized text will not contain escape sequences. Therefore it is sufficient to check that input is utf-8 (see the xterm guide near the beginning for more details).

@derekdreery If I'm understanding you right, I'm not sure that will work. In particular, assuming or requiring that output (or input) is UTF-8 is unfortunately inappropriate in almost any UNIX command line tool.

@BurntSushi my argument is that you can avoid injection by using utf8, but that if you are not then there may be escape sequences present. My approach (at least to start with) will be to just strip any escape sequence as defined in the spec (including things like STX), and add back in the ones that I'm willing to handle for the given platform.
I think what I'm doing is an experiment at this point. I think having a working (by my probably incorrect definition) library will help to spark more debate.

For the issue with hostile escape sequence injection, any utf-8 sanitized text will not contain escape sequences.

I think you're talking about C1 control codes, which overlap with UTF-8 extension bytes. While it's true that a C1 control code like 0x9B (CSI, Control Sequence Introducer) is not directly valid in UTF-8, terminals date back to a time when only 7-bit ASCII was reliably available, so every C1 control-code has a 7-bit encoding of ESC followed by an ASCII character. Thus, any ANSI code defined to begin with CSI can also begin with ESC [ (0x1b 0x5b), and that is valid UTF-8.

@Screwtapello you are correct, I'm still learning :).

@iquiw there was an earlier attempt to standardize on CLICOLOR which managed to gain some traction and that's what clicolors-control currently uses: https://bixense.com/clicolors/

For using colours in CLI output, also consider that for example less has a pass-through mode for only ESC [ ... m sequences using the -R option (by default). This works solidly, e.g. with line-wrapping. So if you want to be compatible with less (as git and grep and so on are), then you limit yourself to ESC [ ... m. So this is relatively simple to handle, e.g. embedded in strings, or for stripping out or skipping when counting visible characters.
Terminfo may include other control codes in its colour sequences, which are fine for a TUI but not what you want in this case.

Considering that a CLI tool (but not a TUI) generally needs to handle having its output redirected to a file and then read later in a pager, this really cuts down on what ANSI sequences need to be handled.
Other ANSI sequences might be used inside a readline-like library, but this is not visible outside of that library, and wouldn't get into a log file from non-interactive use of the CLI tool (e.g. where there is no use of stdin, or stdin is redirected from a file).

If anyone's interested on progress I'm currently gaining the ability to
recognise all ansi escape sequences according to the spec. At that point
I'll be able to strip escape sequences. After that, I will start to
interperest some of the more simple sequences like colour.
On 9 Mar 2018 18:20, "Jim Peters"<EMAIL_ADDRESS>wrote:

Considering that a CLI tool (but not a TUI) generally needs to handle
having its output redirected to a file and then read later in a pager, this
really cuts down on what ANSI sequences need to be handled.
Other ANSI sequences might be used inside a readline-like library, but
this is not visible outside of that library, and wouldn't get into a log
file from non-interactive use of the CLI tool (e.g. where there is no use
of stdin, or stdin is redirected from a file).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/rust-lang-nursery/cli-wg/issues/15#issuecomment-371900673,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABU-XqoPo2VRS00EHFazr7Dtj91uxyFtks5tcsfogaJpZM4SZwS0
.

For the sorts of tools I wrote, declaring that you can only have color support on Windows 10 is just fine. Most command-line tools tend to be developer-focused, and most developers aren't running old versions of Windows anyway. I think as long as tools work on older versions of Windows, color is simply an added bonus, so I don't think we should be writing foundational crates that jump through hoops to support color in that situation.

If anyone's interested on progress I'm currently gaining the ability to
recognise all ansi escape sequences according to the spec. At that point
I'll be able to strip escape sequences. After that, I will start to
interperest some of the more simple sequences like colour.

You might be interested in the strip-ansi-escapes crate I put together recently for sccache. sccache runs compilers and captures their stdout/stderr and then outputs it elsewhere, so the standard "is stdout a tty" checks don't work well. With this crate I can force color output on from compilers and then do the tty check when it's time to output and strip escapes at that point. (My crate uses the vte crate for the actual parsing, so I have fair confidence that it does the right thing.)

Most command-line tools tend to be developer-focused, and most developers aren't running old versions of Windows anyway.

Do you have numbers on this?

My day job is primarily in the administration and security field, which is heavily command line focused. The number of Windows 10 machines we use is absolutely dwarfed by the number of Windows 7 (and even still Windows XP) machines. We're also heavy users of Windows Server 2008/2012.
I'd imagine shops like mine, while not a majority, certainly aren't only a tiny subset of command line tool users on Windows.

@kbknapp @BurntSushi regardless of the number of Win7 (or XP) developer machines currently in use, it is important to note that that number is guaranteed to drop over time. So the question we should ask is: should the design of color add additional complexity in order to support a usecase which will continue to be more and more deprecated?

@vitiral I don't know. All I know is what I endeavor to support today. I certainly would never attempt to enter the business of predicting when older versions of Windows became such a small source of users that they aren't worth supporting fully. I mean, in theory, it could be years. But nobody has any hard numbers as far as I can tell.

Do you have numbers on this?

I do not, this is purely anecdata! I looked around and could not find anything readily available. I wonder if Microsoft has data on Windows versions in use by Visual Studio users?
Regardless, I do think my point stands: given that a tool can be functional without colored output, and the fact that supporting colored output on Windows versions prior to Windows 10 is a significant amount of extra work, I don't think it's a worthwhile investment.

and the fact that supporting colored output on Windows versions prior to Windows 10 is a significant amount of extra work, I don't think it's a worthwhile investment.

It's already done. But I don't know what we're arguing about. You aren't going to convince me to stop supporting <Windows 10 users.

Here is some data - the numbers come from what I would call early adopters using the open source version of PowerShell. I'm not sure what the numbers are exactly - I think they are process launch, not number of users, but you can see 4% (80K) on pre-Win10 systems.

Sorry if this was already mentioned before but I want to just throw it out there. Are there inspirations that answer some of the questions outlined here that can be derived from prior established standards in other language communities? Color control standards doesn't necessarily feel like rust specific territory. If such standards exist I would opt for rust to find ways to honor them. As a cli user, I dont typically expect to find ux to vary by the language a cli was written in. In fact I prefer it didn't! If such standards do not exist in other communities that have been have mature cli ecosystems, does this WG feel this is still an important area to standardize on?

@softprops There are various things I'm aware of like the cli colors spec, but I don't know what kind of adoption it has. For me, when I wrote termcolor, I did a very rudimentary survey of command line applications that I knew were in widespread use, like GNU grep. For the most part, that logic is captured here: https://github.com/BurntSushi/ripgrep/blob/d7c9323a689239ac8b29baba63b1c3a26e12afda/termcolor/src/lib.rs#L135-L147 --- There isn't much to it.
Separately from that, there is the terminfo database, but I ran into problems that I didn't know how to solve, and it seemed like overkill for just needing to emit colors.
I personally would be very weary of standards in this area. Actual behavior of common command line tools wins the day IMO.

but maybe it will be OK if they all respected the same global state, not unlike how the log crate works.

I personally like this idea as ultimately I think it's the end user who needs to decide if they want color or not (and when). The only issue I see with a shared global state such as clicolors-control is one of complexity and potential for the chain to be incorrect somewhere along the line.
I might be misunderstanding, but I see it like this:

Whereas maybe something more like log (just a trait that all libs impl) would look more like this:

And could benefit from fewer branches (maybe?) and moves the global state from clicolor-control to the lib implementing the trait.
Maybe I'm way off and need coffee, but just some thoughts :stuck_out_tongue_winking_eye:

Oh, look, this was already discussed.  Wish I had checked before researching this topic.  When this thread started, I had skipped over it because I hadn't gotten into colored output yet for my applications and knew I was over my head.  Now its being a pain for me and am looking to do something about it.  styling crate authors are still interested in the global state, I'm game for implementing it.
Now onto my research:
Inspiration cases

I want to respect all color standards in typos in a consistent way (regardless of whether I'm printing, env_logger, or clap)
I want assert_cmd to print error info in color, particularly diffs generated by predicates but the API is stateless, having the user tell us to do color doesn't really fit in, and having to check the right settings and configure this in every #[test] is onerous

Aspirations
A developer can quickly adopt color within their CLI that follows best practices

API is easy to adopt
User sees consistent behavior, regardless of implementation (arg parsing, logging, etc)
Doesn't display color when piping, unless asked
Will still display color on the non-piped stream
Respects capabilities of the terminal

Gracefully degrade when color mode (truecolor, 8bit, 3bit) isn't supported
For more on truecolor, see https://gist.github.com/XVilka/8346728
On Windows, either supporting the old color API or enabling ANSI support (and disabling colors when not supported)

User can control through expected color argument (--color[=<always|auto|never>])
Respects CLICOLOR, CLICOLOR_FORCE, NO_COLOR

A developer can get richly formatted test-failure messages

Respects conventions from above
Trivial to take advantage of across all tests

Other considerations: performance should not be so bad that it is noticed (like stdout locking on println)
Survey of ecosystem
Capability crates

terminfo

Looks up and loads termcap database

termbg

Detects type of terminal (wide range)
For some terminals, it directly asks
For others, it does a print/read cycle to see how the escape sequences are handled

term (also under styling)

Styling crates

owocolors

Per-styling disable function per TTY (caller must know intended TTY)
ANSI only

yansi

Global disable, irrespective of TTY
Provides function for enabling ansi colors on Windows
ANSI only

termcolor

Auto-detect on TERM  and NO_COLOR
Supports older Windows terminals
ColorChoice can be specified when building a writer

ansi_term

Supports byte strings
Provides function for enabling ansi colors on Windows
ANSI only

nu_ansi_term

Extension of the above

colored

Respects CLICOLOR, CLICOLOR_FORCE, NO_COLOR
Checks stdout tty status, applies to all coloring
Disable colors through feature flag
Provides function for enabling ansi colors on Windows

Does not impact global color state, does not report failure so caller can change global color state

ANSI only

term (also under capabilities)

Errors if displaying colors beyond what terminal supports
Supports Windows

term-painter

stdout only
Not thread safe
Ignores errors from term (says comment, can't find where this happens though)
Supports Windows

bunt

Replaces println and friends
Wraps `termcolor, see above
Supports clearing a style, to help with user-defined color palettes that degrade

clicolors-control

Detects interactive stdout (not stderr)
Enables / checks for ANSI support on Windows
Respects CLICOLOR and CLICOLOR_FORCE

Color logic

colorparse: parse a git-style color string into ansi_term::Style
ansi_colours for converting RGB to/from 8bit
strip-ansi-escapes

"Middleware"

clap2

color feature flag
Runtime color choice (always, auto, never)
Auto looks at TERM=dumb and tty for stderr (despite also printing to stdout)

clap3

color feature flag
Runtime color choice (always, auto, never)
Auto looks at tty for stderr (despite also printing to stdout) and delegates the rest to termcolor

structopt

Like clap2 except runtime color choice flag has to be passed into a proc-macro attribute on a struct/enum which is awkward and non-obvious

eyre

Allows customizing theme, so user could use a blank theme
(built n owo_colors v1 which doesn't have if_stdout_tty / if_stderr_tty)

trybuild

Auto-detect on TERM  and NO_COLOR (hard codes to termcolors ColorChoice::Auto)

env_logger

stdout/stderr detection (for whichever is the target)
Callers can customize behavior (called WriteStyle instead of ColorChoice)
Auto-detect on TERM  and NO_COLOR

Applications

rg

Auto-detect TTY, TERM, and NO_COLOR (builds on termcolor)
Has --color=<when> flag
clap2's color is turned off because it uses a different color crate
Wraps stdout for color choice (doesn't seem to write to stderr on its own)
Oddly, it looks like TTY detection is done twice, at the arg level and within the stdout wrapper

bat

Turns off clap's coloring if non-interactive stdout (even if clap prints to stderr) or if NO_COLOR
Has --color=<when> flag
Failure to set ANSI support on windows does not impact color support
For own printing, color=auto checks for interactive stdout and NO_COLOR
Additionally checks for truecolor support via COLORTERM (degrades RGB to 8bit via ansi_colours)
For errors, unconditionally prints coloring

hyperfine

Turns off clap's coloring if non-interactive stdout (even if clap prints to stderr)
Has --style=<type> flag which includes coloring
For own printing, overrides --style if stdout is not interactive
For errors, unconditionally prints coloring

nu

At a glance, seemed to do colors unconditionally

cargo

Default initializes the env_logger (interactive stdout/stderr, TERM, NO_COLOR detection)
Default initializes clap

Auto looks at TERM=dumb and tty for stderr (despite also printing to stdout)

--color=<when>
term.color in config file
Auto-detect on TERM  and NO_COLOR, and if stderr is interactive, even if printing to stdout

Open questions

Trade offs of terminfo vs detection through env vars?

burntsushi:
I explicitly chose to not respect this, at least for things like colors or other simplistic styling like underlining or bold. The reason why is because when I did use a library that respected terminfo, I got numerous bug reports where the wrong escape codes were being emitted. Instead, I chose to follow in the footsteps of GNU grep: just stick to the basics. GNU grep is widely deployed, and I never hear anyone complaining about whether its colors work or not, which is compelling evidence from my perspective that it has the right approach here.
For CLI tools that need to do more extensive manipulation of the terminal, then this may be the wrong calculus.

What is the tipping point for recommending supporting non-ansi coloring for Windows?

ANSI coloring tends to make it easier to have a nice API
Non-ANSI means you support older Windows versions

Challenges

Per TTY detection
Knowing what TTY you are rendering for
Following conventions consistently across crates which might use different styling crates which don't specify their auto-policy, requiring digging into the code
Manual work to tunnel env vars + CLI arg to logging, error handling, clap, and through your own program
Some color support comes through indirect dependencies (assert_cmd calling predicates calling difference)
Some scenarios, like tests, are more hassle to setup correctly (duplciating through all tests)

Proposed solution:
Crates:

A singleton to control color support

Allow style crates to read the styling choice

Must be breaking-change resistant so only one version shows up in dependency tree
Report capabilities on a TTY-by-name, stream, or "lower common denominator" basis

Allow main to override it, based on command line
Expose the implementation details as other crates to allow customization / testing but don't expose to in this crate for API stability

Provide a clap-color crate for providing a standard way of specifying color in CLI
Maybe explore a shared definition for colors/styling with graceful degrading

Ideally as much is const-fn as possible

All of this is subject to adoption, see XKCD #927
This ends up being similar to what was proposed earlier when WG-CLI discussed this
Other ideas

Customize color detection via feature-flag system similar to https://github.com/That3Percent/firestorm (if that even works still with the new feature resolver)
Configure logging via Existential types with external definition

You forgot console in styling crates list.

A singleton to control color support

clicolors-control crate is an attempt at it.

You forgot console in styling crates list.

Huh, surprised I missed one that has so many downloads.  I suspect it doesn't add anything new but I'll try to take a look at it earlier

A singleton to control color support

clicolors-control crate is an attempt at it.

Yes, as I mention in the beginning, I found this thread (and clicolors-control) after doing all of this and only did minor touch ups to acknowledge it.  I need to spend some more time on it to see how well it meets the aspirations listed out.

Things missing from  clicolors-control

Treat stdout and stderr distinctly
NO_COLOR support
Truecolor support

The API needs to be able to detect level of color support given either stdout/stderr (names), a stream, or "lowest common denominator".
If we build on clicolors-control, We can introduce these without a breaking change, carefully choosing what new behavior the old APIs map to, but I suspect we should consider breaking the API to optimize for people using it correctly with these new requirements, since no one is listed as depending on it at the moment.
I suspect the easiest way to implement this will be to put all of this into a bitfield in an atomic u32.
It can be a starting point if @mitsuhiko is up for it though it won't be hard to do something similar.

Just read up on the new feature resolver (blog post, edition guide).  It sounds like firestorm is not impacted and that we could do something similar.  All libs could depend on a no-op version of the CLI color control crate.  An application can then enable the features it wants.  I think a middle ground would also be acceptable, libs could choose to depend on the default policy if they offer it through a color feature flag, whether its default or not.

Remember that terminfo and termcap came from a time when there were a lot of very weird non-VT-series terminals around, and if you wanted your app to work at all, then you had to use the peculiar sequences required by those terminals. Nowadays it's reasonable to assume basic ANSI support. So, for colour if you just use plain 8-colour ANSI sequences and maybe bold, it shouldn't need any feature testing. So either aim for the lowest common denominator (easy) or try to get fancy and detect extra features (harder). Also bear in mind that the user might be running with either a white or black default background (colour 49). So blue on default-background might be readable on white, but probably won't be on black. This is all UNIX, though -- I don't know the Windows situation.

We need to handle the CLI case, like concolor-clap.  The developer needs to the ability to say "do what you want".

This could be handled by just not calling set

I try to avoid APIs where a state can't be unset, usually regretting that constraint

This could be handled by the developer doing a get

This is adding extra boilerplate that an enum resolves

On top of those

The Rust API Guidelines encourage using enums over bools to clarify intent
None of these cases help with AlwaysAnsi vs Always for styling still supporting pre-ANSI coloring on Windows.


Access to the path 'C:\WINDOWS\system32\config\systemprofile' is denied.

Access to the path 'C:\WINDOWS\system32\config\systemprofile' is denied.
I had .net Core 2.0 running on our server. I have just installed .Net Core 2.1 and redeployed my WebApi and on IIS and now I get the following in a Log File:
System.UnauthorizedAccessException: Access to the path 'C:\WINDOWS\system32\config\systemprofile' is denied.
at System.IO.FileSystem.CreateDirectory(String fullPath)
at System.IO.Directory.CreateDirectory(String path)
at Microsoft.Extensions.EnvironmentAbstractions.DirectoryWrapper.CreateDirectory(String path)
at Microsoft.DotNet.Configurer.FileSentinel.Create()
at Microsoft.DotNet.Configurer.DotnetFirstTimeUseConfigurer.Configure()
at Microsoft.DotNet.Cli.Program.ConfigureDotNetForFirstTimeUse(INuGetCacheSentinel nugetCacheSentinel, IFirstTimeUseNoticeSentinel firstTimeUseNoticeSentinel, IAspNetCertificateSentinel aspNetCertificateSentinel, IFileSentinel toolPathSentinel, Boolean hasSuperUserAccess, DotnetFirstRunConfiguration dotnetFirstRunConfiguration, IEnvironmentProvider environmentProvider)
at Microsoft.DotNet.Cli.Program.ProcessArgs(String[] args, ITelemetry telemetryClient)
at Microsoft.DotNet.Cli.Program.Main(String[] args)
How do I fix this?

I gave IIS_IUSRS  Read/Write access to: 'C:\WINDOWS\system32\config\systemprofile'
now in the log file I get:
Welcome to .NET Core!
Learn more about .NET Core: https://aka.ms/dotnet-docs
Use 'dotnet --help' to see available commands or visit: https://aka.ms/dotnet-cli-docs
Telemetry
The .NET Core tools collect usage data in order to help us improve your experience. The data is anonymous and doesn't include command-line arguments. The data is collected by Microsoft and shared with the community. You can opt-out of telemetry by setting the DOTNET_CLI_TELEMETRY_OPTOUT environment variable to '1' or 'true' using your favorite shell.
Read more about .NET Core CLI Tools telemetry: https://aka.ms/dotnet-cli-telemetry
ASP.NET Core
Successfully installed the ASP.NET Core HTTPS Development Certificate.
To trust the certificate run 'dotnet dev-certs https --trust' (Windows and macOS only). For establishing trust on other platforms refer to the platform specific documentation.
For more information on configuring HTTPS see https://go.microsoft.com/fwlink/?linkid=848054.
No executable found matching command "dotnet-.\Crm.WebApi.dll"
I have run the command  'dotnet dev-certs https --trust'  and the certificate is already installed.
Everytime I try to get the Web Api to run I get No executable found matching command "dotnet-.\Crm.WebApi.dll"

This looks like the first run experience that write some sentinel files to know whether it has run before. Moving to the CLI repo.

Issue moved to dotnet/cli #9941 via ZenHub


Fixed smoke examples in docs

Fixed issue #277 . Made the docs coherent with the system when mentioning the spouse example.

Coverage increased (+0.35%) to 70.77% when pulling d4c1e75cd9cae7a38dfcbfa4bbddef812572b75d on hotfix-docs-variable into 88b37d31bebcd5cb3bf7c91551a44956762f19f5 on master.

@netj Could you remove these changes? Thanks!

Coverage remained the same at 70.43% when pulling d670c238bf238add149319dce93e244c3bd97915 on hotfix-docs-variable into 88b37d31bebcd5cb3bf7c91551a44956762f19f5 on master.


should a Producer be forced to produce?

In the code for skip(), I noticed this call to bridge_producer_consumer():
let (before_skip, after_skip) = base.split_at(self.n);
bridge_producer_consumer(self.n, before_skip, NoopConsumer::new());
self.callback.callback(after_skip)

It seems odd to me that we do this, rather than just throw away before_skip. In particular, I do think that consumers can expect to be "fed" all the items that a parallel iterator promised (i.e., what it returned for len() or opt_len()). But I don't think that producers should necessarily expect to be "driven" by having all of their items pulled (and, in this case, discarded).
I'm inclined to drop that call to bridge_producer_consumer(). Thoughts?

That was to maintain side-effect symmetry with Iterator::skip : https://github.com/nikomatsakis/rayon/pull/162#issuecomment-261684136
If you want to weaken that symmetry, then sure, we could throw the first half away, just like take throws away its second half.  (IOW take already proves that producers may be incompletely driven.)

For that matter, we also have many short-circuiting ops like find_any.  So I don't think there's any general expectation that producers will fully produce -- skip just needs additional consideration for side effects.

ah, yeah, forgot about the side-effects

I changed the title since I think we agree that producers are not forced to produce.


Add and use pc.list to have list mutation detection

To add and use pc.list/PcList to have list mutation detection.
It's not as straightforward as I thought. Or is my approach too complicated?
For #334. pc.dict would be in another PR.

Sorry for the delay in reviewing this, will get to it soon!

@picklelo @kbrgl thanks for the reviews.
@picklelo What are the edge cases we haven't covered in this PR? Will have a follow up PR for them.


CHS Translation with Small Fixes and Optimizations

The commits
Credit: GH.03

Seems that this PR is no longer necessary :)