Switch to PUT for manifest requests

We occasionally receive GET requests from search engines or other crawlers, malicious as well as benevolent ones, for manifests without any filters. These take several minutes to prepare and put a heavy load on the ES backend. It was a mistake to use GET for expensive requests. REST suggests to use POST or PUT for things that create server-side state or have other side-effects. POST would be used for non-idempotent operations, and PUT for idempotent ones. Since we cache already generated manifest, we switched to PUT. For backwards compatibility, we left GET /fetch/manifest/files in place, but deprecated it. We would like to removed as soon as possible since it is still requested without filters by the above types of bots.
Please switch the data browser (the original and the rewrite) to PUT /fetch/manifest/files instead. Note that any redirects return by that PUT should be followed with GET. It is my uneducated guess that this is a trivial change and my hope that this can be done quickly and non-bureaucratically.

Assignee to provide description for CC.

Description updated.

Assignee to follow up with CC

@NoopDog Please review review assign to the appropriate pipeline.

Is there any urgency to this request? Seems like this has been working fine for many years with only the occasional hiccup and is low priority.
We can prioritize this after the current AnVIL and HCA go-live efforts.  Meanwhile, if you want to make the PUT manifest operational (leaving the GET in place) we can let you know when this is completed so you can remove the GET interface.

Is there any urgency to this request?

There is some level of urgency with every request that we make. We would like to remove the deprecated GET endpoint by the end of this year. Considering that this is a trivial change, that should be feasible, despite the other priorities. If it is not trivial, please explain why.

Seems like this has been working fine for many years with only the occasional hiccup and is low priority.

It has not been working fine. I described what the impact is.

This is a sketch of the change, to back up my claim that it's trival:
diff --git a/packages/data-explorer-ui/src/hooks/useRequestFileLocation.ts b/packages/data-explorer-ui/src/hooks/useRequestFileLocation.ts
--- packages/data-explorer-ui/src/hooks/useRequestFileLocation.ts
+++ packages/data-explorer-ui/src/hooks/useRequestFileLocation.ts
@@ -29,10 +29,11 @@
  * Returns fetch request options.
  * @param accessToken - Access token.
  * @returns fetch request options.
  */
-function createFetchOptions(accessToken: string | undefined): RequestInit {
+function createFetchOptions(accessToken: string | undefined, method: string): RequestInit {
   return {
+    method: method,
     headers: accessToken ? { Authorization: "Bearer " + accessToken } : {},
   };
 }

@@ -42,12 +43,13 @@
  * @param accessToken - Access token.
  * @returns @see FileLocation
  */
 export const getFileLocation = async (
+  method: string,
   url: string,
   accessToken: string | undefined
 ): Promise<FileLocation> => {
-  const options = createFetchOptions(accessToken);
+  const options = createFetchOptions(accessToken, method);
   const res = await fetch(url, options);
   const jsonRes: FileLocationResponse = await res.json();
   return {
     commandLine: jsonRes.CommandLine,
@@ -71,12 +73,13 @@
   accessToken: string | undefined,
   resolve: ResolveFn,
   reject: RejectFn,
   active: MutableRefObject<boolean>,
-  retryAfter = 0
+  retryAfter = 0,
+  method = 'GET'
 ): void => {
   setTimeout(() => {
-    getFileLocation(url, accessToken).then((result: FileLocation) => {
+    getFileLocation(url, accessToken, method).then((result: FileLocation) => {
       if (result.status === FILE_LOCATION_PENDING) {
         if (!active.current) {
           reject({
             location: "",
@@ -130,9 +133,9 @@
   const run = useCallback(() => {
     if (url) {
       runAsync(
         new Promise<FileLocation>((resolve, reject) => {
-          scheduleFileLocation(url, token, resolve, reject, active);
+          scheduleFileLocation(url, token, resolve, reject, active, method='PUT');
         })
       );
     }
   }, [runAsync, token, url]);

Assignee to obtain ETA from CC.

Thanks for the sketch. We will work with @bvizzier-ucsc to schedule this for after the React app release so we don't have to change both the Angular app and the React app.
Cheers,
D

@BruceRodrigues this can be exercised from the

The export selected data flow Projects>Export>Request File Manifest e.g. https://data.humancellatlas.dev.clevercanary.com/explore/export/download-manifest

Each project's metadata tab see file manifest.

The ask is

Please switch the data browser (the original and the rewrite) to PUT /fetch/manifest/files instead. Note that any redirects return by that PUT should be followed with GET

This is implemented in the React data browser deployed to https://explore.data.humancellatlas.org/
The GET version of the API is still being used by

https://data-browser.lungmap.net. This is still on the Angular version.
prod https://prod.anvil.gi.ucsc.edu/explore/datasets. This change has not yet been deployed to this environment.

Triaging to discuss with @bvizzier-ucsc.

Assignee (@bvizzier-ucsc) to discuss with CC.

@NoopDog Can you confirm where this is deployed?
Is this in the update for the AnVIL Managed Access Beta?
And, I assume, we need to schedule an update for LungMAP that includes this change.

This change is merged to main on data-browser and will be available wherever main is deployed.
Once deployed using main on the data browser-repo, the new environments for AnVIL Explorer dev and prod will have this change.
We are working on updating LungMap to use the new Data Explorer and hope to have that live late next week.

Once deployed using main on the data browser-repo, the new environments for AnVIL Explorer dev and prod will have this change.

The agreed-upon procedure for deploying the Data Browser for AnVIL is for Clever Canary to request a deployment from our operator on the #team-boardwalk channel on Slack. Was this done after the PR addressing this issue was merged?

Assignee to consider next steps.

Assignee to create blockers.

Lungmap appears to have been updated to main. I am assuming we can now close this and move forward with a PR that completes the resolution for DataBiosphere/azul#5533, by removing the support for GET /fetch/manifest/files and GET /manifest/files.

We still have one instance of the Angular UI used to validate new DCP catalogs. We are hoping to be able to remove this instance in the next week or two. You may want to hold until this instance is also removed.
@bvizzier-ucsc @hannes-ucsc

@hannes-ucsc: "I don't think that instance is used to generate manifests, but I'll double check."

13 manifest requests in the last 4 months on that instance

compared to > 33k on the regular instance

I don't want this to enter another blocked/waiting cycle on CC and am happy to accept the risk of breaking that instance for the rare case that an internal user uses it to request a manifest, from now until when the instance is completely removed in two weeks.


feat(dex-types): support customizations

(*꒦ິ꒳꒦ີ)
what

add support for dex type customizations
make smol changes to support sv dlc

lgtm


Detection less effective when running falcon-sensor in Container

I am orchestrating my falcon-sensors (kernel mode) via a DaemonSet. I am using the CVE-2021-4034 as my detection test. It seems as my hosts where I have installed falcon sensor directly via the .deb package, it gets detected consistently. However, on hosts where it is deployed via this chart (kernel sensor, not container sensor), it doesn't get detected. Does this make sense at all? The commands show up in the command log if I browse the host, it just doesn't trigger a detection.

Hello,
Please open a case with crowdstrike support. This isn't the place to seek support around the sensor itself. Thanks.


No permission for admin after changed password

Describe the bug
After changing the password for admin, I can log in but Mage day that the user doesn't have any permission
To Reproduce
Steps to reproduce the behavior:

Log in as admin with basci credential
Go to user profile
Change password
Log out
Log in

Expected behavior
Permissions stay the same
Screenshots

Desktop (please complete the following information):

OS: Debian GNU/Linux 12 (bookworm)
Browser Firefox
Version 0.9.43

Additional context
None

@KyllianBeguin can you try version 0.9.45 and see whether you still can reproduce the issue?

I think it's fixed in this PR: https://github.com/mage-ai/mage-ai/pull/3982


sled fixups and prefixes for final conversion bits

Add prefixes to the program tree names in sled and remove the erroneous id structure field which was no longer needed.
Still need to

[x] Add a new_from_db method for the Program enumeration
[x] Flatten the ProgramMap and DispatcherMap into BpfManager
[x] Convert all bpfMap bits into sled

OK @dave-tucker This should do it! Sorry for the delay it took me a while to unravel all of the delicate data lifetime management we had baked in over the past year 💀


Cannot specify GPU limits in the runner

Controller Version
0.23.0
Helm Chart Version
No response
Deployment Method
Kustomize
Checks

[X] This isn't a question or user support case (For Q&A and community support, go to Discussions. It might also be a good idea to contract with any of contributors and maintainers if your business is so critical and therefore you need priority support
[X] I've read releasenotes before submitting this issue and I'm sure it's not due to any recently-introduced backward-incompatible changes
[X] My actions-runner-controller version (v0.x.y) does support the feature
[X] I've already upgraded ARC to the latest and it didn't fix the issue

Resource Definitions
apiVersion: actions.summerwind.dev/v1alpha1
kind: RunnerDeployment
metadata:
    name: runner-deployment
spec:
    template:
        spec:
            repository: org/repo
            labels:
                - gke-gpu-runner
            resources:
                limits:
                    nvidia.com/gpu: 1 # requesting 1 GPU

To Reproduce
1. Have a GPU node on GKE
2. Specify the `nvidia.com/gpu` resource limit

Describe the bug
The created pod does not have the GPU limit
Describe the expected behavior
It should have the nvidia.com/gpu limit
Controller Logs
https://gist.github.com/JCMais/101e494b52967b7b70ea7ba221063674

Runner Pod Logs
https://gist.github.com/JCMais/101e494b52967b7b70ea7ba221063674

This also includes the generated POD yaml.

Additional Context
No response

nvm, this seems to be working now, I've no idea why it did not add the limit initially. lol


13.15 FPS on RTX 2080 Ti with yolact_resnet50_54_800000.pth

IT IS NOT ISSUE.
JUST FOR NOTE AND SHARING.
UBUNTU 18.04 / RTX2080TI / 1080P VIDEO /
CUDA10.0 + CUDNN7.6.5 / PYTORCH 1.4.0 /
MODEL : yolact_resnet50_54_800000.pth

@blackCmd what input size? I can got 13 FPS with deepsnake while using 1280x720 input


Swift implementation example

Is there a Swift implementation of Atlas-Messenger-IOS or how to use Atlas-IOS in Swift?

@sibeliusseraphini currently nothing official from Layer, but there is this: https://github.com/kwkhaw/Layer-Parse-iOS-Swift-Example which should help explain a lot.  The APIs are the same, the syntax is all that differs.


Upgrade bootstrap library to 3.x

When you do this we should switch the client to relying on publicly available repositories of these libraries. There's really no reason to check them in. It would make upgrades more efficient as well.

This is going to be replaced by whatever is used in the 3.0 [#164] UI anyway so will close this in favor of that.


Full documentation link broken?

Hey there,
Nice theme! It looks like the link to the full documentation in the README.md is broken. I tried to search around on https://docs.gethugothemes.com but it doesn't seem to be there? Is there a different location for this themes specific documentation?
Cheers!

Hey @joshuar
It looks like we didn't have this documentation. but you can follow our universal guide to get started. thanks

Coolio, thanks @tfsomrat for the clarification!


rfc-bibtex: init at 2.2.1

Generate bibtex entries from IETF rfc/drafts, for instance:
$ rfcbibtex RFC5246 draft-ietf-tls-tls13-21
@techreport{RFC5246,
author = {T. Dierks and E. Rescorla},
title = {{The Transport Layer Security (TLS) Protocol Version 1.2}},
howpublished = {Internet Requests for Comments},
type = {RFC},
number = {5246},
year = {2008},
month = {August},
issn = {2070-1721},
publisher = {RFC Editor},
institution = {RFC Editor},
url = {http://www.rfc-editor.org/rfc/rfc5246.txt},
note = {\url{http://www.rfc-editor.org/rfc/rfc5246.txt}},
}
@techreport{I-D.ietf-tls-tls13,
author = {Eric Rescorla},
title = {{The Transport Layer Security (TLS) Protocol Version 1.3}},
howpublished = {Working Draft},
type = {Internet-Draft},
number = {draft-ietf-tls-tls13-21},
year = {2017},
month = {July},
institution = {IETF Secretariat},
url = {http://www.ietf.org/internet-drafts/draft-ietf-tls-tls13-21.txt},
note = {\url{http://www.ietf.org/internet-drafts/draft-ietf-tls-tls13-21.txt}},
}
Motivation for this change
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[x] Fits CONTRIBUTING.md.

Success on aarch64-linux (full log)
Attempted: rfc-bibtex
Partial log (click to expand)
writing top-level names to rfc_bibtex.egg-info/top_level.txt
reading manifest file 'rfc_bibtex.egg-info/SOURCES.txt'
writing manifest file 'rfc_bibtex.egg-info/SOURCES.txt'
running build_ext

----------------------------------------------------------------------
Ran 0 tests in 0.000s

OK
/nix/store/pwcxcpvgzbdc8jnyrwcjkxn8rzj20476-rfc-bibtex-0.2.1

Success on x86_64-linux (full log)
Attempted: rfc-bibtex
Partial log (click to expand)
writing top-level names to rfc_bibtex.egg-info/top_level.txt
reading manifest file 'rfc_bibtex.egg-info/SOURCES.txt'
writing manifest file 'rfc_bibtex.egg-info/SOURCES.txt'
running build_ext

----------------------------------------------------------------------
Ran 0 tests in 0.000s

OK
/nix/store/4jcz5xmn6zs7l4sjjs9w2i8x27dzz7lc-rfc-bibtex-0.2.1


Profile images in publisher teasers not woking for some users

in my network tab there are some infura ipfs calls that are failing

ex: https://infura-ipfs.io/ipfs/QmWHkFZvQwGgw2WMwfpC91ofG8qdvTsUYbh8BX8dhA1Bp2
Not sure if they are relevant

The error message from Infura is "Public Gateway Is Not Supported Anymore - Setup a Dedicated Gateway"
I think if you setup a gateway, it will work. For example we created https://mpowered.infura-ipfs.io/


typing: expose error type from tracebackdata

@aroberge this allows fine-grained hints in custom error reporters, e.g. for
from friendly_traceback.core import TracebackData
from friendly_traceback.message_parser import get_parser
from friendly_traceback.typing_info import CauseInfo

class MyError(Exception): ...

parser = get_parser(MyError)

@parser.add
def my_report(message: str, tb_data: TracebackData[MyError]) -> CauseInfo:
    reveal_type(tb_data)
    reveal_type(tb_data.exception_type)
    reveal_type(tb_data.exception_name)
    reveal_type(tb_data.value)
    reveal_type(tb_data.exception_frame)
    return {}

mypy will report
foo.py:15: note: Revealed type is "friendly_traceback.tb_data.TracebackData[foo.MyError]"
foo.py:16: note: Revealed type is "Type[foo.MyError]"
foo.py:17: note: Revealed type is "builtins.str"
foo.py:18: note: Revealed type is "foo.MyError"
foo.py:19: note: Revealed type is "Union[types.FrameType, None]"

@aroberge there should be no change in runtime behaviour, only type hints were changed. I also noticed this PR introduces a regression for type hints as some internal usages of TracebackData now lack explicit generic error type; fixing those turns out to be less trivial than I expected. Will try to amend that in a separate PR on weekend.

Thank you once again @hoefling.


fix(webapp): temporary fix for testnets #915

What does this PR do?

Resolve #915

Steps to test

Copy telos, wax or proton .env testnets and run locally

CheckList

[ ] Follow proper Markdown format
[ ] The content is adequate
[ ] The content is available in both english and spanish
[ ] I Ran a spell check

@fvives99 are you sure you updated all the endpoints i believe they are also set for hapi service

If im not mistaken, this commit does that, if not ill re verify


feat/schedule-fare-thought-modal

Please review before merging.

:tada: This PR is included in version 1.5.1 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


all: future of the openbsd/mips64 port

The openbsd/mips64 port is currently in limbo - this issue is an attempt to identify a path forward.
Background
OpenBSD 6.9 (May 2021) onward requires that system calls be made via libc stubs - direct system calls are no longer permitted (see https://github.com/golang/go/issues/36435 for more details). The openbsd/amd64 and openbsd/arm64 ports were converted in Go 1.16, while openbsd/arm and openbsd/386 were converted early in Go 1.17.
The only port not converted is openbsd/mips64 - this was in part due to the lack of support for SDYNIMPORT with internal linking. An initial conversion was done which required external linking (https://go-review.googlesource.com/c/go/+/342510), however among other issues, this meant that the misc-compile-openbsd would not be able to compile test openbsd/mips64 - it was suggested that internal linking with SDYNIMPORT would be a better route.
The last OpenBSD release that Go tip works on for openbsd/mips64 is OpenBSD 6.8, which has been EOL since October 2021. To further complicate matters, a working version of the port has been maintained in the OpenBSD ports tree (https://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/lang/go/). For this port to be useful, other repositories like golang.org/x/sys/unix have needed to switch to indirect system calls, which has further broken openbsd/mips64 in Go tip (https://github.com/golang/go/issues/58110).
Aside from the openbsd/mips64 port being broken, it also means that the indirect syscall migration cannot be completed and there is various technical debt lingering from this in the Go runtime/linker. The builder is also currently offline.
Current Status
Changes to implement SDYNIMPORT with both internal and external linking were mailed in July 2022 (https://go-review.googlesource.com/c/go/+/415815) - these two changes are ~320 lines of code combined. A year and two full Go release cycles later, the openbsd/mips64 port is still blocked on the second of these changes (the first landed during the previous release cycle).
Moving Forward
There are at least three potential resolutions:

Land the above SDYNIMPORT changes and get the port operational again.
Revisit switching to external linking
Decommission the port

(1) would be preferable as it would allow the port to become functional again, however it is unclear when this may occur. The openbsd/mips64 port is a second class port and mips64 is not a first-class architecture - this seems to be part of the reason why it is difficult to get reviews, however the flip side of this is that it has not lowered the review bar and/or provided any way to progress.
(2) avoids changes to the Go linker, instead switching the port entirely to external linking - this means that builds take longer, the misc-openbsd-compile target is unable to test openbsd/mips64, but the port can become functional again.
(3) given that the port is broken and that it is preventing technical debt from being cleaned up, decommissioning is an option. This is a last resort, however it seems preferable to the current state.
If (2) or (3) are preferred I can send appropriate changes for review.

(CC @golang/openbsd @golang/mips)

It sounds like the main request here is some reviews for the stack at https://go-review.googlesource.com/c/go/+/512475/1.

@cherrymui @mknyszek @rsc has there been any further consideration here, given the imminent freeze?


Fails to correctly determine default interface on Fedora

Running Without Root:
Nov 25 13:18:38.012 [INFO] zmap: started
Nov 25 13:18:38.025 [FATAL] zmap: could not detect default network interface (e.g. eth0). Try running as root or setting interface using -i flag.

Running as Root:
Nov 25 13:18:45.075 [INFO] zmap: started
Nov 25 13:18:45.199 [ERROR] get-gw: ioctl failure: No such device
Nov 25 13:18:45.199 [FATAL] zmap: could not detect default IP address for for usbmon1. Try specifying a source address (-S).

usbmon1 is not a valid interface for this machine. Running with -ip2p1 (the correct interface) works correctly.
ifconfig output:
$ ifconfig
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet <IP_ADDRESS>  netmask <IP_ADDRESS>
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 0  (Local Loopback)
        RX packets 12  bytes 1124 (1.0 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 12  bytes 1124 (1.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

p2p1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet ANONYMIZED  netmask <IP_ADDRESS>  broadcast ANONYMIZED
        inet6 ANONYMIZED  prefixlen 64  scopeid 0x20<link>
        inet6 ANONYMIZED  prefixlen 64  scopeid 0x0<global>
        ether ANONYMIZED  txqueuelen 1000  (Ethernet)
        RX packets 63972  bytes 88285317 (84.1 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 13434  bytes 1697321 (1.6 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

This still occurs in centos 7.1.1503:
[root@fry ~]# zmap -p 53 <IP_ADDRESS>/32
Nov 02 21:58:44.352 [WARN] zmap: too few targets relative to senders, dropping to one sender
Nov 02 21:58:44.398 [FATAL] get-iface-ip: ioctl failure: No such device
[root@fry ~]# zmap -p 53 -i eno16780032 <IP_ADDRESS>/32
Nov 02 21:59:37.272 [WARN] zmap: too few targets relative to senders, dropping to one sender
Nov 02 21:59:37.273 [INFO] zmap: output module: csv
Nov 02 21:59:37.273 [INFO] csv: no output file selected, will use stdout
0:00 0%; send: 1 done (48 p/s avg); recv: 0 0 p/s (0 p/s avg); drops: 0 p/s (0 p/s avg); hitrate: 0.00%
0:00 0%; send: 1 done (48 p/s avg); recv: 0 0 p/s (0 p/s avg); drops: 0 p/s (0 p/s avg); hitrate: 0.00%
<IP_ADDRESS>
0:01 13%; send: 1 done (48 p/s avg); recv: 1 0 p/s (0 p/s avg); drops: 0 p/s (0 p/s avg); hitrate: 100.00%
0:02 25%; send: 1 done (48 p/s avg); recv: 1 0 p/s (0 p/s avg); drops: 0 p/s (0 p/s avg); hitrate: 100.00%
0:03 38%; send: 1 done (48 p/s avg); recv: 1 0 p/s (0 p/s avg); drops: 0 p/s (0 p/s avg); hitrate: 100.00%
0:04 50%; send: 1 done (48 p/s avg); recv: 1 0 p/s (0 p/s avg); drops: 0 p/s (0 p/s avg); hitrate: 100.00%
0:05 63% (3s left); send: 1 done (48 p/s avg); recv: 1 0 p/s (0 p/s avg); drops: 0 p/s (0 p/s avg); hitrate: 100.00%
0:06 75% (2s left); send: 1 done (48 p/s avg); recv: 1 0 p/s (0 p/s avg); drops: 0 p/s (0 p/s avg); hitrate: 100.00%
0:07 88% (1s left); send: 1 done (48 p/s avg); recv: 1 0 p/s (0 p/s avg); drops: 0 p/s (0 p/s avg); hitrate: 100.00%
0:08 100% (0s left); send: 1 done (48 p/s avg); recv: 1 0 p/s (0 p/s avg); drops: 0 p/s (0 p/s avg); hitrate: 100.00%
Nov 02 21:59:46.304 [INFO] zmap: completed

centos is based on f19. You probably need to file a ticket against RHEL 7 or CentOS 7.


WIP: Heat transfer transient adjoint

Some notes:

Currently hardcoded to only use backward Euler time integrators.
It reads the previous temperature values from disk at every timestep (no checkpointing).
It changed the quasi-static function signature from solveAdjoint to reverseAdjointTimestep to be consistent with the forward pass.
It updates Axom to include the axom::MFEMSidreDataCollection bugfix needed to correctly read an mfem::ParGridFunction from disk.

Codecov Report

Merging #964 (84f09fd) into develop (a59f888) will decrease coverage by 0.57%.
The diff coverage is 35.64%.

@@             Coverage Diff             @@
##           develop     #964      +/-   ##
===========================================
- Coverage    89.45%   88.88%   -0.57%
===========================================
  Files          141      141
  Lines        10749    10823      +74
===========================================
+ Hits          9615     9620       +5
- Misses        1134     1203      +69

Files Changed
Coverage Δ

src/serac/physics/base_physics.hpp
30.76% <0.00%> (ø)

src/serac/physics/state/state_manager.cpp
74.01% <0.00%> (-5.39%)
:arrow_down:

src/serac/physics/state/state_manager.hpp
85.00% <ø> (ø)

src/serac/physics/heat_transfer.hpp
69.45% <33.33%> (-16.73%)
:arrow_down:

src/serac/physics/base_physics.cpp
59.33% <50.00%> (-0.26%)
:arrow_down:

.../serac/numerics/functional/element_restriction.cpp
96.19% <100.00%> (ø)

src/serac/physics/solid_mechanics.hpp
86.66% <100.00%> (ø)

src/serac/physics/tests/parameterized_thermal.cpp
100.00% <100.00%> (ø)

...cs/tests/parameterized_thermomechanics_example.cpp
100.00% <100.00%> (ø)

src/serac/physics/tests/solid_finite_diff.cpp
100.00% <100.00%> (ø)

... and 1 more

... and 1 file with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

I changed the interface to reflect our discussion yesterday. The sensitivities are no longer accumulated internally. This means only the sensitivity increment is returned to a user for each timestep. I also added a field for the timestep size to be consistent with the forward pass. Let me know what you think!

Closed in favor of https://github.com/LLNL/serac/pull/998


Image Uploading Fails for files with dashes and underscores in their names.

Look this up

Not consistent. Small files under 75kb with dashes and underscores are uploaded properly.


[2/5] Visualizations (merge after 1/5)

I’ll review after 1/5 is merged as this PR seems cumulative

I'll merge to unblock :)


Active Directory Federation Services

Many companies using Office 365 will implement ADFS.
I am not a specialist of Oauth2 and SAML, it seems ADFS implements Oauth2 (maybe the microsoft way).
It would be usefull to be able to use oauth2_proxy with ADFS.

Would be very useful for many internal business use cases.

I would appreciate this feature too.


Add Problems related to Queue:

What information is missing?
Adding problems related to queue in the blog section:
I agree to follow this project's Code of Conduct
I'm a GSSoC'24 contributor
I want to work on this issue

I am a GSSoC contributor and would like to work on adding problems related to queues as described in issue #386. Could you please assign this issue to me? Thank you!


[TACHYON-924] Relax the dir permission bits' assert restriction

Relax the dir permission bits' assert restriction in FileUtilsTest#setLocalDirStickyBitTest.
https://tachyon.atlassian.net/browse/TACHYON-924

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

Can one of the admins help verifying this patch? TACHYON-933 also raise the same issue (duplicate with: TACHYON-924) @apc999  Thanks!

LGTM


allow_existing for fs.create_directory()

One situation I got surprised by is that seemingly according to Python's os.makedirs() and bash's mkdir creating a directory for a path which is a symlink to a directory is apparently ok.  I guess we should retain this behavior?

My brain hurted parsing that sentence (which I'm sure is Python/bash's fault not yours) but what do you mean?
You mean os.makedirs(some/path/that/is/a/symlink) turns the symlink into a directory?

mkdir -p doesn't complain when you specify a symlink to a directory.  Neither does os.makedirs(, exist_ok=True).  They both leave it as a symlink.  When I first wrote the applicable tests I wrote them to check for a complaint that the 'directory' already existed.  I was then mildly surprised when I saw they failed.  I then did the tests below, roughly, and found the precedence for not failing when trying to create a directory where a symlink to a directory is present.  Presently I have changed the tests to match the behavior of mkdir -p and os.makedirs(, exist_ok=True).
altendky@p1:/tmp$ rm -rf red blue
altendky@p1:/tmp$ mkdir blue
altendky@p1:/tmp$ ln -s blue red
altendky@p1:/tmp$ ls -dl blue red
drwxrwxr-x 2 altendky altendky 4096 Jan  2 14:39 blue
lrwxrwxrwx 1 altendky altendky    4 Jan  2 14:39 red -> blue
altendky@p1:/tmp$ mkdir -p red
altendky@p1:/tmp$ ls -dl blue red
drwxrwxr-x 2 altendky altendky 4096 Jan  2 14:39 blue
lrwxrwxrwx 1 altendky altendky    4 Jan  2 14:39 red -> blue
altendky@p1:/tmp$ python3.8
Python 3.8.1 (default, Dec 27 2019, 18:45:57)
[GCC 9.2.1 20191008] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.makedirs('red', exist_ok=True)
>>>
altendky@p1:/tmp$ ls -dl blue red
drwxrwxr-x 2 altendky altendky 4096 Jan  2 14:39 blue
lrwxrwxrwx 1 altendky altendky    4 Jan  2 14:39 red -> blue

For completeness, here is a follow up showing that both of the above fail when the symlink targets a file.  Which would presumably be expected by 'everyone'.
altendky@p1:/tmp$ touch green
altendky@p1:/tmp$ ln -s green magenta
altendky@p1:/tmp$ ls -dl green magenta
-rw-rw-r-- 1 altendky altendky 0 Jan  2 14:43 green
lrwxrwxrwx 1 altendky altendky 5 Jan  2 14:43 magenta -> green
altendky@p1:/tmp$ mkdir -p magenta
mkdir: cannot create directory ‘magenta’: File exists
altendky@p1:/tmp$ python3.8
Python 3.8.1 (default, Dec 27 2019, 18:45:57)
[GCC 9.2.1 20191008] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.makedirs('magenta', exist_ok=True)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/altendky/.pyenv/versions/3.8.1/lib/python3.8/os.py", line 221, in makedirs
    mkdir(name, mode)
FileExistsError: [Errno 17] File exists: 'magenta'
>>>
altendky@p1:/tmp$ ls -dl green magenta
-rw-rw-r-- 1 altendky altendky 0 Jan  2 14:43 green
lrwxrwxrwx 1 altendky altendky 5 Jan  2 14:43 magenta -> green


Update-Module fails on v.1.8.1

The error message says that the catalog signature doesn't match the hash.

What is the version of PowerShellGet you are using?

Hi!
I have the same problem.
Env: Windows 10, PSVersion 5.1.14393.206

You can use the -SkipPublisherCheck parameter to get around this.  Typically i would not recommend this, but i trust the source of this module.

Since we are now on version 1.17.1 and this is working now, will close.


Split contribution doc into a separate file

Description
Describe the big picture of your changes here to communicate to the maintainers why we should accept this pull request.
If it fixes a bug or resolves a feature request, be sure to link to that issue.
Slowly implementing https://github.com/prometheus-operator/kube-prometheus/issues/1005
This PR moves contributing section into a separate file that is then enhanced with data from similar file in prometheus-operator repository.
Type of change
What type of changes does your code introduce to the kube-prometheus? Put an x in the box that apply.

[ ] CHANGE (fix or feature that would cause existing functionality to not work as expected)
[ ] FEATURE (non-breaking change which adds functionality)
[ ] BUGFIX (non-breaking change which fixes an issue)
[ ] ENHANCEMENT (non-breaking change which improves existing functionality)
[x] NONE (if none of the other choices apply. Example, tooling, build system, CI, docs, etc.)

Changelog entry
Please put a one-line changelog entry below. Later this will be copied to the changelog file.

Regarding #1005, I was gonna mention that on today's contributor office hour but we didn't get to that point.
It would be nice if we could split the effort into smaller and well-defined issues and solve them one by one. I'm proposing this idea just because I'd like to help but I'm don't have a clear understanding of what we want :)

It would be nice if we could split the effort into smaller and well-defined issues and solve them one by one. I'm proposing this idea just because I'd like to help but I'm don't have a clear understanding of what we want :)

The overall idea is that we should split README.md into parts so it will be easier to navigate on the website. In short, we want to move the following sections into separate documents living in Documentation directory (potentially more than one document from one section):

troubleshooting
customization examples
Minikube Example - this one might be a good candidate to add in contributing doc, but I wanted to start small
Continuous Delivery

IMHO in readme we should have only the following content and use links to dive into other documents:

Project Name
(optional) Status Badges
Project Description (what project does, what technologies are used, what are the challenges project tries to solve)
Table Of Contents (used as an entry point to link to other docs in Documentation/ directory)
How to Install
How to Use (brief overview with links to more in-depth scenarios)
License link


Bump Go versions

I'm actually thinking of updating this to remove even the older releases.  Technically golang folks only support 1.7 and 1.8 now... and there are a few things I'd like to revisit again that I couldn't do because of missing support in earlier versions of golang.
@sbinet do you have a reference about tip vs master?

yep:
https://docs.travis-ci.com/user/languages/go/#Specifying-a-Go-version-to-use

This was addressed in #307


main PE soundness theorems

This PR includes the main soundness theorems for partial authorization (in Thm/Partial/Authorization.lean) and partial evaluation (in Thm/Partial/Evaluation.lean).  Draft for now because although it contains over 5K lines of proof (!), it also still contains approximately 52 sorrys (!)
This PR also fixes a few soundness problems which otherwise prevent the theorems from holding (!):

Error residuals in Partial.Response no longer carry a copy of the specific error, just the ID of the policy that errored, so that structural equality of Partial.Response has the intended semantics (matching how the spec authorizer is specified; see #206).
Partial-evaluating true && residual cannot return residual in all cases. Consider the case where residual is a single unknown, and that we substitute it with 37. We need the substitute-and-reevaluate operation to return type-error, not 37. This PR has partial evaluation just return true && residual in all these cases. More precision is possible in the future, but not required for soundness.
Everything in the above bullet also applies to false || residual.
Everything in the above two bullets applies to both Partial.evaluate and Partial.evaluateValue.
When the partial evaluator evaluates a request variable (principal, context, etc) or a GetAttr getting an entity attribute, instead of returning the partial value directly, it needs to evaluateValue it, in case the partial value contains a residual that could be (fully) evaluated (e.g., because a substitution operation was recently performed on it).

Everything in the above bullet also applies to false || residual.
We need typed unknowns :)


Update minor frontend dependencies

This PR updates minor FE dependencies to address issues pointed out by dependabot and by npm audit. (It does not tackle the larger ones, such as Gatsby.) It also fixes a few broken Cypress tests that popped up while updating the dependencies (the outstanding Cypress test failure is addressed in #2189).

This PR updates minor FE dependencies to address issues pointed out by dependabot and by npm audit. (It does not tackle the larger ones, such as Gatsby.) It also fixes a few broken Cypress tests that popped up while updating the dependencies (the outstanding Cypress test failure is addressed in #2189).

Great catch! Being away from J40, I forgot about these cypress tests, even though some took quite bit of time to write. Thanks for bringing this back on the radar for me.
PS - they used to be part of the CI/CD pipeline, however there was some error causing me to remove them. I'll try and find the ticket that captures this.


Fix/id minting inversion

Addresses DT-1594.
Moves the construction of the base id (what DPLA hashes) into the Extractor trait and adds getter methods to be implemented in the provider's extractor.
useProviderName(): Boolean
getProviderId(): String
getProviderName(): String
These methods provide the Extractor trait with all it needs to create the base id, mint the DPLA id and construct the DPLA item URI.  The provider extractor now explicitly states what the base ID is to be constructed from and Extractor does the construction.
If the provider's identifier cannot be or if the combination of values for (useProviderName and getProviderName().isEmpty) do not make sense (e.g. false, false or true, true) extracted an exception is raised and the record is not mapped.

The last commit addresses issues raised by Michael about requiring a provider shortName for all providers and then relying only on useProviderName when minting an id.


Review ID format check

During the release process, our internal release scripts picked up on some HTAN IDs that did not match the HTAN ID Format SOP. However, these errors were not listed on hdash in the Primary IDs follow the HTAN ID Spec section.
For example, WashU had submitted parent biospecimen IDs such as CE336E1-S1, HT128B1-S1H4, and P5296-1N2)
(These have now been resolved, but see example non-conforming IDs in the previous version (v6) of the snATAC-Seq_level_1_atac_tumor manifest https://www.synapse.org/#!Synapse:syn52257214.6 )
Currently the regex rule used for ID validation is ^(HTA([1-9]|1[0-5]))_((EXT)?([0-9]\d*|0000))_([0-9]\d*|0000)$. We may want to look into why errors did not appear for the IDs that should have been caught by the rule.

This may be because the check is only being applied to primary IDs and not 'parent' IDs?

Also one more note, the above regex works for HTAN Data File IDs and HTAN Biospecimen IDs (eg HTA11_120_1211), but not participant IDs (eg HTA11_120)

Updated HTAN ID regex rules (distinct for file, biospecimen, and participant IDs) can be found here: https://github.com/ncihtan/data-models/issues/268#issue-1808171944

This is now fixed and deployed.  I relaxed the leading zero filter.


"Uncaught Error: TypeError [...]" at runtime - Inference issue?

Hi all,
I don't know if this was always the case or it's me noticing only now;
this code doesn't throw any error until runtime,
then at runtime then throws  Uncaught Error: TypeError: Instance of 'Square': type 'Square' is not a subtype of type 'Circle'
Shouldn't this error be cough before?
Thank you

See https://github.com/dart-lang/language/issues/1124; Dart currently has implicit casts. Fixed with a few things mentioned in the response.


Corrected misspelled instances of "ServicePrincipal" as "ServicePrinciple"

Description
Corrected misspelled instances of "ServicePrincipal" wrongly written as "ServicePrinciple".
Related to issue #36634.

@microsoft-github-policy-service agree [company="{your company}"]

@microsoft-github-policy-service agree [company="Tiago"]

@microsoft-github-policy-service agree

@SwathingBlock thanks for your changes , I copied over the changes into https://github.com/Azure/azure-sdk-for-java/pull/37121 and have merged it


[ README ] update deepflow-architecture.png

This PR is for:
update deepflow-architecture.png
Changes to fix the bug

README

Affected branches

main

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


How to load images and mask for unet ,with keras imagedatagenerator

I need to load images and mask for unet model,i dont wanna use cv2 or any libaraires to load images.I wanna use easy way to load up these images.

Have you solved this problem? I have the same problem as you.


chore(main): release 1.0.0

:robot: I have created a release beep boop
1.0.0 (2024-12-11)
Features

add plugin v0.0.1 ([8c68dff]

This PR was generated with Release Please. See documentation.

:robot: Created releases:

v1.0.0
:sunflower:


fix: enable select text by dblclick

first i would like to thank you for that plugin.
i tried to fix the issue with not being able to select text by dblclick.
i add a condition to not preventDefault, if the event target tagName is input or textarea.
i am not yet 100% sure, if that are the only tags which should avoid that - if that's even possible...
it would be nice to hear your opinion.
thx!

just realized, it's a bit more difficult, if writer fields are included :(


AST Walking with changing Environment

https://norvig.com/lispy.html
By coincidence, it is very similar to the AST walk.
TODO:

make an environment class with environment nesting and finding variables fast based on a dictionary.

The AST walking allows only for setting and changing names in the current environment.
How should the set work? There is still an issue with setting structure fields/etc. Right now we can only change the name to a new instance of something.


make Queryable from Python UDF

Closes #851

Current dependencies on/for this PR:

main

PR #870   👈

PR #871

This comment was auto-generated by Graphite.

Added 2 new commits


fix mergeGeometries exception color attribute

related : https://github.com/gkjohnson/three-gpu-pathtracer/issues/641

any feedback always welcome

Excellent work! Thank you

Made some minor style adjustments in a6608cd67f7d93687bc58dfc365a922762fbbe23


pull request for e2e test at 11/13/2016 17:26:11

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

optest/docs/updated_at.md
:white_check_mark:Succeeded

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


Address static analyzer warning in OCPartialMockObject (Issue #543)

Issue #543 about potential nil passed to class_addMethod()

OCPartialMockObject#setupForwarderForSelector

Modified to just return if there is no existing implementation for the method

@erikdoe - Any chance this could be merged so it's in any future OCMock releases?
-Thanks!

@erikdoe  - You've got a much better understanding of the innerworkings of all of this than I do, so I will gladly defer to your gut instincts! 😄
I do suspect you're right, that there is enough other "safety" checks that just skipping the call to "class_addMethod" is likely okay in this erroneous instance of a consumer trying to mock a method that doesn't exist (or can't be found) via ObjC. Especially since it doesn't seem to be causing problems, today - other than the warning message I'm trying to clean up. 😄

@erikdoe - Just hoping to get this approved & pulled in & released to cocoapods sometime soon?
-Thanks!


secret-handshake:  verify ordering of actual/expected

In the Jasmine testing framework, it is convention to:
expect(actual).fn(expected)

But some test suites have the following:
expect(expected).fn(actual)

This causes the error messages to be confusing.
Please verify the secret-handshake exercise to make sure that the expectations are ordered correctly. If they are, then this can be closed.
This issue will help to close #111

Got it

This one is OK and can be closed

Thanks a lot!


⚠ Bofrost.be has degraded performance

In 4e6876e, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 2879 ms

Resolved: Bofrost.be performance has improved in fc96063.


Importing Mindmaps

It would be great if we could import mind-maps of topics+materials, in particular if the nodes in the mind-map come with links.
CC @frauzufall

Hi @frauzufall,
if you're still interested in this, please let me know and I will reopen this.
Cheers,
Robert


[Mempool] CheckSigOps using incorrect constant

Used in https://github.com/stratisproject/StratisBitcoinFullNode/blob/master/src/Stratis.Bitcoin.Features.MemoryPool/MempoolValidator.cs#L768 ->
if (context.SigOpsCost > this.ConsensusOptions.MaxBlockSigopsCost)
Used in core https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L724 ->
if (nSigOpsCost > MAX_STANDARD_TX_SIGOPS_COST)
These are two distinct constants with their own values (the max for blocks is 80 000 and the max for a single transaction is 80 000 / 5 = 16 000).

I experienced a bug partly because of this with a new network.....  I can get a transaction into the mempool where its sig ops is 2.  (well below the 20,000 max which stratis has)....  and you are right, this should be 1/5 of the 20,000 really
Yet this can never get mined because it has many ancestors..... and at consensus time it does the check of the transaction sigops and the sigops of all its ancestors which comes to 56835, well above the max sig ops for a transaction and even a block.
It seems the calculation for ancestors is done after the sig ops check at mempool time but it is done before at consensus time...

I notice this in the config which could possibly overcome it ?
#Maximal size in kB of ancestors of a transaction in mempool (including itself). Defaults to 101kb.   That transaction is actually 113kb in the mempool.

We should fix trx builder, miner and mempool.

some references about this subject:
https://gist.github.com/gavinandresen/4135d03a56e0ecd146c7
https://github.com/bitcoin/bitcoin/issues/747
https://github.com/bitcoin/bitcoin/pull/4150

I'm working on this issue, this is the branch if you want to check it before PR
https://github.com/stratisproject/StratisBitcoinFullNode/compare/master...MithrilMan:bug/maxStandardTxSigopsCost?expand=1

@dangershony I'm not sure we need to fix builder/miner/mempool if the problem was just that we were accepting a nonstandard transaction in memory pool.
AFAIU the other checks were against the right parameter, in bitcoincore we find only two occurrances of MAX_STANDARD_TX_SIGOPS_COST`
https://github.com/bitcoin/bitcoin/search?utf8=✓&q=MAX_STANDARD_TX_SIGOPS_COST&type=
Can somebody confirm that my changes are enough?
https://github.com/stratisproject/StratisBitcoinFullNode/compare/master...MithrilMan:bug/maxStandardTxSigopsCost?expand=1

suggest reopening as the PR only covers part of the problem


simple bundle.json validation

This is quite minimal, but it ~should fix~ is a start for #48.
Now, both
{}

and
{
  "type": "github",
  "repo": "oraoto/pony-websocket"
}

result in errors, while the empty bundle still is accepted:
{"deps":[]}

I've tried to keep duplication low, but I'm also still new to Pony. Happy to take directions :)

One oddity is that using this bundle.json,
{
  "deps": [
    { "tyxpe": "github", "repo": "jemc/pony-jason" }
  ]
}

the output is
$ ../pony-stable/build/release/stable fetch
failed to parse dependency: {"tyxpe":"github","repo":"jemc/pony-jason"}
failed to parse dependency: {"tyxpe":"github","repo":"jemc/pony-jason"}

-- So it seems Bundle().deps() is created twice? Or I botched something up.
Another data point, using an empty object bundle.json, {}, I get this:
JSON error at: /Users/stephan/Misc/pony/pony-crdt/bundle.json: missing "deps" array
JSON error at: /Users/stephan/Misc/pony/pony-crdt/bundle.json: missing "deps" array
No bundle.json in current working directory or ancestors.

I suspect something is wonky in this section: https://github.com/ponylang/pony-stable/blob/353733f5933bab2fe51e7938abcd8b0267119e14/stable/main.pony#L38-L50

@SeanTAllen agreed! I'd feel better with tests here, too. :) I'll try adding some tests to this PR this week. (Doing this one the side, so please bear with me if it takes a bit longer.)

Ok, I've updated the branch: there's now some tests for Bundle(...), both reading existing file, and a simple check for when it's supposed to create an empty file itself.
Looks like circleci was instructed to run make test anyways, so this is already wired up: https://circleci.com/gh/ponylang/pony-stable/66
I've also reverted a but of what I've proposed initially: this is now only checking for the deps key, the values themselves aren't checked yet.
@SeanTAllen How does that look? I'd be grateful for any suggestions :)

I think @jemc is the best person to evaluate this as he has experience on how tests should be set up for applications and I have zero real experience with that.

@SeanTAllen, @jemc thank you both! 😃

Thank you!


Minimum Python version

Hi,
I get the following error for installation:
pip3 install cm4mlops --user
Collecting cm4mlops
  Using cached https://files.pythonhosted.org/packages/ff/16/46b9f311bb802787dee1891a63612a5e7e2b0202983d4cc658164cca3f33/cm4mlops-0.2.tar.gz
    Complete output from command python setup.py egg_info:
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "/tmp/pip-build-mhgdidky/cm4mlops/setup.py", line 40
        elif (spec := importlib.util.find_spec(name)) is not None:
                   ^
    SyntaxError: invalid syntax

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

The Python3 version is 3.6.8. I don't know if that version is the correct one. Is there a minimum version for Python3 for this package?

Hi @mahmoodn currently we need minimum python version 3.8.

This issue is fixed in this PR but the minimum python requirement is 3.7. Most of the CM scripts won't work with 3.6 or below.


order of function eval bug

I'm not sure I have the expertise to figure this out, and I am also not sure what impact (if any) this has on the viz, but we often get an error on page load:

within updateLegendTextToView()
here:
var state_data = waterUseViz.stateData
      .filter(function(d) {
        return d.abrv === activeView;
    });

(the error is map_utils.js?_c=7941337:301 Uncaught TypeError: waterUseViz.stateData.filter is not a function)

Gah, that means the async loading still isn't in the right order. I've learned that that error means it still has null for the stateData.  I haven't seen that error since my big pr a couple days ago....but that was the bulk of my frustration for the legend task. I'll keep thinking about it, and maybe one of our D3 experts will realize why it's still loading wrong. Do you happen to know if the error only comes when the browser doesn't have a hash? Or is it just once in awhile?

I thought I had fixed this with the if() statements at https://github.com/USGS-VIZLAB/water-use-15/blob/master/js/build_map.js#L217 and https://github.com/USGS-VIZLAB/water-use-15/blob/master/js/build_map.js#L229, and I can't reproduce it right now, but I see that those commits happened 5 days ago whereas this issue was created 2 days ago, and I was able to reproduce it on some branch, some build, details now lost, this morning. So I'm not sure whether those changes fully fix the problem.

I'm getting this consistently when the URL I go to is for a state rather than loading the US first and then clicking the state. It seems to be because addStates ends up calling updating the view (which eventually calls updateLegendTextToView but waterUseViz.stateData is loaded later in the fillMap function.
wu_state_data.json and wu_data_15_sum.json are really small files so I think this can just be fixed by having those part of the initial queue. I'm going to try that.

This was fixed in #286.


domain change

domain changed from stud.hsnr.de to stud.hn.de

@MasterOfSpeed Thank you for the update! Pull request merged.


Consolidate all color / ASNI output code into a single object

Takes all of the ANSI handling from the default CLI experience and the --help  and consolidates the logic into a single place. This makes it easy to handle something like NO_COLORS and to not show ANSI inside tests, which I will do in a separate PR

My initial impetus was supporting hyperlinks in the terminal to type/interface names, I left that code in there - open to dropping it and I'll have a separate PR for hyperlink support once I can figure that out.

To help with PR housekeeping, I'm going to close this PR since none of us had time to finish this after @orta left 😢


Fix last version of Peewee and others methods deprecated

Coverage decreased (-1.009%) to 93.064% when pulling 79fd3296475558e4dec19bddf6e1526c2ced77e2 on gregadc:fix-last-version-peewee into 7e9bddeb3b8495a26442b1c86744e9fb187fe88f on TheGhouls:master.


Updated Medeasy notes website template

Description
Updated Website by adding About and Contact Us section to it.
Fixes:  #615

Type of change

[x] New feature (non-breaking change which adds functionality)

Checklist:

[x] I have made this from my own
[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[x] My changes generate no new warnings

ATTACH SCREEN-SHOTS / DEPLOYMENT LINK
Final Website after Updating.

consider this under GSSoC'22 contribution.

@priyanshi1282

@priyanshi1282

Yes?

@VidhiBhatt01 I have resolved the conflicts, please check once.


Fixing typos

this is the branch that i used git cherry-pick to add the earlier commit

hmm... doesn't seem like you started from the master branch when you created the new one.


Bytes type bug

When I tried to create a Bytes type, after generating, I ran into an error. The screenshots below show the schema file content and the generated code.

i was able to track down the issue and fixed it here but I am not sure about how to proceed with making sure the tests pass because I dont (really) know GraphQL. I currently use this in a project so this fix does work I just need help with the test.
Here, I am not sure I understand what it should be as I get parser error. I'd love some help here so I can get this merge and (probably) move on to other issues I am working on.
cc @steebchen i'd appreciate some help here.

Can you be more specific what exactly doesn't work? The implemented tests seem to pass, as Bytes refer to []bytes already here.
Are you using the latest go client version?
To answer your second question, you could probably just specify a string "foo" in the GraphQL setup query.

Yes, I am using latest go client (v0.9.0)
what doesn't work is that when you specify type "Byte" in the prisma file and generate the go code, it returns "Bytes" (see the first screenshot) which is an invalid type. So i get errors
also, yes, Bytes refer to []bytes somewhere in the code but when you run go generate to generate the db_gen.go code, it still returns Bytes instead of []byte which is literally the issue I am/was having.

That's weird. I still can't reproduce though. For me, it uses Bytes, but in the generated file it's defined as type Bytes = types.Bytes (and in package types: type Bytes = []byte).
Can you please give the exact error message you are getting, and ideally sending the db_gen.go file, as well as your prisma schema to help me reproduce? Thanks.

Please re-open if this still happens with the latest version.


Error: Cannot find module 'esbuild'

mdx-bundler version: 6.0.1
node version: 14.17.1
npm version: 6.14.13

This is my config file - mdx.ts
import { bundleMDX } from "mdx-bundler";
import path from "path";

export const prepareMDX = async () => {
  if (process.platform === "win32") {
    process.env.ESBUILD_BINARY_PATH = path.join(
      process.cwd(),
      "node_modules",
      "esbuild",
      "esbuild.exe"
    );
  } else {
    process.env.ESBUILD_BINARY_PATH = path.join(
      process.cwd(),
      "node_modules",
      "esbuild",
      "bin",
      "esbuild"
    );
  }

  const mdxSource = `
---
title: Example Post
published: 2021-02-13
description: This is some description
---

# Wahoo
`.trim();

  const { code, frontmatter } = await bundleMDX(mdxSource);

  return { code, frontmatter };
};

This is my page file - blog.tsx
import Layout from "@/components/Layout";
import { prepareMDX } from "@/lib/mdx";
import { getMDXComponent } from "mdx-bundler/client";
import { useMemo } from "react";

export default function blog({
  code,
  frontmatter
}: {
  code: any;
  frontmatter: any;
}) {
  const Component = useMemo(() => getMDXComponent(code), [code]);
  return (
    <Layout>

{frontmatter.title}

{frontmatter.description}

      <Component />
    </Layout>
  );
}

export async function getStaticProps() {
  const { code, frontmatter } = await prepareMDX();
  return { props: { code, frontmatter } };
}

Now I'm getting this error

Even though I see esbuild package in node_modules but still this error is shown.. why? how to solve it ?

I think you may forget to install esbuild as your dependency. Try installing npm i esbuild and try again. :)

I think you may forget to install esbuild as your dependency. Try installing using npm i esbuild and try again. :)

I did but still it isn't working

I'm having the exact same issue when using the remix-run's blues stack. But, it works just fine with remix runs indie stack.


no project found

I accidentally created this ticket because it got the error that the iOS project is not found. To fix it, make sure to install it, as it's written in the docs, with --save and not --save-dev.

Still getting error about ios project not found


Pie plot request.

There is no df.hvplot.pie() analogue to the native df.plot.pie(). Maybe pie plots have a bad reputation, but I think they are extremely useful especially for financial modelling where monetary distributions often sum to 1.
df.hvplot.pie() would be a wonderful interface in my opinion.
I would love an hvplot interface because just moving the legend on a matplotlib plot is a nightmare.

Thank you for your consideration of this feature. If you are curious, I'm working on a token distribution model for https://spiritfoundation.io/

Thanks for the feature request!
Pie charts have often been discussed at the holoviews level and we are thinking of a Donut element that could easily be turned into a pie chart. Until such an element exists, there is nothing that hvplot can do about it.
I'll move this issue to the holoviews repo.

Thanks for the feature request!
Pie charts have often been discussed at the holoviews level and we are thinking of a Donut element that could easily be turned into a pie chart. Until such an element exists, there is nothing that hvplot can do about it.
I'll move this issue to the holoviews repo.


Update VSCode artifact to support VMs with older powershell versions

Also added the !runcode parameter to the install so that it does not start Code.exe when the install completes

Hi @workleodig, I'm your friendly neighborhood Azure Pull Request Bot (You can call me AZPRBOT). Thanks for your contribution!

This seems like a small (but important) contribution, so no contribution license agreement is required at this point. Real humans will now evaluate your PR.

TTYL, AZPRBOT;

Also, we will be moving more toward leveraging Chocolatey. So, this artifact will get updated to use the package visualstudiocode.


Fix angle parameter from smirnoff99frosst issue #84

This pull request addresses smirnoff99Frosst issue#84. It fixes a 5-membered ring angle parameter to not match tetrahedral carbons.

Um, tests are failing, @bannanc . Is that related to this one? If not we can merge anyway.

The badge on master is also failing so I don’t think this caused it. If
there’s not an issue about it I can write one.
On Mon, Dec 17, 2018 at 19:57 David L. Mobley<EMAIL_ADDRESS>wrote:

Um, tests are failing, @bannanc https://github.com/bannanc . Is that
related to this one? If not we can merge anyway.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/openforcefield/openforcefield/pull/147#issuecomment-448088158,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ALagHRfD-jVPMIPt3b8JhGmrb6R4D0Q9ks5u6GeagaJpZM4ZQtUf
.

--

Caitlin C. Bannan
Ph.D. Candidate
Mobley Group
UC Irvine - Chemistry Department
<EMAIL_ADDRESS>mobleylab.org

Please. Thanks!

Let's remember @j-wags will have to import these fixes into the updated SMIRNOFF 1.0 format files in the topology branch!
@bannanc : Is there a changelog where we keep a running list of the bugfixes in the force field between point releases?

"Importing" is pretty easy FTR -- there is a conversion utility which takes the parameters from a modified AMBER-format parameter file they resided in originally (remember, this was a conversion from AMBER) and inserts them into a template providing our XML format. So importing will basically just mean updating this utility to use the correct XML format. (Tagging @j-wags FTR)


Fixes to FPGA GZIP Reference Design performance and warnings

Description
Fix number of reordering units for gzip-LL. Fix free() call in gzip.cpp to remove warning.
GZIP-LL was mistakenly using 6 reordering unit which is not necessary since we only have 1 global memory port (host memory), so this has been removed.
A call to free() in gzip.cpp is causing compiler warnings, this is now fixed.
Fixes # (issue)
Type of change
[ X] Bug fix (non-breaking change which fixes an issue)
How Has This Been Tested?
Ran GZIP regtest

@JoeOster this is a very minor change to an FPGA reference design.  I'm not sure if you want to review changes like this, or if I have the authority to approve them on my own?  Audrey is away for a few weeks so I can't ask her.

@JoeOster this is a very minor change to an FPGA reference design. I'm not sure if you want to review changes like this, or if I have the authority to approve them on my own? Audrey is away for a few weeks so I can't ask her.

FPGA is owned by you, so I have no issue with you approving and merging these samples if they are updated. I do review these but not extensively. Just make sure they go through CI and pass first


receive commands

Hello,
can somebody give me please a hint, how to receive the commands, sended from the web-ui?
For example I send a 'custom' Type Command, where do I get it?
I think it uses the HttpURLConnection from the 'RequestManager.java' or? Because the web-ui send the command on the open connection with the client. Is that correct?

Currently it's not possible to send command to the client app because it uses HTTP protocol. One option would be to send command as a response to the location report.

Which protocol should the client use to receive commands? Why is the HTTP protocol used at the moment? Has is some advantages?
Is that feature in planing to send commands as a response to the location report?

The HTTP protocol is used to make code simpler and communication more stable.
There is no specific plans around commands for Traccar Client app at the moment. It was just an idea of how to approach it.


Set local pipeline thread stack size

PR Summary
Related #4268.

Set local pipeline thread stack size to 10MB by default.
Read the PipelineMaxStackSizeMB configuration value from config.

Thread stack OS system default size is:

on Windows - 1MB
on MacOs - 0.5MB
on Linux - 8MB

We should use the same stack size for all platforms to get predictable behavior.
This value should match the Windows PowerShell value for backward compatibility (I expect that .Net Core and Windows PowerShell consume the stack as well as .Net Framework and Windows PowerShell).
Perhaps default 10MB may be too large if we use many local pipelines for paralleling. We can reconsider this later.
PR Checklist
Note: Please mark anything not applicable to this PR NA.

[x] PR has a meaningful title

[x] Use the present tense and imperative mood when describing your changes

[x] Summarized changes
[NA] User facing Documentation needed

[NA] Issue filed - Issue link:

[x] Change is not breaking
[NA] Make sure you've added a new test if existing tests do not effectively test the code changed

[NA] Add [feature] if the change is significant or affects feature tests

[x] This PR is ready to merge and is not Work in Progress.

If the PR is work in progress, please add the prefix WIP: to the beginning of the title and remove the prefix when the PR is ready.

@PowerShell/powershell-committee reviewed this and don't believe that the stack size should even be a configurable setting until there is a clear need to make it settable.  Recommendation is to not even have it settable despite what Windows PowerShell did.

@SteveL-MSFT Stack size default is different on different platforms - should we set the same default internally to get predictable behavior on all platforms? I think it make sense.

@iSazonov yes, @PowerShell/powershell-committee agrees to changing the default on all systems.  We thought the only point that needed discussion from the committee was configuration.

A new PR was submitted based on the committee's review: #6224
I will close this PR.


Investigate using boltons.funcutils to create modules

Description

functools.partials generate objects that are interpreted as data by the help function. Maybe boltons could fix this.
help(xclim.icclim)

@huard #394 partly solves the help issue and the signature of the wrapped functions. However, the name and the docstring are still the ones from the wrapped indice. Is this something we want to fix? (Considering that fixing the docstring is on another level of complexity...)


Selecting "Allow multiple options to be chosen." in form builder changes Select tag type to Checkboxes

After attempting to add a Select box where multiple answers can be chosen to a form, I was greeted with a list of checkboxes.
This is not expected behaviour, for a few reasons:

I chose Select, which has functionality for this, by adding the "multiple" element to the tag. Example: https://codepen.io/anon/pen/GvaWOj
I did not choose Checkbox, which is an element specifically for checkboxes.
There's already a Checkbox option. Why on earth is functionality for an existing input type in another inputs configuration?

I would recommend copying the functionality for the multiple entries and adding it to the checkbox answer type, so that users can easily create checkboxes, and have a more sane UX workflow. The select type can have the expected multiple select box, and for those who want radio buttons, you could rename it to be "Checkbox/Radio", and add in an option to "Allow only one option to be chosen". This would also resolve issue #5932

This has been resolved by https://github.com/concrete5/concrete5/pull/5964


Change complex expressions in templates example

Change complex expressions in templates example using filters instead of computed properties

Thanks for the suggestion, but I don't really see value added here. We've just refactored a computed property to a filter, making the example more complex. Filters are generally just for simple text transformations that have nothing to do with the business logic of the app, so it's often not appropriate and generally more work to convert a complex template expression to a filter, rather than a computed property or method.

I respect your opinion, but I disagree. Whenever we use filters, we follow one of the major principles of the functional paradigm, immutability. Whenever we use computed properties and methods, the chance of generating side effects in our app is too great. You said that filters are just for text transformations, exactly the context of the example. Thank you for your time.

Whenever we use filters, we follow one of the major principles of the functional paradigm, immutability. Whenever we use computed properties and methods, the chance of generating side effects in our app is too great.

A couple notes here:

Immutability isn't actually a principle, but rather a tool commonly used in service of a principle: predictability.

Filters do not guard against side effects (including mutability). In the case of strings, which have no self-mutating methods, one is only protected from the side effects from an explicit assignment like:
this.fullName = 'new string'

I've never personally encountered a case where someone did this accidentally, but the soon-to-be-released eslint-plugin-vue will actually be able to flag any side effects (including mutation) in computed properties, so that it really will be impossible if you're worried.
When we move beyond strings to arrays or objects, functions are passed a reference rather than an immutable value in JS, so filters are actually able to mutate data properties just like anything else. And if you're really passionate about predictability, then you're very likely also using a central state management solution like Vuex. In this case, you could import the store anywhere in your app (including a filter) and call an action, triggering a mutation. It's not good practice, but once again, the filter won't protect you.
The point is, if you've found there's a large chance of accidentally generating side effects when using computed properties or methods, the problem isn't computed properties or methods - it's developer education. By overusing filters, you only avoid one of the more obvious ways of generating side effects, ignoring the larger problem of training developers about what qualifies as a side effect, when to avoid them, and how.

You said that filters are just for text transformations, exactly the context of the example.

Reading the rest of the sentence, you'll notice I said filters are for "text transformations that have nothing to do with the business logic of the app." This filter is specific to fullName, rather than strings in general, so it's business logic and best suited to a computed property.
Computed properties are also automatically cached, since they can track their own dependencies, so will offer improved performance over filters in every scenario.


Added info extractor for www.tele5.de, a German TV station.

Before submitting a pull request make sure you have:

[x] At least skimmed through adding new extractor tutorial and youtube-dl coding conventions sections
[x] Searched the bugtracker for similar pull requests
[x] Checked the code with flake8

In order to be accepted and merged into youtube-dl each piece of code must be in public domain or released under Unlicense. Check one of the following options:

[x] I am the original author of this code and I am willing to release it under Unlicense
[ ] I am not the original author of this code but it is in public domain or released under Unlicense (provide reliable evidence)

What is the purpose of your pull request?

[ ] Bug fix
[ ] Improvement
[x] New extractor
[ ] New feature

Description of your pull request and other information
This adds support for www.tele5.de, which is a German TV station providing temporary online access to movies and TV shows after broadcast.
I have added tests, but since the referenced videos will only be available for limited time, these tests will fail in the future. They all were successful at the time this PR has been created, though. Unfortunately the site does not provide videos that are available for a longer time.

@dstftw I've implemented the requested changes - sorry for the beginner bugs - I've never done python programming before.
The only requested change I've not implemented is 'Capture and use display id.' because not all URLs contain the actual video ID.
For example the URL from the second test always points to the current (and only available) episode of a series, so the actual video reachable via this URL will change - for example each week, when a new episode is made available.

I'm not talking about video id, capture part of URL as display id.

@dstftw I think I've implemented all requested changes.
Let me know if there's anything missing or if I should squash the commits before merging.

Here is my take on it:
https://github.com/mrtnmtth/youtube-dl/blob/master/youtube_dl/extractor/tele5.py
My regex is more relaxed by making www optional and allowing http without s.
Also I only download parse the html if there is no id in the url.
Feel free to copy parts of it as you like.


Prevent go test to update go.mod

Q
A

🐛 Bug fix?
no

🚀 New feature?
no

⚠ Deprecations?
no

❌ BC Break
no

🔗 Related issues
none

❓ Documentation
no

Description
Prevent go test to mess up with go.mod

Is this the fix we're all waiting for that will finally fix our problems in ACC tests ?

I don't think this is related unfortunatly ...


PR-#104 Improvements to Ansible based CI framework

Created a new role for IOmeter. This role helps in creating & instantiating a container that
consumes iSCSI storage and runs the dynamo.

Placed the Dockerfile for building the iometer image & dynamo binary (which will be copied
into the container) in ./files

Created a new playbook, test-iometer.yml to run the iometer test on the lines of test-fio.yml

Updated run-tests.yml to include test-iometer testcase. Also created a commenting convention
to capture test details

Updated fio role's defaults file (defaults/main.yml) to include fio_run_duration as an argument to
the fio container command. Also, changed the variable name for the tests-fio container reflect
"image" instead of "container"

Updated the fio role's tasks (tasks/main.yml) to pass fio_run_duration while specifying the
container command. Changed fio container variable name as mentioned above

Updated the cleanup tasks (tasks/main.yml) to remove the stale node entry for the previous
iSCSI session using iscsiadm-m node -T  -o delete

Accepting this pull request. As a followup to this, some re-factoring is required w.r.t the contents of the ansible/files directory, which is becoming an umbrella folder for misc files.


Breeze UI will not start when running on Node LTS 8.9

I am getting the following error when running npm start on node 8.9.1 on OSX 10.13.1:
13 verbose stack Error<EMAIL_ADDRESS>start: npm-run-all --parallel webpack:watch electron:serve
13 verbose stack Exit status 1
13 verbose stack     at EventEmitter. (/usr/local/lib/node_modules/npm/node_modules/npm-lifecycle/index.js:280:16)
13 verbose stack     at emitTwo (events.js:126:13)
13 verbose stack     at EventEmitter.emit (events.js:214:7)
13 verbose stack     at ChildProcess. (/usr/local/lib/node_modules/npm/node_modules/npm-lifecycle/lib/spawn.js:55:14)
13 verbose stack     at emitTwo (events.js:126:13)
13 verbose stack     at ChildProcess.emit (events.js:214:7)
13 verbose stack     at maybeClose (internal/child_process.js:925:16)
13 verbose stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:209:5)
14 verbose pkgid<EMAIL_ADDRESS>15 verbose cwd /Users/paf0/blockchain/Breeze/Breeze.UI
16 verbose Darwin 17.2.0
17 verbose argv “/usr/local/Cellar/node/8.9.1/bin/node” “/usr/local/bin/npm” “start”
18 verbose node v8.9.1
19 verbose npm  v5.5.1

Hi @patrickafoley, have you still not managed to run this?
What's the full set of commands you're running?

@bokobza sorry, yes, it does work. I'm not sure what fixed it, perhaps a reinstall of node.

cool, thanks!