text:
wrong api response for healthcheck interval and timeout values

Welcome!

[X] Yes, I've searched similar issues on GitHub and didn't find any.
[X] Yes, I've searched similar issues on the Traefik community forum and didn't find any.

What did you do?
I configured healthcheck interval or timeout to "wrong" values, e.g. -10s for interval
What did you see instead?
In the api response (and webui) the values for interval and timeout are the same as in the config (in this case -10s), but in reality, they are some sort of fallback values (in this case 30s for interval)
What version of Traefik are you using?
Version:      2.9.10
Codename:     banon
Go version:   go1.20.3
Built:        2023-04-06T16:15:08Z
OS/Arch:      linux/amd64

What is your environment & configuration?
services:
  traefik:
    image: traefik
    command:
      - --api.insecure=true
      - --providers.docker=true
      - --log.level=DEBUG
    ports:
      - "8080:8080"
    volumes:
      - /run/user/1000/docker.sock:/var/run/docker.sock
  whoami:
    image: traefik/whoami
    labels:
      - "traefik.http.services.myservice.loadbalancer.healthcheck.path=/health"
      - "traefik.http.services.myservice.loadbalancer.healthcheck.interval=-10s"

If applicable, please paste the log output in DEBUG level
time="2023-04-18T00:10:28Z" level=info msg="Configuration loaded from flags."
time="2023-04-18T00:10:28Z" level=info msg="Traefik version 2.9.10 built on 2023-04-06T16:15:08Z"
time="2023-04-18T00:10:28Z" level=debug msg="Static configuration loaded {\"global\":{\"checkNewVersion\":true},\"serversTransport\":{\"maxIdleConnsPerHost\":200},\"entryPoints\":{\"http\":{\"address\":\":80\",\"transport\":{\"lifeCycle\":{\"graceTimeOut\":\"10s\"},\"respondingTimeouts\":{\"idleTimeout\":\"3m0s\"}},\"forwardedHeaders\":{},\"http\":{},\"http2\":{\"maxConcurrentStreams\":250},\"udp\":{\"timeout\":\"3s\"}},\"traefik\":{\"address\":\":8080\",\"transport\":{\"lifeCycle\":{\"graceTimeOut\":\"10s\"},\"respondingTimeouts\":{\"idleTimeout\":\"3m0s\"}},\"forwardedHeaders\":{},\"http\":{},\"http2\":{\"maxConcurrentStreams\":250},\"udp\":{\"timeout\":\"3s\"}}},\"providers\":{\"providersThrottleDuration\":\"2s\",\"docker\":{\"watch\":true,\"endpoint\":\"unix:///var/run/docker.sock\",\"defaultRule\":\"Host(`{{ normalize .Name }}`)\",\"exposedByDefault\":true,\"swarmModeRefreshSeconds\":\"15s\"}},\"api\":{\"insecure\":true,\"dashboard\":true},\"log\":{\"level\":\"DEBUG\",\"format\":\"common\"}}"
time="2023-04-18T00:10:28Z" level=info msg="\nStats collection is disabled.\nHelp us improve Traefik by turning this feature on :)\nMore details on: https://doc.traefik.io/traefik/contributing/data-collection/\n"
time="2023-04-18T00:10:28Z" level=info msg="Starting provider aggregator aggregator.ProviderAggregator"
time="2023-04-18T00:10:28Z" level=debug msg="Starting TCP Server" entryPointName=traefik
time="2023-04-18T00:10:28Z" level=debug msg="Starting TCP Server" entryPointName=http
time="2023-04-18T00:10:28Z" level=info msg="Starting provider *traefik.Provider"
time="2023-04-18T00:10:28Z" level=debug msg="*traefik.Provider provider configuration: {}"
time="2023-04-18T00:10:28Z" level=info msg="Starting provider *docker.Provider"
time="2023-04-18T00:10:28Z" level=debug msg="*docker.Provider provider configuration: {\"watch\":true,\"endpoint\":\"unix:///var/run/docker.sock\",\"defaultRule\":\"Host(`{{ normalize .Name }}`)\",\"exposedByDefault\":true,\"swarmModeRefreshSeconds\":\"15s\"}"
time="2023-04-18T00:10:28Z" level=info msg="Starting provider *acme.ChallengeTLSALPN"
time="2023-04-18T00:10:28Z" level=debug msg="*acme.ChallengeTLSALPN provider configuration: {}"
time="2023-04-18T00:10:28Z" level=debug msg="Configuration received: {\"http\":{\"routers\":{\"api\":{\"entryPoints\":[\"traefik\"],\"service\":\"api@internal\",\"rule\":\"PathPrefix(`/api`)\",\"priority\":2147483646},\"dashboard\":{\"entryPoints\":[\"traefik\"],\"middlewares\":[\"dashboard_redirect@internal\",\"dashboard_stripprefix@internal\"],\"service\":\"dashboard@internal\",\"rule\":\"PathPrefix(`/`)\",\"priority\":2147483645}},\"services\":{\"api\":{},\"dashboard\":{},\"noop\":{}},\"middlewares\":{\"dashboard_redirect\":{\"redirectRegex\":{\"regex\":\"^(http:\\\\/\\\\/(\\\\[[\\\\w:.]+\\\\]|[\\\\w\\\\._-]+)(:\\\\d+)?)\\\\/$\",\"replacement\":\"${1}/dashboard/\",\"permanent\":true}},\"dashboard_stripprefix\":{\"stripPrefix\":{\"prefixes\":[\"/dashboard/\",\"/dashboard\"]}}},\"serversTransports\":{\"default\":{\"maxIdleConnsPerHost\":200}}},\"tcp\":{},\"udp\":{},\"tls\":{}}" providerName=internal
time="2023-04-18T00:10:28Z" level=debug msg="Provider connection established with docker 23.0.3 (API 1.42)" providerName=docker
time="2023-04-18T00:10:28Z" level=debug msg="Configuration received: {\"http\":{\"routers\":{\"traefik-traefik\":{\"service\":\"traefik-traefik\",\"rule\":\"Host(`traefik-traefik`)\"},\"whoami-traefik\":{\"service\":\"myservice\",\"rule\":\"Host(`whoami-traefik`)\"}},\"services\":{\"myservice\":{\"loadBalancer\":{\"servers\":[{\"url\":\"http://172.20.0.2:80\"}],\"healthCheck\":{\"path\":\"/health\",\"interval\":\"-10s\",\"followRedirects\":true},\"passHostHeader\":true}},\"traefik-traefik\":{\"loadBalancer\":{\"servers\":[{\"url\":\"http://172.20.0.3:80\"}],\"passHostHeader\":true}}}},\"tcp\":{},\"udp\":{}}" providerName=docker
time="2023-04-18T00:10:28Z" level=debug msg="No default certificate, fallback to the internal generated certificate" tlsStoreName=default
time="2023-04-18T00:10:28Z" level=debug msg="Added outgoing tracing middleware dashboard@internal" middlewareType=TracingForwarder entryPointName=traefik routerName=dashboard@internal middlewareName=tracing
time="2023-04-18T00:10:28Z" level=debug msg="Creating middleware" entryPointName=traefik middlewareName=dashboard_stripprefix@internal middlewareType=StripPrefix routerName=dashboard@internal
time="2023-04-18T00:10:28Z" level=debug msg="Adding tracing to middleware" entryPointName=traefik middlewareName=dashboard_stripprefix@internal routerName=dashboard@internal
time="2023-04-18T00:10:28Z" level=debug msg="Creating middleware" entryPointName=traefik routerName=dashboard@internal middlewareName=dashboard_redirect@internal middlewareType=RedirectRegex
time="2023-04-18T00:10:28Z" level=debug msg="Setting up redirection from ^(http:\\/\\/(\\[[\\w:.]+\\]|[\\w\\._-]+)(:\\d+)?)\\/$ to ${1}/dashboard/" entryPointName=traefik routerName=dashboard@internal middlewareName=dashboard_redirect@internal middlewareType=RedirectRegex
time="2023-04-18T00:10:28Z" level=debug msg="Adding tracing to middleware" entryPointName=traefik middlewareName=dashboard_redirect@internal routerName=dashboard@internal
time="2023-04-18T00:10:28Z" level=debug msg="Added outgoing tracing middleware api@internal" entryPointName=traefik routerName=api@internal middlewareName=tracing middlewareType=TracingForwarder
time="2023-04-18T00:10:28Z" level=debug msg="Creating middleware" middlewareName=traefik-internal-recovery entryPointName=traefik middlewareType=Recovery
time="2023-04-18T00:10:28Z" level=debug msg="No entryPoint defined for this router, using the default one(s) instead: [http]" routerName=whoami-traefik
time="2023-04-18T00:10:28Z" level=debug msg="No entryPoint defined for this router, using the default one(s) instead: [http]" routerName=traefik-traefik
time="2023-04-18T00:10:28Z" level=debug msg="No default certificate, fallback to the internal generated certificate" tlsStoreName=default
time="2023-04-18T00:10:28Z" level=debug msg="Added outgoing tracing middleware api@internal" entryPointName=traefik routerName=api@internal middlewareName=tracing middlewareType=TracingForwarder
time="2023-04-18T00:10:28Z" level=debug msg="Added outgoing tracing middleware dashboard@internal" middlewareName=tracing middlewareType=TracingForwarder entryPointName=traefik routerName=dashboard@internal
time="2023-04-18T00:10:28Z" level=debug msg="Creating middleware" middlewareName=dashboard_stripprefix@internal middlewareType=StripPrefix entryPointName=traefik routerName=dashboard@internal
time="2023-04-18T00:10:28Z" level=debug msg="Adding tracing to middleware" entryPointName=traefik routerName=dashboard@internal middlewareName=dashboard_stripprefix@internal
time="2023-04-18T00:10:28Z" level=debug msg="Creating middleware" entryPointName=traefik routerName=dashboard@internal middlewareType=RedirectRegex middlewareName=dashboard_redirect@internal
time="2023-04-18T00:10:28Z" level=debug msg="Setting up redirection from ^(http:\\/\\/(\\[[\\w:.]+\\]|[\\w\\._-]+)(:\\d+)?)\\/$ to ${1}/dashboard/" entryPointName=traefik routerName=dashboard@internal middlewareType=RedirectRegex middlewareName=dashboard_redirect@internal
time="2023-04-18T00:10:28Z" level=debug msg="Adding tracing to middleware" entryPointName=traefik routerName=dashboard@internal middlewareName=dashboard_redirect@internal
time="2023-04-18T00:10:28Z" level=debug msg="Creating middleware" middlewareType=Recovery entryPointName=traefik middlewareName=traefik-internal-recovery
time="2023-04-18T00:10:28Z" level=debug msg="Creating middleware" entryPointName=http routerName=whoami-traefik@docker serviceName=myservice middlewareName=pipelining middlewareType=Pipelining
time="2023-04-18T00:10:28Z" level=debug msg="Creating load-balancer" entryPointName=http routerName=whoami-traefik@docker serviceName=myservice
time="2023-04-18T00:10:28Z" level=debug msg="Creating server 0 http://172.20.0.2:80" serverName=0 entryPointName=http routerName=whoami-traefik@docker serviceName=myservice
time="2023-04-18T00:10:28Z" level=debug msg="child http://172.20.0.2:80 now UP"
time="2023-04-18T00:10:28Z" level=debug msg="Propagating new UP status"
time="2023-04-18T00:10:28Z" level=debug msg="Added outgoing tracing middleware myservice" entryPointName=http middlewareName=tracing middlewareType=TracingForwarder routerName=whoami-traefik@docker
time="2023-04-18T00:10:28Z" level=debug msg="Creating middleware" entryPointName=http routerName=traefik-traefik@docker middlewareType=Pipelining middlewareName=pipelining serviceName=traefik-traefik
time="2023-04-18T00:10:28Z" level=debug msg="Creating load-balancer" routerName=traefik-traefik@docker serviceName=traefik-traefik entryPointName=http
time="2023-04-18T00:10:28Z" level=debug msg="Creating server 0 http://172.20.0.3:80" routerName=traefik-traefik@docker serverName=0 serviceName=traefik-traefik entryPointName=http
time="2023-04-18T00:10:28Z" level=debug msg="child http://172.20.0.3:80 now UP"
time="2023-04-18T00:10:28Z" level=debug msg="Propagating new UP status"
time="2023-04-18T00:10:28Z" level=debug msg="Added outgoing tracing middleware traefik-traefik" middlewareType=TracingForwarder entryPointName=http routerName=traefik-traefik@docker middlewareName=tracing
time="2023-04-18T00:10:28Z" level=debug msg="Creating middleware" middlewareName=traefik-internal-recovery middlewareType=Recovery entryPointName=http
time="2023-04-18T00:10:28Z" level=error msg="Health check interval smaller than zero for service 'myservice@docker'" serviceName=myservice@docker
time="2023-04-18T00:10:28Z" level=debug msg="Setting up healthcheck for service myservice@docker with [Hostname:  Headers: map[] Path: /health Method:  Port: 0 Interval: 30s Timeout: 5s FollowRedirects: true]" serviceName=myservice@docker
time="2023-04-18T00:10:28Z" level=debug msg="Initial health check for backend: \"myservice@docker\""

last three lines are relevant here

Hello @1-Samuel ,
We've looked into it, and we agree that the lack of consistency between the effective configuration of traefik and the "raw data" returned by the API is annoying and disturbing (although not very concerning in itself in our opinion).
So here is our plan:

for v3, we actually would like to take another route: in such a case of wonky input from the user (e.g. -10s) we're of the opinion that we should log a clear error about it, and simply fail. And not try to cover up the mistake with a "saner" default. We've actually already taken such steps for similar situations in v3, and we think we should keep that trend going.

for v2, we cannot do the same as above, because it would be a breaking change. We may want to go in the direction you suggested (i.e. fix the raw data so that it fits with the effective configuration), but we're not convinced yet that the exact fix you proposed is the way we want to go. And tbh, we're not even sure that changing anything at all is worth the effort for v2.
So we would like to think about it some more, and also gauge the interest of the community on that matter.

WDYT?
Thanks.

Hello,
thank you for looking into the issue. Sounds like a good plan to me. :+1:
I only stumbled upon the issue while looking into #6550 and I couldn't think of a good way to write a test for retry intervals, so I thought I give the bug fix a try, just to practice a bit. :) I don't think many people with a real use case will run into this issue anyway.
Thank you  :)

Hello @mpl ,
yeah I will have a look at implementing the v3 changes (fail if implausible values are configured). But I think making a new PR would make more sense, since the changes would be different all together. I'll close it :)


text:
What is the status of Binary Ninja support? DynInst support?

These are some questions and a documentation bug report (insofar as the README is a bit confusing or doesn't answer these questions).
The top of the README states:

Control flow recovery is performed using the mcsema-disass tool, which relies on IDA Pro, Binary Ninja, or DynInst to disassemble a binary file and produce a control flow graph.

and later...

Currently IDA and BinaryNinja are supported for control-flow recovery...

but not dyninst...? (I see there are several abandoned or pending PRs).
Then later...

Why do I need IDA Pro to use McSema ... we have a branch with experimental Binary Ninja support ...

It looks like the referenced branch is deleted (presumably merged?). I also see a ninja branch referenced in a PR, and another one hanging out. What is the status of Binary Ninja support?
I'm trying out McSema for fun. I might shell out $150 for binary ninja if I was sure it would work (but maybe McSema requires the $600 version for its API?).
Thanks!

Also getting slightly off topic, I tried out the freeware version of IDA on the off chance it worked and no one has noticed. It doesn't and I don't get any helpful errors (is idal64 the headless version that McSema needs? if so I guess they don't ship that with the freeware version), but I wonder if the free version could be made to work in some other way? Or maybe y'all could try to convince them to release the functionality McSema needs in the free version (still for non-commercial use)? Seems mutually beneficial, but what do I know

@jberryman I have not tested IDA Pro Free Version, but if it includes IDAPython it should work. Use of idal64 is not required; you can use idaq64, but you have to do it from an X session since it has to start a GUI. I do this when debugging the CFG recovery scripts.

Thanks. Hm, doesn't seem to. The IDA free tree looks like:
/home/me/.local/idafree-7.0/
├── appico64.png
├── assistant
├── cfg
│   ├── ida.cfg
│   └── idagui.cfg
├── dbgsrv
├── ida64
├── ida64.int
├── ida.hlp
├── idc
│   └── idc.idc
├── ids
│   ├── idsnames
│   └── win7.zip
├── libclpx.so
├── libdwarfx.so
├── libida64.so
├── libQt5CLucene.so.5
├── libQt5Core.so.5
├── libQt5DBus.so.5
├── libQt5Gui.so.5
├── libQt5Help.so.5
├── libQt5Network.so.5
├── libQt5PrintSupport.so.5
├── libQt5Sql.so.5
├── libQt5Widgets.so.5
├── libQt5XcbQpa.so.5
├── libX11-xcb.so.1
├── license.txt
├── loaders
│   ├── elf64.so
│   ├── macho64.so
│   └── pe64.so
├── plugins
│   ├── bdescr64.so
│   ├── dbg64.so
│   ├── dwarf64.so
│   ├── objc64.so
│   ├── platforms
│   │   ├── libqlinuxfb.so
│   │   ├── libqminimal.so
│   │   ├── libqoffscreen.so
│   │   └── libqxcb.so
│   ├── platformthemes
│   │   └── libqgtk2.so
│   ├── plugins.cfg
│   └── tds64.so
├── procs
│   └── pc64.so
├── qidahelpcollection.qhc
├── qidahelp.qch
├── qt.conf
├── qwingraph
├── sig
│   ├── list
│   └── pc
│       ├── bcb5rt.sig
│       ├── iclapp64.sig
│       ├── ms64wdk.sig
│       ├── msmfc64d.sig
│       ├── msmfc64.sig
│       ├── msmfc64u.sig
│       ├── mssdk64.sig
│       ├── pe64.sig
│       ├── vc32rtf.sig
│       ├── vc64_14.sig
│       ├── vc64atl.sig
│       ├── vc64extra.sig
│       ├── vc64mfc.sig
│       ├── vc64rtf.sig
│       ├── vc64seh.sig
│       ├── vc64ucrt.sig
│       ├── vcseh.sig
│       └── win64unx.sig
├── til
│   ├── gnuunx64.til
│   ├── macosx64.til
│   └── pc
│       ├── bcb5win.til
│       ├── gnulnx_x64.til
│       ├── mssdk.til
│       ├── ntddk64.til
│       ├── vc10_64.til
│       ├── vc6win.til
│       └── vc8amd64.til
├── uninstall
├── uninstall.dat
└── Uninstall IDA Free.desktop

Sadly it looks like the free version is missing IDAPython so the script will not work.

Closing for now.

source: gharchive/issue

authors: artemdinaburg jberryman pgoodman

repo: trailofbits/mcsema

license_type: permissive

license_source: bigquery


text:
requirement, pypi: Add a --require-hashes flag

Closes #172

This needs cleanup + testing but I wanted to engage early on this one since the intended behaviour isn't straightforward.
@di You mentioned that the --require-hashes flag should skip dependency resolution. Did you mean that we shouldn't resolve dependencies for each requirement and instead, only audit what is explicitly listed in the requirements file?
I was also wondering how hashes should work when the --require-hashes flag isn't supplied. My thinking is that when the --require-hashes flag is supplied, every requirement in the file needs to have a hash. But if it isn't supplied, we should still check any hashes that we find against PyPI.

You mentioned that the --require-hashes flag should skip dependency resolution. Did you mean that we shouldn't resolve transitive dependencies for each requirement and instead, only audit what is explicitly listed in the requirements file?
I was also wondering how hashes should work when the --require-hashes flag isn't supplied. My thinking is that when the --require-hashes flag is supplied, every requirement in the file needs to have a hash AND we check them against PyPI. But if the flag isn't supplied, we should still check any hashes that we find against PyPI and fail if it doesn't match.

This is an indirect answer to both: we can skip dependency resolution entirely, since pip stipulates the following:

If any dependency has a content hash, then all dependencies have content hashes
(Transitively) All dependencies must be explicitly listed in the requirements file if hashing is enabled

In other words: our requirements parser in pip-api should preserve those properties: we should raise an error if we're given a requirements file with dependencies that are missing hashes, and we should not do dependency resolution because only the present hashed dependencies should be considered.
(Looking at things more, I'm not actually sure that we need the --require-hashes flag -- pip stipulates that passing it is identical to any requirement having hashes attached to it. But I guess we should preserve it as a no-op, since that's what pip seems to do?

In other words: our requirements parser in pip-api should preserve those properties: we should raise an error if we're given a requirements file with dependencies that are missing hashes, and we should not do dependency resolution because only the present hashed dependencies should be considered.

Ah! Right, I misunderstood how that works. Thanks for explaining.

(Looking at things more, I'm not actually sure that we need the --require-hashes flag -- pip stipulates that passing it is identical to any requirement having hashes attached to it. But I guess we should preserve it as a no-op, since that's what pip seems to do?

I think it's still important because your file may not have ANY hashes in it. If you pass in --require-hashes, it will complain whereas it otherwise would succeed.

I think it's still important because your file may not have ANY hashes in it. If you pass in --require-hashes, it will complain whereas it otherwise would succeed.

Ah! You're absolutely right. Yes, we need it for that case.

@di You mentioned that the --require-hashes flag should skip dependency resolution. Did you mean that we shouldn't resolve transitive dependencies for each requirement and instead, only audit what is explicitly listed in the requirements file?

Thinking about this more, I think we still need to do dependency resolution, and ensure that we have hashes for all subdependencies, because this is what pip does as well:
$ cat req.txt
sampleproject==2.0.0 \
    --hash=sha256:2b0c55537193b792098977fdb62f0acbaeb2c3cfc56d0e24ccab775201462e04 \
    --hash=sha256:d99de34ffae5515db43916ec47380d3c603e9dead526f96581b48c070cc816d3

$ python -m pip install -r req.txt
Collecting sampleproject==2.0.0 (from -r req.txt (line 1))
  Using cached https://files.pythonhosted.org/packages/b8/f7/dd9223b39f683690c30f759c876df0944815e47b588cb517e4b9e652bcf7/sampleproject-2.0.0-py3-none-any.whl
Collecting peppercorn (from sampleproject==2.0.0->-r req.txt (line 1))
ERROR: In --require-hashes mode, all requirements must have their versions pinned with ==. These do not:
    peppercorn from https://files.pythonhosted.org/packages/14/84/d8d9c3f17bda2b6f49406982546d6f6bc0fa188a43d4e3ba9169a457ee04/peppercorn-0.6-py3-none-any.whl#sha256=46125cad688a9cf3b08e463bcb797891ee73ece93602a8ea6f14e40d1042d454 (from sampleproject==2.0.0->-r req.txt (line 1))

I think it's still important because your file may not have ANY hashes in it. If you pass in --require-hashes, it will complain whereas it otherwise would succeed.

Agreed!

Thinking about this more, I think we still need to do dependency resolution, and ensure that we have hashes for all subdependencies, because this is what pip does as well:

Can we leave that validation to pip and not attempt to do that validation ourselves? I imagine that's going to introduce a significant chunk of code reinventing what pip does which will have to be removed during integration, since pip already contains this logic.

Can we leave that validation to pip and not attempt to do it ourselves? I imagine that's going to introduce a significant chunk of code reinventing what pip does which will have to be removed during integration, since pip already contains this logic.

I'm inclined to agree with this, although it does deviate our handling of --require-hashes from that of pip (our --require-hashes is more like --no-deps --require-hashes). My reasoning is that pip-audit isn't in the business of telling the user whether pip install ... would succeed, and that the overwhelming majority of hashed requirements files should be valid already (since, if they're like Warehouse's, they're checked in after successful local and CI usage).
Thoughts @di?

I suppose the pip install with an incompletely hashed requirements file, or a hashed requirements file that's missing dependencies, would fail to install anyways, so the user would be protected regardless.

source: gharchive/pull-request

authors: di tetsuo-cpp woodruffw

repo: trailofbits/pip-audit

license_source: github-api


text:
Downgrades react-intl to fix importStar error

This fixes an issue with websites that have an old version of requirejs. react intl v5 > relies on import *, which the older version of requirejs does not support

see https://github.com/transcend-io/consent-manager-ui/pull/101

repo: transcend-io/consent-manager-ui

license: MIT


text:
WIP: Adds UI for confirming pre-approval request deletion [delivers #161129636]

Description
Delete UI, some spacing issues to work out. WIP.
Breaks out the PreApprovalRequest row into its own component that owns the state of whether the delete UI is shown
Code Review Verification Steps

[ ] End to end tests pass (make e2e_test).
[ ] Code follows the guidelines for Logging
[ ] The requirements listed in
Querying the Database Safely
have been satisfied.
Any new migrations/schema changes:

[ ] Follow our guidelines for zero-downtime deploys (see Zero-Downtime Deploys)
[ ] Have been communicated to #dp3-engineering

[ ] There are no aXe warnings for UI.
[ ] This works in IE.
Any new client dependencies (Google Analytics, hosted libraries, CDNs, etc) have been:

[ ] Communicated to @willowbl00
[ ] Added to the list of network dependencies

[ ] Request review from a member of a different team.
[ ] Have the Pivotal acceptance criteria been met for this change?

References

Pivotal story for this change

Screenshots

This is a great start, but I'm not sure how you plan on signaling that one of the deletion confirms is open to prevent this:

authors: stangah tinyels

repo: transcom/mymove


text:
B 20441 int

Agility ticket
Summary
Updating migrations to add WHERE NOT EXIST to protect against any issues from running the migration more than once
Verification Steps for the Author
These are to be checked by the author.

[ ] Tested in the Experimental environment (for changes to containers, app startup, or connection to data stores)
[ ] Have the Agility acceptance criteria been met for this change?

Verification Steps for Reviewers
These are to be checked by a reviewer.

[ ] Has the branch been pulled in and checked out?
[ ] Have the BL acceptance criteria been met for this change?
[ ] Was the CircleCI build successful?
[ ] Has the code been reviewed from a standards and best practices point of view?

Setup to Run the Code

Instructions for starting storybook
Instructions for starting the MilMove application
Instructions for running tests

How to test

Access the
Login as a

Frontend

[ ] There are no aXe warnings for UI.
[ ] This works in Supported Browsers and their phone views (Chrome, Firefox, Edge).
[ ] There are no new console errors in the browser devtools.
[ ] There are no new console errors in the test output.
[ ] If this PR adds a new component to Storybook, it ensures the component is fully responsive, OR if it is intentionally not, a wrapping div using the officeApp class or custom min-width styling is used to hide any states the would not be visible to the user.
[ ] This change meets the standards for Section 508 compliance.

Backend

[ ] Code follows the guidelines for Logging.
[ ] The requirements listed in Querying the Database Safely have been satisfied.

Database
Any new migrations/schema changes:

[ ] Follows our guidelines for Zero-Downtime Deploys.
[ ] Have been communicated to #g-database.
[ ] Secure migrations have been tested following the instructions in our docs.

Screenshots

Warnings

:warning:

Files located in legacy directories (src/shared or src/scenes) have
been edited. Are you sure you don’t want to also relocate them to the new file structure?
View the frontend file org ADR for more information

  Generated by :no_entry_sign: dangerJS against 912398a13be2e07babfe0d644614ac7640536f9b

authors: CoryKleinjanCACI robot-mymove


text:
[MB-8204] Refactor TXO MTO fetch to not query for MoveTaskOrder

Description
Explain a little about the changes at a high level.
Reviewer Notes
Is there anything you would like reviewers to give additional scrutiny?
Setup
Add any steps or code to run in this section to help others prepare to run your code:
echo "Code goes here"

Code Review Verification Steps

[ ] If the change is risky, it has been tested in experimental before merging.
[ ] Code follows the guidelines for Logging
[ ] The requirements listed in Querying the Database Safely have been satisfied.
Any new migrations/schema changes:

[ ] Follow our guidelines for zero-downtime deploys (see Zero-Downtime Deploys)
[ ] Have been communicated to #g-database
[ ] Secure migrations have been tested following the instructions in our docs

[ ] There are no aXe warnings for UI.
[ ] This works in Supported Browsers and their phone views (Chrome, Firefox, IE, Edge).
[ ] Tested in the Experimental environment (for changes to containers, app startup, or connection to data stores)
[ ] User facing changes have been reviewed by design.
[ ] Request review from a member of a different team.
[ ] Have the Jira acceptance criteria been met for this change?

References

Jira story for this change
this article explains more about the approach used.

Screenshots
If this PR makes visible UI changes, an image of the finished UI can help reviewers and casual
observers understand the context of the changes. A before image is optional and
can be included at the submitter's discretion.
Consider using an animated image to show an entire workflow instead of using multiple images. You may want to use GIPHY CAPTURE for this! 📸
Please frame screenshots to show enough useful context but also highlight the affected regions.

Warnings

:warning:

Files located in legacy directories (src/shared or src/scenes) have
been edited. Are you sure you don’t want to also relocate them to the new file structure?
View the frontend file org ADR for more information

Messages

:book:
:link: MB-8204

  Generated by :no_entry_sign: dangerJS against 94d60bf5a36c4b8cb0ee8d8665c616b86dd29ecd

This looks good so far. I love removing code. Here are a few more things we need to remove:
https://github.com/transcom/mymove/blob/master/pkg/services/move_task_order.go#L37
https://github.com/transcom/mymove/blob/master/pkg/services/move_task_order.go#L58
https://github.com/transcom/mymove/blob/master/pkg/services/move_task_order/move_task_order_fetcher.go#L23-L40
And then we'll need to regenerate the mocks:
make mocks_generate

authors: hannaliebl monfresh robot-mymove


text:
[MB-8827] Bump storybook-related dependencies to 6.3.6

Description
This PR consolidates the following dependabot PRs related to upgrading Storybook to version 6.3.6:
#7068
#7066
#7063
#7061
#7060
Setup
Just need to ensure the tests and build pass with no issues.

Messages

:book:
:link: MB-8827

  Generated by :no_entry_sign: dangerJS against 822e9a2a4009fb08faf5fa03ce3c70fc897a2d6b

Can a front-end person confirm the happo diffs are okay? Especially the document viewer one (the diff shows it as loading instead of present)
cc: @YanZ777 @jenniferlynparsons

authors: pearl-truss robot-mymove


text:
[MB-11012] Fixes bug where NTS shipment turns into HHG when editing as a SC

Jira ticket for this change
Summary
We ran across a bug in the services counselor UI where editing an NTS shipment turns it into an HHG after submission.  This PR addresses that issue (it looks like we had just hardcoded the HHG as an input to the component).
I also noticed that we were using some old naming for ntsSac and ntsTac in some places.  That was causing those values (if present on the order record) to not show up on the edit form, for instance.  Those are fixed as well in this PR.
Note to reviewers: Are there any particular tests I need to add/edit for this?
Setup to Run Your Code

💻 You will need to use three separate terminals to test this locally.
Terminal 1
Start the Storybook locally.
make storybook

Terminal 2
Start the UI locally.
make client_run

Terminal 3
Start the Go server locally.
make server_run

Additional steps
As a services counselor, try editing an NTS shipment (or NTS-R) and change something like the counselor remarks.  Hit save and verify that the shipment remains the same type it was previously.
Also, you can add NTS TAC/SAC values to the associated order and verify that they show up in the edit interface.
Verification Steps for Author
These are to be checked by the author.

[ ] Tested in the Experimental environment (for changes to containers, app startup, or connection to data stores)
[ ] Request review from a member of a different team.
[ ] Have the Jira acceptance criteria been met for this change?

Verification Steps for Reviewers
These are to be checked by a reviewer.

Frontend

[ ] User facing changes have been reviewed by design.
[ ] There are no aXe warnings for UI.
[ ] This works in Supported Browsers and their phone views (Chrome, Firefox, IE, Edge).
[ ] There are no new console errors in the browser devtools
[ ] There are no new console errors in the test output

Warnings

:warning:
This PR does not include changes to unit tests, even though it affects app code.

Messages

:book:
:link: MB-11012

  Generated by :no_entry_sign: dangerJS against aea9c431eafe9cc2bc9c8d4023bc31b6c8eca337

authors: reggieriser robot-mymove


text:
[MB-14464] Updated milmove-cypress hash to latest one, now with Cypress 8.5.0

Jira ticket for this change
Summary
First, reference this circleci-docker PR.  This MilMove PR is just trying to get MilMove on the latest image with a downgraded Cypress (8.5.0).  We're currently on the same version, but we're having to use a circleci-docker hash from back in April because cypress was updated after that to 9.x and 10.x in circleci-docker independently of MilMove.  As a result, updating other dependencies becomes more difficult.  So this just tries to get everything on the latest main branches back in sync.
Setup to Run Your Code

💻 You will need to use three separate terminals to test this locally.
Terminal 1
Start the Storybook locally.
make storybook

Terminal 2
Start the UI locally.
make client_run

Terminal 3
Start the Go server locally.
make server_run

Additional steps
Just make sure all E2E tests pass.
Verification Steps for Author
These are to be checked by the author.

[ ] Tested in the Experimental environment (for changes to containers, app startup, or connection to data stores)
[ ] Request review from a member of a different team.
[ ] Have the Jira acceptance criteria been met for this change?

Messages

:book:
:link: MB-14464

  Generated by :no_entry_sign: dangerJS against ffdd48b6377fec23f2641a781a88ee0bcf573cd9


text:
Modernization

The original project is great!
It relies on a lot of outdated dependencies, though. I've gone through the codebase and bumped dependencies, gotten rid of old code, and implemented a unified way to set the icons on the right bar and the bottom bar.
The key dependency react-notion-x is not altered here. I'm also working on that, but have hit some sort of a roadblock with some dependency.

Thanks @gauravmm for this! While we are waiting for @transitive-bullshit to decide how to continue with this starter I created my own fork with updated react-notion-x dependency.
See more here:
https://github.com/onnimonni/nextjs-notion-starter-kit/pull/2
You can see the forked react-notion-x here: https://github.com/onnimonni/react-notion-x/tree/publish-forked-versions
It works perfectly but few tests are still failing which are written with ts and try to import the internal packages eg `import "notion-utils"' are not working and fail with:
Uncaught exception in src/notion-api-universal.test.ts

  Error [ERR_MODULE_NOT_FOUND]: Cannot find package '@onnimonni/notion-utils' imported from /Users/onnimonni/Projects/react-notion-x/packages/notion-client/src/notion-api.ts

I'm happy to add you as contributor to both of these forks if you want to help out 👍.

Fixed in https://github.com/transitive-bullshit/nextjs-notion-starter-kit/pull/641

authors: gauravmm onnimonni transitive-bullshit


text:
Services support

Hello, I would like to inquire if the Transient Robotics platform supports sending and receiving ROS services. Currently, I am developing a web interface that requires some services to control certain actions on the robot, and I would like to evaluate your solution for a series of additional features that you offer. I have read that managing services may be a limitation of the MQTT communication protocol. I'm not sure if this is the right place to ask this question; if it isn't, I can move it to where it's more appropriate. Thank you very much.

We don't currently have an existing capability to do this, but it has been requested by others, too, so we'll probably create one soon. Since you are asking this question here, on the github repo of the open-source Transitive framework, I'll also point out that you could write that capability yourself, if that's what you want. To get started with that, you'd follow these steps and then look at the starter code that is generated from it: https://transitiverobotics.com/docs/develop/creating_capabilities
To implement the service calls, I would use mqttSync.mqtt directly, i.e., not use mqttSync (which is for synchronizing stateful data), but the mqtt client itself. You can follow this example from the robot-agent itself, used to trigger agent actions, in this case restarting the agent, from the web:
https://github.com/transitiverobotics/transitive/blob/bf7aadaef4c6508b5195ee9f33079ac4e18370f6/cloud/app/web_components/robot-agent-device.jsx#L294-L298
MQTT does not have any built-in support for RPCs, so you'll need to think about the return value yourself. In the agent we do this by writing it into the synchronized data, where the web client will receive it, e.g., for receiving the package log upon request. This pattern is not ideal though and still needs some improvement.
But again, if this is more involved than you'd like, then you can also wait until we create a capability for it that you could then just install on your robots.

Thanks for your kind reply. I took a look at the solution proposed by you by searching for additional material online like async-mqtt or mqtt-json-rpc but, given my limited knowledge of the mqtt protocol, i would most likely not be able to obtain a good result. Currently I will therefore remain on the websocket protocol but keeping an eye on the developments and implementations of your platform. Thanks so much again

Makes sense. Just to clarify though: MQTTSync is not async-mqtt. The former is a protocol we've developed an it's documented here and here.

authors: alexgiano chfritz

repo: transitiverobotics/transitive


text:
Support LAMP based monthly csvs

There's a new dataset for monthly dumps based on LAMP with slightly different formatting
Use that new file and handle its formatting

Already using this for data already in the production dashboard, going to merge to avoid someone parsing data with the old version

repo: transitmatters/mbta-performance


text:
Feature: Setting constant onset shift for one cachefile

Is your feature request related to a problem? Please describe.
Currently, it is possibly to shift the onset of MEPs in the GUI. However, for one cachefile it requires one to manually shift the onset for every single MEP.
Describe the solution you'd like
It would be great to have the possibility to set an onset shift and have it constant for the whole data of one Cachefile.

I believe using the python API is the best approach for such batch-manipulation. I wrote a couple of examples and added them to the documentation. The one for your use-case is at https://offline-inspect.readthedocs.io/en/latest/cachefile.html#batch-manipulate and repeated here for ease of use:
from offspect.api import CacheFile, decode, encode
cf = CacheFile("merged.hdf5")
for ix, (data, attrs) in enumerate(cf):
    key = "onset_shift"
    old = decode(attrs[key])
    print(f"Trace {ix} {key}:", old, end=" ")
    new = old + 5
    attrs["onset_shift"] = encode(new)
    cf.set_trace_attrs(ix, attrs)
    test = decode(cf.get_trace_attrs(ix)["onset_shift"])
    print("to", test)

In this example, we shift all onsets by 5 samples to the right.

Closing this, as we agreed a API approach is  most suitable. Find updated documentations with examples for batch manipulation https://offline-inspect.readthedocs.io/en/latest/cachefile.html

authors: BettinaTrunk agricolab

repo: translationalneurosurgery/tool-offspect


text:
🛑 TechinAsia_Laravel_API is down

In 833fcd5, TechinAsia_Laravel_API (https://www.techinasia.com/api/2.0/companies) was down:

HTTP code: 403
Response time: 172 ms

Resolved: TechinAsia_Laravel_API is back up in 93232f9 after 7 minutes.

repo: traqy/upptime


text:
🛑 TechinAsia_WordPress_API is down

In 3514459, TechinAsia_WordPress_API (https://www.techinasia.com/wp-json/techinasia/2.0/posts) was down:

HTTP code: 403
Response time: 226 ms

Resolved: TechinAsia_WordPress_API is back up in 2b7888e after 7 minutes.


text:
🛑 TechinAsia is down

In eebba53, TechinAsia (https://www.techinasia.com) was down:

HTTP code: 403
Response time: 959 ms

Resolved: TechinAsia is back up in 078d2ea after 9 minutes.


text:
🛑 TechinAsia_Laravel_API is down

In 1aa71df, TechinAsia_Laravel_API (https://www.techinasia.com/api/2.0/companies) was down:

HTTP code: 403
Response time: 228 ms

Resolved: TechinAsia_Laravel_API is back up in bf63915 after 7 minutes.


text:
🛑 TechinAsia_Laravel_API is down

In c9f95b1, TechinAsia_Laravel_API (https://www.techinasia.com/api/2.0/companies) was down:

HTTP code: 403
Response time: 225 ms

Resolved: TechinAsia_Laravel_API is back up in 08f5cd2 after 7 minutes.


text:
🛑 TechinAsia_Laravel_API is down

In c5ea9d6, TechinAsia_Laravel_API (https://www.techinasia.com/api/2.0/companies) was down:

HTTP code: 403
Response time: 230 ms

Resolved: TechinAsia_Laravel_API is back up in 11b702b after 14 minutes.


text:
🛑 TechinAsia_Laravel_API is down

In 6cfb34a, TechinAsia_Laravel_API (https://www.techinasia.com/api/2.0/companies) was down:

HTTP code: 403
Response time: 227 ms

Resolved: TechinAsia_Laravel_API is back up in 07f7c1a after 7 minutes.


text:
🛑 TechinAsia_WordPress_API is down

In dc58ede, TechinAsia_WordPress_API (https://www.techinasia.com/wp-json/techinasia/2.0/posts) was down:

HTTP code: 403
Response time: 231 ms

Resolved: TechinAsia_WordPress_API is back up in bc82ed7 after 37 minutes.


text:
🛑 TechinAsia is down

In ff66d5d, TechinAsia (https://www.techinasia.com) was down:

HTTP code: 403
Response time: 947 ms

Resolved: TechinAsia is back up in a00258e after 7 minutes.


text:
Code Coverage Plugin

@travisjeffery I would like to enable https://codecov.io/ on the repo. I don't think I can perform all the required steps to set it up but I can assist and add the required test setup. What do you think?

Good idea, I've set it up. Let's get the coverage up before we add the badge to the README though :D

@travisjeffery I messaged on gitter before looking at these issues - i will try and help with coverage too :)

authors: jacktuck ryanstinson travisjeffery

repo: travisjeffery/jocko

license: mit


text:
x and y-units in mosaic and terrain example

In this example https://pdemtools.readthedocs.io/en/latest/examples/mosaic_and_terrain.html there are some very nice figures.
However, the x- and y- units are unknown. Would it be possible to show these as latitude/longitudes or something the reader can understand?

Thanks Adam. The merging process I use to combined the mosaics from different tiles loses the CF-compliant coordinate attributes that the PDT data normally comes with. New addition of code below enforces the CF-compliant attributes and makes the mosaic data match the rest of the data. This is also reflected in the notebooks.
    dem['x'].attrs['axis'] = 'X'
    dem['x'].attrs['long_name'] = 'x coordinate of projection'
    dem['x'].attrs['standard_name'] = 'projection_x_coordinate'
    dem['x'].attrs['units'] = 'metre'

    dem['y'].attrs['axis'] = 'Y'
    dem['y'].attrs['long_name'] = 'y coordinate of projection'
    dem['y'].attrs['standard_name'] = 'projection_y_coordinate'
    dem['y'].attrs['units'] = 'metre'

authors: AdamRJensen trchudley

repo: trchudley/pdemtools


text:
Redundant parentheses cause memory corruption

Following code cause memory corruption:
main :- (foo, (bar(baz))), halt.

Yep,
main :- (bar(baz)), halt.
is enough.

Not sure if related, following code does not parse correctly:
main :- write(a), nl, (write(b), nl), halt.

Listing:
Trealla v0.1alpha, 64-bits (int=128-bits), Dec 16 2016
main :-
        write(a),
        nl(write(b),nl),
        halt.

According to valgrind's result, those lines trealla.c#L2058-L2063 are suspicious.
After I commented them out, memory corruption disappeared.

Yes, very suspect. Can't imagine what it is supposed to be doing.

Perhaps it was supposed to be NLIST_POP_FRONT, not NLIST_FRONT.

Anyway, it still doesn't parse correctly.

Now your test case will cause an infinite loop:
main :- (bar(baz)), halt.

Now for this:
main :- write(a), nl, (write(b), nl), halt.
Seems ok now?

Cool! Fix confirmed in devel branch. I'll close this issue.

authors: dram infradig

repo: trealla-lang/trealla


text:
Unification segv

?- A=[A|A],B=[A|B],A=[A|B], false.
Segmentation fault (core dumped)

(This one blocks a lot)

I can only repeat that this blocks a lot, I just reencountered exactly this error.

repo: trealla-prolog/trealla


text:
Add "lakectl fs upload --recursive" flag

Behaves a lot like s3 cp --recursive: uploads files using their path relative from the local directory.
Example
Suppose you have these files:
/tmp/a/foo
/tmp/a/b/bar
/tmp/a/b/c/d/e/xyzzy

Then lakectl upload --recursive --source /tmp/a/ lakefs://repo@master/top/ will create these objects:
lakefs://repo@master/top/foo
lakefs://repo@master/top/b/bar
lakefs://repo@master/top/b/c/d/e/xyzzy

Alternative solution for https://lakefs.slack.com/archives/C016726JLJW/p1606735311131500.

Alternative to #977, probably don't want both...

Thanks!  Pulling this one, throwing #977 away.

repo: treeverse/lakeFS


text:
CancellationException thrown + unhandled after Single subscription disposed (RxJava 2)

I'm not quite sure how to handle this issue.
I have a subscription to a Single that is bound to the lifecycle of a fragment, which I may at some point have to cancel/dispose. Once this has happened, if the fragment is closed the exception is thrown to the system and the app crashes. See below for the stack trace
java.util.concurrent.CancellationException
     at io.reactivex.internal.operators.single.SingleTakeUntil$TakeUntilOtherSubscriber.onNext(SingleTakeUntil.java:150)
     at io.reactivex.internal.subscriptions.DeferredScalarSubscription.complete(DeferredScalarSubscription.java:133)
     at io.reactivex.internal.operators.single.SingleToFlowable$SingleToFlowableObserver.onSuccess(SingleToFlowable.java:63)
     at io.reactivex.internal.operators.observable.ObservableElementAtSingle$ElementAtObserver.onNext(ObservableElementAtSingle.java:91)
     at io.reactivex.internal.operators.observable.ObservableFilter$FilterObserver.onNext(ObservableFilter.java:52)
     at io.reactivex.internal.operators.observable.ObservableOnErrorReturn$OnErrorReturnObserver.onNext(ObservableOnErrorReturn.java:66)
     at io.reactivex.internal.operators.observable.ObservableCombineLatest$LatestCoordinator.drain(ObservableCombineLatest.java:246)
     at io.reactivex.internal.operators.observable.ObservableCombineLatest$LatestCoordinator.combine(ObservableCombineLatest.java:199)
     at io.reactivex.internal.operators.observable.ObservableCombineLatest$CombinerObserver.onNext(ObservableCombineLatest.java:316)
     at io.reactivex.internal.operators.observable.ObservableSkip$SkipObserver.onNext(ObservableSkip.java:53)
     at io.reactivex.internal.operators.observable.ObservableRefCount$ConnectionObserver.onNext(ObservableRefCount.java:169)
     at io.reactivex.internal.operators.observable.ObservablePublish$PublishObserver.onNext(ObservablePublish.java:233)
     at io.reactivex.internal.util.NotificationLite.accept(NotificationLite.java:246)
     at io.reactivex.subjects.BehaviorSubject$BehaviorDisposable.test(BehaviorSubject.java:490)
     at io.reactivex.subjects.BehaviorSubject$BehaviorDisposable.emitNext(BehaviorSubject.java:485)
     at io.reactivex.subjects.BehaviorSubject.onNext(BehaviorSubject.java:184)
     at com.trello.rxlifecycle2.components.support.RxFragment.onPause(RxFragment.java:88)
     at android.support.v4.app.Fragment.performPause(Fragment.java:2371)
     at android.support.v4.app.FragmentManagerImpl.moveToState(FragmentManager.java:1357)
     at android.support.v4.app.FragmentManagerImpl.moveFragmentToExpectedState(FragmentManager.java:1528)
     at android.support.v4.app.FragmentManagerImpl.moveToState(FragmentManager.java:1595)
     at android.support.v4.app.FragmentManagerImpl.dispatchPause(FragmentManager.java:2920)
     at android.support.v4.app.FragmentController.dispatchPause(FragmentController.java:234)
     at android.support.v4.app.FragmentActivity.onPause(FragmentActivity.java:448)
     at com.trello.rxlifecycle2.components.support.RxAppCompatActivity.onPause(RxAppCompatActivity.java:81)
     at android.app.Activity.performPause(Activity.java:6819)
     at android.app.Instrumentation.callActivityOnPause(Instrumentation.java:1322)
     at android.app.ActivityThread.performPauseActivityIfNeeded(ActivityThread.java:3740)
     at android.app.ActivityThread.performPauseActivity(ActivityThread.java:3717)
     at android.app.ActivityThread.performPauseActivity(ActivityThread.java:3691)
     at android.app.ActivityThread.handlePauseActivity(ActivityThread.java:3665)
     at android.app.ActivityThread.-wrap16(ActivityThread.java)
     at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1489)
     at android.os.Handler.dispatchMessage(Handler.java:102)
     at android.os.Looper.loop(Looper.java:154)
     at android.app.ActivityThread.main(ActivityThread.java:6119)
     at java.lang.reflect.Method.invoke(Native Method)
     at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:886)
     at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:776)

The issue can be seen in SingleTakeUntil.TakeUntilMainObserver.otherError which will throw an exception to the default UncaughtExceptionHandler if the Disposable(subscription) is disposed
How do I deal with this?

Single emits CancellationException when it disposes: https://github.com/trello/RxLifecycle#unsubscription
Due to the way RxLifecycle is setup, there isn't a great way around it. I suggest checking out AutoDispose if you want to automatically dispose of Singles without getting an exception.

Seems like it should come with a clearer warning in the documentation.
In any case, an easy workaround seems to be to convert your Single to an Observable

authors: dlew kassim

repo: trello/RxLifecycle


text:
Search bar

I think it would be useful to have a search bar component to filter rows of a table/list or other data. I've seen your examples of using a MultiSelectbox box for filtering, but I think the search functionality would be helpful too.

Hey @alexheiner, thanks for the comment! Did you have the chance to check out the SelectBox component already, which essentially provides a search-box to filter among the available options? Or are you looking for something different? Feel free to elaborate 🙂

I actually didn't notice the ability to search in the SelectBox, thanks for pointing that out. Sorry I don't know how I missed that. I was originally thinking of a more general purpose table/data search, such as searching for a specific address, phone number, etc in a table. But I thInk the SelectBox could probably be used to do something similar.

@alexheiner Let us know if a simple search bar (including further features, such as auto complete) still would be more appealing to your use cases! :)

Sounds good! I do think it could be a useful feature, but it could be something that is added down the line in a future release. Thanks for getting back to me about it! I think this is a really cool project, I'm excited to keep using it!

SearchBox does no appear to be documented in the list of components here through. https://www.tremor.so/docs/components

authors: alexheiner christopherkindl mitrotasios tonyxiao

repo: tremorlabs/tremor


text:
Can I use my own form?

like:
$.prompt({
    html: '<form action="/user/settings" method="post"......',
})

Impromptu wraps the all of the states into a single form, so doing so would create a form inside a form, which will cause issues.

authors: trentrichardson zackperdue

repo: trentrichardson/jQuery-Impromptu


text:
Query previous/next historical entry

One of the main use cases I've found with django-simple-history has been to get the previous historical entry to calculate deltas in values.
Issue #201 talks about the Django utility functions, which allows for getting the last value by a field. I think it would be great to add a previous property to the historical model that grabbed the get_previous_by_history_date that reflected the same tracked instance automatically. I feel like a next and previous method fits perfectly within the historical records context.
As a dependent though, comparing versions between points in time would be excellent, too, but I'll submit a second issue based on response to this.

What is the best way, given a historical entry, to get the "previous" entry?
In my use case, thing and thing.history.most_recent() have the same field values in all cases, except they don't compare identically because thing._state != thing.history.most_recent()._state, and id(thing) != id(thing.history.most_recent()).

:white_check_mark: https://github.com/treyhunner/django-simple-history/pull/365

authors: SpainTrain ransford willjschmitt

repo: treyhunner/django-simple-history


text:
fix: #526 CLI warn if using @trigger.dev/react package with Next.js pages directory

Closes #526
✅ Checklist

[x] I have followed every step in the contributing guide
[x] The PR title follows the convention.
[x] I ran and tested the code works

Screenshots

This is a bit stale now


text:
feat: Upgrade to material-components-web v1.1.0

WIP
closes #1842 #1845

Almost ready!

repo: trimox/angular-mdc-web


text:
sc-7976 GDS User UI : Remove blue border from css custom-styled button

Scope of changes
sc-7976 GDS User UI : Remove blue border from css custom-styled button
Type of change

[ ] bug fix
[ ] new feature
[ ] documentation
[ ] other (describe)

Acceptance criteria
Describe how reviewers can test this change to be sure that it works correctly. Add a checklist if possible
Author checklist

[x] I have manually tested the change and/or added automation in the form of unit tests or integration tests
[ ]  I have updated the dependencies list
[ ]  I have recompiled and included new protocol buffers to reflect changes I made
[ ]  I have added new test fixtures as needed to support added tests
[x]   Check this box if a reviewer can merge this pull request after approval (leave it unchecked if you want to do it yourself)
[x]  I have moved the associated Shortcut story to "Ready for Review"

Reviewer(s) checklist

[ ] Any new user-facing content that has been added for this PR has been QA'ed to ensure correct grammar, spelling, and understandability.

Codecov Report

Merging #699 (916900f) into main (c9e02fb) will decrease coverage by 5.80%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main     #699      +/-   ##
==========================================
- Coverage   43.89%   38.08%   -5.81%
==========================================
  Files         580      155     -425
  Lines       17363     2434   -14929
  Branches     1273      618     -655
==========================================
- Hits         7621      927    -6694
+ Misses       8557     1330    -7227
+ Partials     1185      177    -1008

Impacted Files
Coverage Δ

...eb/gds-user-ui/src/components/FileUpload/index.tsx

...i/src/components/NeedsAttention/AttentionAlert.tsx

web/gds-user-ui/src/theme/components/Button.ts

...github.com/trisacrypto/directory/pkg/gds/backup.go

...ficateManagement/CertificateManagement.stories.tsx

...isacrypto/directory/pkg/utils/logger/middleware.go

web/gds-user-ui/src/locales/fr/messages.js

web/gds-user-ui/src/components/NotFound/index.tsx

...om/trisacrypto/directory/pkg/gds/client/profile.go

...-user-ui/src/components/Navbar/Landing/NavItem.tsx

... and 415 more

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

repo: trisacrypto/directory


text:
Output showing in s (Seconds) instead of micro or milli seconds And Output not in readable format

Added an Image to show the output
In the first you can see it's showing "s" which is not correct
And in the second log it's not in a readable format

Request:-

Add a UTC timestamp as a configurable option maybe because we can stream these logs or access from Docker logs we would be able to confirm with a timestamp

Hi 👋 , it this is accepted I would like to work on this, could you assign it to me 🙂!

Okay, I will take a look at it. The timing got messed up in the last update from a bug I didn't catch.
I could include that. Maybe a few other logging options too like JSON for structured loggers?

@tristanisham
Logger does look good and this will help a lot in future.
You can provide more options, also you can maybe as well use local timestamp so that people developing in their own timezone will be able to relate by the time easier. You can enable this as an option.
What do you have in mind for Structured loggers?
Also are you working on adding testing?

@Yashrocky96 could you make a pull request for the errant seconds label?
As for logging, I'll add some options to enable logging in UTC and support for the TZ variable.

@tristanisham I have raised a PR, Please review and let me know

#5 is almost done. One more change and it's good to merge @Yashrocky96

@tristanisham I have updated the PR
Also, Please check this out if you can.
Story:- When there's an error during execution of onError for example during development you are giving a wrong JSON and you get an error that the input is Failed to parse JSON.
In this scenario, onError hook is executing twice and logging the information twice.
For now, I am fairly new with Elysia and do not understand why that is happening.

@tristanisham Please close this issue and would I not join as a Contributor here?

@tristanisham

Hi,
I am on vacation and will review these changes when I return in
November.
Tristan Isham
On October 23, 2023, Tristan Isham @.***> wrote:

@tristanisham https://github.com/tristanisham

—
Reply to this email directly, view it on GitHub
<https://github.com/tristanisham/logysia/issues/4#issuecomment-
1774702710>, or unsubscribe
<https://github.com/notifications/unsubscribe-
auth/AFQNWUQIXLSLPUOWAMZVWC3YAYUTJAVCNFSM6AAAAAA5VUOQ4GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONZUG4YDENZRGA>.
You are receiving this because you were mentioned.Message ID:
@.***>

Hi Tristanisham,
Hope that you are back from your vacations, Would you please add me as a contributor and do a patch release please?

Just send them here? Is there a pull request?

Could you please send them here?
What do I send and how do I send, This is my first Open-Source Contribution @tristanisham . Please guide me. And thanks.

You have already merged my changes from my forked repository

Hi @tristanisham Please do a patch release and add me as a contributor to the package, if my application does use this package.

@tristanisham Please do a patch release

authors: Yashrocky96 kareemmahlees tristanisham

repo: tristanisham/logysia


text:
Do not call yarn directly in the package.json pre commands

Your Environment

Prettier version: 2.8.3
node version [12.x.x, 14.x.x]: 18.13
package manager: pnpm@7.26.3
IDE: VSCode

Describe the bug
When installed via pnpm install, pnpm expresses that the command fails due to yarn missing.

Install a fresh nvm version (like 18.13) and run npm install -g pnpm. Then create a new project add @trivago/prettier-plugin-sort-imports as a dep. Run install and see the error.
Expected behavior
Should work without the need to have a global yarn package manager.

Any ideas?

hello?

Please use require while loading the plugin if you use it pnpm. Something like this https://github.com/verdaccio/verdaccio/blob/c9bd22dcaa2f0d919338fb387ae261992f0e1116/prettier.config.js#L10

Feel free to reopen if you still face the issue.

authors: ayusharma matsko

repo: trivago/prettier-plugin-sort-imports


text:
Rename basis part of DG to operator or something similar?

This came up in https://github.com/trixi-framework/Trixi.jl/pull/617#discussion_r644467670. The name basis might not fit very well for FD-SBP methods...

@andrewwinters5000 suggested "spectral approximation", but that doesn't really fit for FD methods, I think. The "approximation" part is probably okay, though - "approximation space"? But that's also quite long compared to "basis"...

I like the approximation-related name. One could also use a name related to the reference element/domain since all quantities are defined there?

One could also use a name related to the reference element/domain since all quantities are defined there?

Like what?

I was thinking ReferenceElementData/ReferenceDomainData after deal.ii's FiniteElementData and GridAP's ReferenceFE, but those names are pretty long.

Hm. So it would be something like LobattoLegendreReferenceElementData? That is quite long...

Yeah, that's definitely too long. Maybe ReferenceElementData would be better as an abstract type, something like
LobattoLegendreElement <: AbstractReferenceElementData{RealT}.

Triage: Not necessary

authors: jlchan ranocha sloede


text:
Brew Tap is broken

~ brew install trntv/sshed/sshed                                                                                1 [15:45:25]
==> Tapping trntv/sshed
Cloning into '/usr/local/Homebrew/Library/Taps/trntv/homebrew-sshed'...
remote: Enumerating objects: 6, done.
remote: Counting objects: 100% (6/6), done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 6 (delta 2), reused 0 (delta 0), pack-reused 0
Receiving objects: 100% (6/6), done.
Resolving deltas: 100% (2/2), done.
Error: Invalid formula: /usr/local/Homebrew/Library/Taps/trntv/homebrew-sshed/sshed.rb
sshed: Calling bottle :unneeded is disabled! There is no replacement.
Please report this issue to the trntv/sshed tap (not Homebrew/brew or Homebrew/core):
/usr/local/Homebrew/Library/Taps/trntv/homebrew-sshed/sshed.rb:9
Error: Cannot tap trntv/sshed: invalid syntax in tap!

Same for me with M1 Mac Pro

Same here

authors: basarozcan gabrielbryk rinchen

repo: trntv/sshed


text:
🛑 PiHole is down

In e4592e5, PiHole (https://pihole.tronflix.app/admin/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: PiHole is back up in d0b14bc.

repo: tronyx/upptime


text:
🛑 Radarr Anime is down

In 2bf7d09, Radarr Anime (https://tronflix.app/radarr-anime/activity/queue/) was down:

HTTP code: 520
Response time: 103 ms

Resolved: Radarr Anime is back up in 150bc0e.


text:
🛑 Sonarr is down

In fa8805e, Sonarr (https://tronflix.app/sonarr/activity/queue/) was down:

HTTP code: 521
Response time: 38 ms

Resolved: Sonarr is back up in cdfc73d.


text:
🛑 Overseerr is down

In 0210f49, Overseerr (https://overseerr.tronflix.app/login) was down:

HTTP code: 523
Response time: 19906 ms

Resolved: Overseerr is back up in 1cafcc4 after 1 hour, 29 minutes.


text:
🛑 Grafana is down

In be12d86, Grafana (https://grafana.tronflix.app) was down:

HTTP code: 521
Response time: 99 ms

Resolved: Grafana is back up in 8b12c10 after 3 hours, 20 minutes.


text:
multiple instances of gridster

Hi Troolee,
I am trying to create 2 separate  instances of gridster on one page how ever i have found some difficulties as they are using the same naming conventions. I have tried to initialize gridster with options  (item_class ,placeholder_class) how ever I couldnt see any differences. Could you advise pls if gridster support multiple instances on one project and if yes ;) how correctly initialize each instance. I am trying :
for second instance I am trying :

    var options = {
        cell_height: 10,
        vertical_margin: 10,
		item_class: "my_iteam_class",
		placeholder_class: "my_placeholder_class"
};
$('.grid-stack.test').gridstack(options);

Thanks for advance...

I'm also having problems with this.
@kozilla did you managed to put this to work?
@troolee Any suggestion?

Please check 2 grids demo http://troolee.github.io/gridstack.js/demo/two.html

authors: jpsfs kozilla troolee


text:
nerfing pin/multi-pin

Per issue #67 Attempt to balance marksman pin/multi-pin abilities.
Nerfed the bonus accuracy. Redesigned other things.
I tried to reword some text to remove vagueness.

What do you think of the following changes:
"If the target is fired at by you" -> "If you hit the selected target"
The effect should only trigger when a target is hit.
"The Pin/Multi-Pin ability can be activated by a pinned target up to 3 times per Marksman player's turn cycle" -> "This ability allows a marksman to react to a pinned target once per turn."
This version of the feat only allows one target to be pinned, so it doesn't makes sense that the only pinned target would trigger the marksman's reaction shot more than once per turn.
Also, "Only 1 target may be pinned by the marksman at a time." should be added to the first iteration of this feat.
"You may select and pin up to PER/2 (round down) targets at a time (you have to fire at a target to pin it).+30% to hit a Pinned target (instead of +10%). Only usable with long-rifles. " -> "You may monitor and react to up to PER/2 (round down) pinned targets at a time. +20% to hit a pinned target. Only usable with Long Rifles."
Cleared up some phrasing. A target is only pinned when hit, that is defined in the first section of the feat so we don't have to mention that again. The original +20% replaces any other bonus, this is the intended behavior of all class feats. if class X has a level 5 feat that says "+15% to do Y", and the level 10 variant says "+30% to do Y" that means the total bonus to performing Y is 30%. This phrasing is fairly ambiguous and I apologize for that. Maybe we should change all second-tier class feats so that bonuses are written as "The bonus for doing Y increases to +30%". That is fairly explicit.
Are we also adding in that this ability takes actions off of the marksman's turn, or leaving it as-is? I'm fine with either decision, I thought'd I'd bring it up since we'd discussed it in the past.

What do you think of the following changes:
"If the target is fired at by you" -> "If you hit the selected target"
The effect should only trigger when a target is hit.

Why should the effect only trigger when a target is hit?
My reasoning was that I didn't want to straight nerf marksman, so it gives them an advantage this way while other ways get nerfed. Also realism, 'pinning' sounds analogous to  'suppressing' a target, and that is more about psychological warfare than physical damage. Also, it would even make sense if you just aimed at him, for him to be pinned, since him coming out of cover would be stupid. I suppose you may be considering the first shot to be a maiming shot? Also, most long rifles are bolt action, making it much harder to pin targets if it's an on-hit effect (especially in regards to multi-pin).

"The Pin/Multi-Pin ability can be activated by a pinned target up to 3 times per Marksman player's turn cycle" -> "This ability allows a marksman to react to a pinned target once per turn."
This version of the feat only allows one target to be pinned, so it doesn't makes sense that the only pinned target would trigger the marksman's reaction shot more than once per turn.

Why doesn't it make sense? In my mind, the target could be darting from cover to cover on their turn. If I was trying to kill someone, I would be shooting every chance I get.

Also, "Only 1 target may be pinned by the marksman at a time." should be added to the first iteration of this feat.

"If the target dies you may select a new target." already says that, but we can make it more explicit if you prefer.

"You may select and pin up to PER/2 (round down) targets at a time (you have to fire at a target to pin it).+30% to hit a Pinned target (instead of +10%). Only usable with long-rifles. " -> "You may monitor and react to up to PER/2 (round down) pinned targets at a time. +20% to hit a pinned target. Only usable with Long Rifles."
Cleared up some phrasing. A target is only pinned when hit, that is defined in the first section of the feat so we don't have to mention that again. The original +20% replaces any other bonus, this is the intended behavior of all class feats. if class X has a level 5 feat that says "+15% to do Y", and the level 10 variant says "+30% to do Y" that means the total bonus to performing Y is 30%. This phrasing is fairly ambiguous and I apologize for that. Maybe we should change all second-tier class feats so that bonuses are written as "The bonus for doing Y increases to +30%". That is fairly explicit.

Ok.

Are we also adding in that this ability takes actions off of the marksman's turn, or leaving it as-is? I'm fine with either decision, I thought'd I'd bring it up since we'd discussed it in the past.

I put the following in, "The Pin/Multi-Pin ability can be activated by a pinned target up to 3 times per Marksman player's turn cycle" for that reason. I figured that it would be ok to grant the marksman the ability to react without extra expense.

I think this is good discussion!

I felt pinned by Alex's nerf monstrosity at nerf wars in past even when not hit by his shots.
If the trigger is the target leaving cover, how would it be possible for the marksman's ability to trigger more than once per turn per target? That also doesn't make sense to me.
We should make that much more explicit. Players sometimes create loopholes when they don't quite understand what's written. We should avoid attempting to communicate with nuance.
Whichever way we communicate it, we need to make it very clear.
I still don't understand how a target could proc 3 sniper reaction shots in a single turn.

@bleehu,
2. If a target re-enters cover and leaves it again.
Example:, I am pinned and hiding behind light cover in a hallway, I run ahead to then next cover in the hallway, proc'ing marksman Pin. Then I leave from that cover, to a third cover. Proc'ing marksman pin a 2nd time.
5. I tried to make it about multi-pin as well as 'single'-pin in one swoop. The way I meant it to be written is that the Marksman player cannot shoot more than 3 reaction shots per his full turn cycle, no matter how many people he is pinning.

That makes a little more sense. =)

@trowl223, fyi I won't do (don't want to do) any more work on this until you respond to the recent post(s) =)
(I have plenty of other things to do, so take your time)

So sorry! working on this now.

Makes sense.
I don't think so. The marksman is attuned to only the precise locations of the target he has pinned. if one leaves cover and is not hit by the reaction shot, the marksman has lost track of them temporarily and must readjust. The time frames seem to be in favor of the marksman too much. three shots in the span of their enemy's turn while they've already had a full turn is like granting them extra actions.
The situation will not always be that someone is moving in a straight line down a hallway towards you as in your given example. In that instance, it may be up to the DM to allow that if the Marksman has a semi-auto rifle since they don't have to readjust, but in a different example this may not be the case. What if the Marksman was providing cover to their squad from a bell-tower positioned 200 meters from combat, and they have to watch a 300m spread of land in front of them? A pinned target moving side-to-side form the Marksman's POV would require considerable time for the marksman to readjust if they miss the first shot as the target leaves cover.
My thoughts exactly. An ability of this caliber needs to be pretty explicit.
I still don't think that they should receive an extended amount of extra firing time. At the second tier, I think that with multiple targets the Marksman can have multiple reaction shots (as per my original edit) but at the first tier we're talking about a potential Level 5 ability, its too much out of turn action IMO.

@trowl223, sounds good.
Please review my latest commit


text:
NAS-123236 / 23.10 / Allow waiting for jobs to complete

Context
A new parameter has been added to MiddlewareCommand to allow waiting for a job to complete so we get the job's endpoints output and not the job number.

Jira URL: https://ixsystems.atlassian.net/browse/NAS-123236

repo: truenas/ixdiagnose


text:
broomwood, folks

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 100
sleep for: 300s
close stale after: 4 hours
[pullrequest]
requests per hour: 0
deps=[b,f]

/trunk merge

repo: trunk-io/mergequeue-staging


text:
favillous, gigantostracous

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 100
sleep for: 300s
close stale after: 4 hours
[pullrequest]
requests per hour: 0
deps=[f,g]

/trunk merge


text:
fostered, crosses

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 100
sleep for: 300s
close stale after: 4 hours
[pullrequest]
requests per hour: 0
deps=[c,f]

/trunk merge


text:
drilling, enters

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 100
sleep for: 300s
close stale after: 4 hours
[pullrequest]
requests per hour: 0
deps=[d,e]

/trunk merge


text:
aerometry, dominion

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 100
sleep for: 300s
close stale after: 4 hours
[pullrequest]
requests per hour: 0
deps=[a,d]

/trunk merge


text:
goats, exactingness

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 100
sleep for: 300s
close stale after: 4 hours
[pullrequest]
requests per hour: 0
deps=[e,g]

/trunk merge


text:
galvanoplastical, descanting

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 100
sleep for: 300s
close stale after: 4 hours
[pullrequest]
requests per hour: 0
deps=[d,g]

/trunk merge


text:
culturization

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 100
sleep for: 300s
close stale after: 4 hours
[pullrequest]
requests per hour: 0
deps=[c]

/trunk merge


text:
antimedication, detrect

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 100
sleep for: 300s
close stale after: 4 hours
[pullrequest]
requests per hour: 0
deps=[a,d]

/trunk merge


text:
fiscalization, accounters

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 100
sleep for: 300s
close stale after: 4 hours
[pullrequest]
requests per hour: 0
deps=[a,f]

/trunk merge


text:
dovecot, fuddledness

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 100
sleep for: 300s
close stale after: 4 hours
[pullrequest]
requests per hour: 0
deps=[d,f]

/trunk merge


text:
atypicality, bractlets

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 100
sleep for: 300s
close stale after: 4 hours
[pullrequest]
requests per hour: 0
deps=[a,b]

/trunk merge


text:
fireplough

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 100
sleep for: 300s
close stale after: 4 hours
[pullrequest]
requests per hour: 0
deps=[f]

/trunk merge


text:
emesidae, chromatophoric

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 100
sleep for: 300s
close stale after: 4 hours
[pullrequest]
requests per hour: 0
deps=[c,e]

/trunk merge


text:
criminals, excorticating

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 100
sleep for: 300s
close stale after: 4 hours
[pullrequest]
requests per hour: 0
deps=[c,e]

/trunk merge


text:
gendarmes, conceivability

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 100
sleep for: 300s
close stale after: 4 hours
[pullrequest]
requests per hour: 0
deps=[c,g]

/trunk merge


text:
genteelest, epencephalic

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 100
sleep for: 300s
close stale after: 4 hours
[pullrequest]
requests per hour: 0
deps=[e,g]

/trunk merge


text:
equimultiple, frequence

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 100
sleep for: 300s
close stale after: 4 hours
[pullrequest]
requests per hour: 0
deps=[e,f]

/trunk merge


text:
aasvogel, disarray (logical-conflict)

This pull request was generated by the 'mq' tool

/trunk merge


text:
gurdy, blinking

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 1000
sleep for: 600s
close stale after: 24 hours
[pullrequest]
requests per hour: 20
deps=[b,g]

/trunk merge

repo: trunk-io/mergequeue


text:
bilimbi

This pull request was generated by the 'mq' tool

/trunk merge


text:
foism, debussed

This pull request was generated by the 'mq' tool

/trunk merge


text:
emydian, diddering

This pull request was generated by the 'mq' tool

/trunk merge


text:
feater, desipience

This pull request was generated by the 'mq' tool

/trunk merge


text:
cycloheptanone, goldeneye

This pull request was generated by the 'mq' tool

/trunk merge


text:
desipiency, esparcet

This pull request was generated by the 'mq' tool

/trunk merge


text:
effervescence, garbure

This pull request was generated by the 'mq' tool

/trunk merge


text:
cosignificative, bowlers

This pull request was generated by the 'mq' tool

/trunk merge


text:
farsakh

This pull request was generated by the 'mq' tool

/trunk merge


text:
grandmother, antifermentative

This pull request was generated by the 'mq' tool

/trunk merge


text:
fadridden, absorbition

This pull request was generated by the 'mq' tool

/trunk merge


text:
conventionality, excoecaria

This pull request was generated by the 'mq' tool

/trunk merge


text:
frangula, bureaucratical

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 1000
sleep for: 2100s
close stale after: 24 hours
[pullrequest]
requests per hour: 100
deps=[b,f]

/trunk merge


text:
appaloosa, flavobacterium

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 1000
sleep for: 2100s
close stale after: 24 hours
[pullrequest]
requests per hour: 100
deps=[a,f]

/trunk merge


text:
charcoalist

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 1000
sleep for: 2100s
close stale after: 24 hours
[pullrequest]
requests per hour: 100
deps=[c]

/trunk merge


text:
chaton, agruif

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 1000
sleep for: 2100s
close stale after: 24 hours
[pullrequest]
requests per hour: 100
deps=[a,c]

/trunk merge


text:
footnoted, anerethisia

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 1000
sleep for: 2100s
close stale after: 24 hours
[pullrequest]
requests per hour: 100
deps=[a,f]

/trunk merge


text:
emprizes, glitch

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 1000
sleep for: 2100s
close stale after: 24 hours
[pullrequest]
requests per hour: 100
deps=[e,g]

/trunk merge


text:
gallivorous, consentaneously

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 1000
sleep for: 2100s
close stale after: 24 hours
[pullrequest]
requests per hour: 100
deps=[c,g]

/trunk merge


text:
dissyllabify, foredoes

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 1000
sleep for: 600s
close stale after: 24 hours
[pullrequest]
requests per hour: 20
deps=[d,f]

/trunk merge


text:
botong, apodous

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 1000
sleep for: 600s
close stale after: 24 hours
[pullrequest]
requests per hour: 20
deps=[a,b]

/trunk merge


text:
betattered

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 1000
sleep for: 600s
close stale after: 24 hours
[pullrequest]
requests per hour: 20
deps=[b]

/trunk merge


text:
excommunicable

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 1000
sleep for: 600s
close stale after: 24 hours
[pullrequest]
requests per hour: 20
deps=[e]

/trunk merge


text:
azotise, exploit

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 1000
sleep for: 600s
close stale after: 24 hours
[pullrequest]
requests per hour: 20
deps=[a,e]

/trunk merge


text:
belauds, dicyclopentadienyliron

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 1000
sleep for: 600s
close stale after: 24 hours
[pullrequest]
requests per hour: 20
deps=[b,d]

/trunk merge


text:
franklinite, clarigation

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 1000
sleep for: 600s
close stale after: 24 hours
[pullrequest]
requests per hour: 20
deps=[c,f]

/trunk merge


text:
arachnoidal, embolectomies

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 1000
sleep for: 600s
close stale after: 24 hours
[pullrequest]
requests per hour: 20
deps=[a,e]

/trunk merge


text:
blockheadedly, givenness

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 1000
sleep for: 600s
close stale after: 24 hours
[pullrequest]
requests per hour: 20
deps=[b,g]

/trunk merge


text:
ergastic, acrophonically

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 1000
sleep for: 600s
close stale after: 24 hours
[pullrequest]
requests per hour: 20
deps=[a,e]

/trunk merge


text:
aurivorous, calombigas

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 1000
sleep for: 600s
close stale after: 24 hours
[pullrequest]
requests per hour: 20
deps=[a,c]

/trunk merge


text:
biacuminate, erythroblastosis

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 1000
sleep for: 600s
close stale after: 24 hours
[pullrequest]
requests per hour: 20
deps=[b,e]

/trunk merge


text:
admedial, enthronising

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 1000
sleep for: 600s
close stale after: 24 hours
[pullrequest]
requests per hour: 20
deps=[a,e]

/trunk merge


text:
fleysome, aversive

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 1000
sleep for: 600s
close stale after: 24 hours
[pullrequest]
requests per hour: 20
deps=[a,f]

/trunk merge


text:
distrail, flailed

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 1000
sleep for: 600s
close stale after: 24 hours
[pullrequest]
requests per hour: 20
deps=[d,f]

/trunk merge


text:
bolsheviks, glenoidal

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 1000
sleep for: 600s
close stale after: 24 hours
[pullrequest]
requests per hour: 20
deps=[b,g]

/trunk merge


text:
fuddles, ejectives

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 1000
sleep for: 600s
close stale after: 24 hours
[pullrequest]
requests per hour: 20
deps=[e,f]

/trunk merge


text:
Improve testing workflow

Changes targeted by this PR:

Avoid snapshot assertions failing when it's a new version that doesn't have a snapshot. This includes removing the requirement to specify output files, and now snapshots are always autogenerated. See comment in linterCheckTest() for specifics on this design. This decision was rooted in a couple factors, namely:

As identified in #65, the lack of a snapshot for a specific version was causing unnecessary failures.
Linters can still change their messages, outputs, etc (as sqlfluff did yesterday). This is something that we don't want to cause too much friction, but we still want to call it out as a noticeable change. If this happens during someone's workflow (should still be relatively infrequent), now simply run the specific command in tests/readme.md and validate expected output. We may want to highlight this specific command better or with more visibility.
The JSON assertions and snapshot code were a bit redundant and unnecessarily complex. This should simplify and be flexible enough for the near future. If we want any additional assertions, we can do so via the postCheck hook.

Make tests run in parallel. This also simplifies the setup for the config_check_test.ts. It's a tad redundant, but its presence makes triaging problems a bit easier.
Attempt to reduce flakiness (the parallelism appears to reduce flakiness to about 1-3%--it'd be nice to have analytics on this). I'll continue investigating alternatives for dealing with the daemon lifetime.

Average test time right now locally with these 4 tests is about 10 seconds in total :)
They're about a minute in total on CI because of the need to download and install linters.
Remaining todos (unordered):

Investigate daemon lifetime changes
Modify sandboxing to shadow tree from root
Use debugging library in testing
Add contributing.md
Add option for specifying a range of linter versions (ideally for nightlies)
Migrate rest of definitions

Addressing all comments in a follow-up to unblock folks with testing failures

repo: trunk-io/plugins


text:
fix data import paths in weav/instance.py

files currently in weav folder but need to figure out how to properly import using ././ etc while opening json and pandas read_csv

wrong repo

repo: trustgraph/trustgraph


text:
Status should probably be a single field rather than an array

This was an observation in #1006 that I think warrants its own issue...
The response from /api/v1/vulnerability/{id} contains a field advisories.sboms.status which is an array and not a single field. That technically means that an a Single advisory can say that an SBOM has the status affected and not_affected at the same time. E.g.
{
  "advisories": [
    {
      "identifier": "Advisory1",
      "sboms": [
        {
          "id": "Sbom1",
          "status": ["affected", "not_affected"]
          // other fields
        },
      ]
    }
  ]
}

This structure forces the client to come up with some kind of algorithm to parse the data and solve conflicts between multiple advisory.sboms.status values which might contradict each other.

This should be fixed by #1098. The status field is replaced with purl_statuses that contains list of purls with the specific status. As advisory can refer to different packages with different statuses, this should remain the array

repo: trustification/trustify


text:
Adds Checkout to main-branch action

... because otherwise there's nothing to build from
Many thanks for submitting your Pull Request :heart:!
Please make sure that your PR meets the following requirements:

[ ] You have read the contributors guide
[ ] Pull Request title is properly formatted: FAI-XYZ Subject
[ ] Pull Request title contains the target branch if not targeting main: [0.3.x] FAI-XYZ Subject
[ ] Pull Request contains link to the JIRA issue
[ ] Pull Request contains link to any dependent or related Pull Request
[ ] Pull Request contains description of the issue
[ ] Pull Request does not include fixes for issues other than the main ticket

\approve

\lgtm


text:
problem with online version

Somehow the Detailed plot of the online version doesn't work the same as the offline version. The order of sequences is incorrect :(

it works now, still don't know why =))

repo: trvinh/phyloprofile


text:
fix(json-mapper): fix serialization of additional properties

Serialization of additional properties if @additionalProperties(true) decorator is set on Model
Information

Type
Breaking change

Fix
No

I expected the addition of the @additionalProperties decorator to a Model to also allow serialization of any additional properties but it didn't. This changes fixes this.

Pull Request Test Coverage Report for Build 1836605096

9 of 9 (100.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.007%) to 95.688%

Totals

Change from base Build 1830608288:
0.007%

Covered Lines:
4037

Relevant Lines:
4050

💛  - Coveralls

Hello @KODIKAS-NL
Thanks for this first PR ;)
Just minor changes!
See you
Romain

:tada: This PR is included in version 6.102.1 :tada:
The release is available on:

v6.102.1
GitHub release

Your semantic-release bot :package::rocket:

authors: KODIKAS-NL Romakita coveralls

repo: tsedio/tsed


text:
About your trained model

Could you please provide your trained model?
Thank you so much.

你好，你训练出淘宝数据集了吗？非常感谢

你能提供你训练有素的模型吗？ 太感谢了。
1

Thanks for your attention on our work. We have released the pretrained model. Please check pretrained-model-evaluation.

repo: tsinghua-fib-lab/CLSR


text:
Use SIGCHLD for graceful child cleanup without hanging

We can't guarantee that child processes exit immediately.  Rather than hanging, we handle the SIGCHLD we receive to ensure that we wait on a process when it's ready to be waited upon.

e73a8e85878ddd5e60075b8b6daca5d52c6dbd06


text:
Programs the produce their output too fast block cm

$ cargo run yes

This is because we are "flushing" the input until we hit "EAGAIN" (I don't remember if it's actually EAGAIN, but it's besides the point). So in cause of yes it never finishes "flushing". We can try to fix that by limiting amount of lines we "flush" to unblock the UI.

It also rises the problem of potentially infinite output that my consume all the memory.

repo: tsoding/cm


text:
Use Callout Manager plugin as source for callouts.

This pull requests adds support for the Callout Manager API, allowing Callout Manager to provide a list of callouts (and their icons/colors) to use for callout completions. It introduces a new drop-down setting to change the source for callout suggestions.
By default, Completr's callouts.json file will be used.
If Callout Manager is installed, a new option labelled "Callout Manager" will be available.
Selecting this option will have Completr suggest the callouts detected by Callout Manager instead.
Screenshot:

(the `deprecated` callout is a custom callout)

Sorry for the delay. I've been pretty inactive on here.


text:
Message proxy to bot

I have a bot. I want to make a chat inside the bot. Admins can send messages
Is it possible to send *Message from user to all admins?
Its like proxy, user send message to bot, bot send it to other users.
Thank you

yep its call forward)

repo: tucnak/telebot


text:
Release candidate 1.8.1

Fix issue with phpmap git tag, set it to current relese 1.35
Remove AD CI config for safeptr, see #64

Pull Request Test Coverage Report for Build 2656421287

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.06%) to 89.921%

Totals

Change from base Build 2259383905:
0.06%

Covered Lines:
3203

Relevant Lines:
3562

💛  - Coveralls

authors: ahueck coveralls

repo: tudasc/TypeART


text:
Can not download graphs

The link to http://atlarge.ewi.tudelft.nl/graphalytics/ is broken.

Our server is currently down due to an issue in the data center. Currently we are working on migrating data back from our mirror site. Our apologies for the inconvenience,  and we will provide you an update on this within a week.

Thanks for the answer! Hope the issue is solved soon.

@wlngai any updates?

Now I can access the mirror 👍

Thanks for reporting the issue. All dataset should be made accessible by end of today.

Looks like the server is down again (at http://atlarge.ewi.tudelft.nl/graphalytics/)

authors: brunoalr sampollard wlngai

repo: tudelft-atlarge/graphalytics


text:
doesnt work with faraday 0.9.2

Tumblr.configure do |config|
config.consumer_key = "A4U....."
config.consumer_secret = "aK8...."
config.oauth_token = "A4U....."
config.oauth_token_secret = "aK8..."
end
client = Tumblr::Client.new
# client = Tumblr::Client.new(:client => :httpclient)
client.info
NoMethodError: undefined methodclient=' for #Faraday::ConnectionOptions:0x0000000310f948 from /var/lib/gems/2.1.0/gems/faraday-0.9.2/lib/faraday/options.rb:31:in block in update'
from /var/lib/gems/2.1.0/gems/faraday-0.9.2/lib/faraday/options.rb:20:ineach' from /var/lib/gems/2.1.0/gems/faraday-0.9.2/lib/faraday/options.rb:20:in update'
from /var/lib/gems/2.1.0/gems/faraday-0.9.2/lib/faraday/options.rb:52:inmerge' from /var/lib/gems/2.1.0/gems/faraday-0.9.2/lib/faraday.rb:69:in new'
from /var/lib/gems/2.1.0/gems/tumblr_client-0.8.2/lib/tumblr/connection.rb:19:inconnection' from /var/lib/gems/2.1.0/gems/tumblr_client-0.8.2/lib/tumblr/request.rb:8:in get_response'
from /var/lib/gems/2.1.0/gems/tumblr_client-0.8.2/lib/tumblr/request.rb:26:inget' from /var/lib/gems/2.1.0/gems/tumblr_client-0.8.2/lib/tumblr/user.rb:5:in info'
Will somebody fix it?

1, please!

+1

Hm, i can't seem to reproduce this. On ruby 2.1.0 with the following gems:
~ >ruby -v
ruby 2.1.0p0 (2013-12-25 revision 44422) [x86_64-darwin14.0]
~ >gem install tumblr_client
Fetching: mime-types-data-3.2016.0521.gem (100%)
Successfully installed mime-types-data-3.2016.0521
Fetching: mime-types-3.1.gem (100%)
Successfully installed mime-types-3.1
Fetching: oauth-0.5.1.gem (100%)
Successfully installed oauth-0.5.1
Fetching: simple_oauth-0.3.1.gem (100%)
Successfully installed simple_oauth-0.3.1
Fetching: multipart-post-2.0.0.gem (100%)
Successfully installed multipart-post-2.0.0
Fetching: faraday-0.9.2.gem (100%)
Successfully installed faraday-0.9.2
Fetching: faraday_middleware-0.9.2.gem (100%)
Successfully installed faraday_middleware-0.9.2
Fetching: tumblr_client-0.8.5.gem (100%)
Successfully installed tumblr_client-0.8.5
8 gems installed
~ >irb
2.1.0 :001 > require 'tumblr_client'
2.1.0 :002 > Tumblr.configure do |config|
2.1.0 :003 >       config.consumer_key = "[..]"
2.1.0 :004?>     config.consumer_secret = "[..]"
2.1.0 :005?>     config.oauth_token = "[..]"
2.1.0 :006?>     config.oauth_token_secret = "[..]"
2.1.0 :007?>   end
2.1.0 :008 > client = Tumblr::Client.new(:client => :httpclient)
2.1.0 :009 > client.posts('staff.tumblr.com')['total_posts']
 => 1807

Can you share the output of gem list? And the ruby version if you're on some other version than 2.1.0.

$ ruby -v
ruby 2.3.0p0 (2015-12-25 revision 53290) [x86_64-linux]
$ gem list
*** LOCAL GEMS ***
actioncable (5.0.0)
actionmailer (5.0.0, 4.2.6, 4.2.5, 4.1.10)
actionpack (5.0.0, 4.2.6, 4.2.5, 4.1.10)
actionview (5.0.0, 4.2.6, 4.2.5, 4.1.10)
activejob (5.0.0, 4.2.6, 4.2.5)
activemodel (5.0.0, 4.2.6, 4.2.5, 4.1.10)
activerecord (5.0.0, 4.2.6, 4.2.5, 4.1.10)
activesupport (5.0.0, 4.2.6, 4.2.5, 4.1.10)
airbrussh (1.1.0)
angularjs-rails (1.5.0)
arel (7.1.1, 6.0.3, 5.0.1.20140414130214)
ast (2.3.0)
awesome_print (1.7.0, 1.6.1)
bcrypt (3.1.11)
bigdecimal (1.2.8)
binding_of_caller (0.7.2)
builder (3.2.2)
bundler (1.12.4)
bundler-unload (1.0.2)
byebug (9.0.5, 8.2.2)
capistrano (3.6.0, 2.15.9)
capistrano-bundler (1.1.4)
capistrano-harrow (0.5.2)
capistrano-rails (1.1.7)
carrierwave (0.11.0)
carrierwave-neo4j (2.0.1)
carrierwave-processing (1.1.0)
chronic (0.10.2)
coffee-rails (4.1.1, 4.0.1)
coffee-script (2.4.1)
coffee-script-source (1.10.0, 1.9.1.1)
colored (1.2)
colorize (0.8.1, 0.7.7)
commonjs (0.2.7)
concurrent-ruby (1.0.2, 1.0.1)
crass (1.0.2)
debug_inspector (0.0.2)
devise (4.2.0)
did_you_mean (1.0.0)
diff-lcs (1.2.5)
domain_name (0.5.20160310, 0.5.25)
erubis (2.7.0)
execjs (2.7.0, 2.6.0)
executable-hooks (1.3.2)
exifr (1.2.4)
faker (1.6.3)
faraday (0.9.2)
faraday_middleware (0.10.0)
faraday_middleware-multi_json (0.0.6)
gem-wrappers (1.2.7)
geoip (1.6.1)
globalid (0.3.7, 0.3.6)
google-translate (1.1.2)
gpx_utils (0.0.1)
hashie (2.1.2)
highline (1.7.8)
hike (1.2.3)
htmlentities (4.3.4)
httmultiparty (0.3.16)
http-cookie (1.0.2)
httparty (0.13.7)
httpclient (2.8.0)
i18n (0.7.0)
io-console (0.4.5)
jbuilder (2.6.0, 2.4.1, 2.3.2)
jquery-rails (4.2.1, 4.1.1, 3.1.4)
json (1.8.3)
json_pure (1.8.3)
jwt (1.5.4)
less (2.6.0)
less-rails (2.7.1)
loofah (2.0.3)
mail (2.6.4, 2.6.3)
mechanize (2.7.3, 2.1.1)
method_source (0.8.2)
mime-types (3.1, 3.0, 2.6.2)
mime-types-data (3.2016.0521, 3.2016.0221)
mimemagic (0.3.1)
mini_portile (0.6.2)
mini_portile2 (2.1.0, 2.0.0)
minitest (5.9.0, 5.8.3, 5.8.2)
multi_json (1.12.1, 1.12.0, 1.11.2)
multi_xml (0.5.5)
multipart-post (2.0.0)
mysql (2.9.1)
mysql2 (0.3.20)
neo4j (7.0.6)
neo4j-core (6.1.4)
neo4j-rake_tasks (0.5.4)
net-http-digest_auth (1.4)
net-http-persistent (2.9.4)
net-scp (1.2.1)
net-sftp (2.1.2)
net-ssh (3.2.0)
net-ssh-gateway (1.2.0)
net-telnet (0.1.1)
nio4r (1.2.1)
nokogiri (1.6.8, 1.6.7.2, 1.6.6.2)
nokogumbo (1.4.7)
ntlm-http (0.1.1)
oauth (0.5.1)
oauth2 (1.2.0)
omniauth (1.3.1)
omniauth-facebook (4.0.0)
omniauth-google-oauth2 (0.4.1)
omniauth-oauth2 (1.4.0, 1.3.1)
orm_adapter (0.5.0)
os (0.9.6)
parser (2.3.1.3)
pkg-config (1.1.7)
power_assert (0.2.6)
powerpack (0.1.1)
protected_attributes (1.1.3)
psych (2.0.17)
puma (3.2.0)
quiet_assets (1.1.0)
rack (2.0.1, 1.6.4, 1.5.5)
rack-test (0.6.3)
rails (5.0.0, 4.2.6, 4.2.5, 4.1.10)
rails-deprecated_sanitizer (1.0.3)
rails-dom-testing (2.0.1, 1.0.7)
rails-html-sanitizer (1.0.3)
railties (5.0.0, 4.2.6, 4.2.5, 4.1.10)
rainbow (2.1.0)
rake (11.2.2, 11.1.2, 10.4.2)
rdoc (4.2.2, 4.2.1, 4.2.0)
redis (3.2.2)
redis-objects (1.2.1)
resource_accessor (1.2.4)
responders (2.3.0)
rmagick (2.15.4)
rspec (3.5.0)
rspec-core (3.5.3)
rspec-expectations (3.5.0)
rspec-mocks (3.5.0)
rspec-support (3.5.0)
rubocop (0.43.0)
ruby-prof (0.15.8)
ruby-progressbar (1.8.1)
rubygems-bundler (1.4.4)
rubyzip (1.2.0)
rvm (1.11.3.9)
sanitize (4.0.1)
sass (3.4.22, 3.4.21, 3.2.19)
sass-rails (5.0.6, 5.0.4, 4.0.5)
sdoc (0.4.1)
soundcloud (0.3.2)
spring (1.7.2, 1.4.0)
sprockets (3.7.0, 3.6.0, 3.5.2, 2.12.4)
sprockets-rails (3.1.1, 3.0.4, 2.3.3)
sqlite3 (1.3.11)
sshkit (1.11.1)
test-unit (3.1.5)
thor (0.19.1)
thread_safe (0.3.5)
tilt (2.0.5, 2.0.2, 1.4.1)
tubesock (0.2.6)
turbolinks (5.0.1, 2.5.3)
turbolinks-source (5.0.0)
twitter-bootstrap-rails (3.2.2)
tzinfo (1.2.2)
uglifier (3.0.2, 3.0.0, 2.7.2)
unf (0.1.4)
unf_ext (0.0.7.2, 0.0.7.1)
unicode-display_width (1.1.1)
unidecoder (1.1.2)
vimeo (1.5.4)
warden (1.2.6)
web-console (2.3.0)
webrobots (0.1.2, 0.1.1)
websocket (1.2.2)
websocket-driver (0.6.4)
websocket-extensions (0.1.2)
whatlanguage (1.0.5)
whenever (0.9.7)
yt (0.25.35)
zip (2.0.2)
zipruby (0.3.6)

I just updated gem to latest version and problem resolved.

Works if in Gemfile:
gem 'tumblr_client', git: 'https://github.com/tumblr/tumblr_client.git'

then
bundle install
# Using tumblr_client 0.8.6 (was 0.8.5) from https://github.com/tumblr/tumblr_client.git (at master@a72b7f4)

authors: aprotsyk defect isidzukuri tchret


text:
Minor import time output suppression for windows

These outputs are problematic when piping output to other programs.
"where" writes some unhelpful stuff to stderr/stdout "INFO: Could not find files for the given pattern(s). so this quiets that.
Put the "injected compiler path" behind the verbose flag.
The failure to find cl.exe message is now written to stderr to avoid having it unintentionally redirected.

Seems reasonable.

authors: allenbenz turboderp

repo: turboderp/exllama