improve test cases

Current coverage is 98.06% (diff: 60.00%)

Merging #10 into master will decrease coverage by 0.30%

@@             master        #10   diff @@
==========================================
  Files             1          1
  Lines           306        310     +4
  Methods           4          4
  Messages          0          0
  Branches         50         49     -1
==========================================
+ Hits            301        304     +3
- Misses            1          3     +2
+ Partials          4          3     -1

Powered by Codecov. Last update 8afb3ba...b750dc6


How to revert Visual Studio to 16.3

Describe the bug
Visual Studio 16.4 has some nasty bugs related to codegen, causing our environment to completely break.
https://developercommunity.visualstudio.com/content/problem/843918/wrong-code-generation-in-1640.html
https://developercommunity.visualstudio.com/content/problem/844870/bad-codegen-after-update-to-vc-2019-1640.html
https://developercommunity.visualstudio.com/content/problem/842917/error-c3538-when-using-scoped-lock-in-derived-temp.html
The last one we can work around, but the first 2 are completely broken with no workarounds. There should be an option to revert to prior VS versions if major bugs like this occur.
Virtual environments affected

[ ] macOS 10.15
[ ] Ubuntu 16.04 LTS
[ ] Ubuntu 18.04 LTS
[ ] Windows Server 2016 R2
[x] Windows Server 2019

I realized this was the wrong repo. I moved it to the correct repo https://github.com/microsoft/azure-pipelines-image-generation/issues/1450

Currently, we do not have a way for you to revert to VS 16.3. We have some investigations on being able to re-run jobs on prior virtual environments, but I don't have a timeline to share at the moment.

Closing as this is currently as designed.


Schemas are not created if the first schema is 'public' [redshift]

What version of Flyway are you using?
4.1.2
Which client are you using? (Command-line, Java API, Maven plugin, Gradle plugin, SBT plugin, ANT tasks)
SBT
What database are you using (type & version)?
AWS Redshift
What operating system are you using?
OS X
What did you do?
In my build.sbt, this is the buggy code:
flywaySchemas := Seq("public", "otherSchema")
Which results in this:
[info] Successfully validated 0 migrations (execution time 00:00.125s)
[info] Creating Metadata table: "public"."schema_version"
[info] Current version of schema "public": << Empty Schema >>
[info] Schema "public" is up to date. No migration necessary.
[success] Total time: 2 s, completed Apr 24, 2017 5:37:38 PM

Notice how otherSchema was not created.
However, with this code:
flywaySchemas := Seq("schema1", "schema2", "schema3")
We get this:
[info] Creating schema "schema1" ...
[info] Creating schema "schema2" ...
[info] Creating schema "schema3" ...
[info] Creating Metadata table: "schema1"."schema_version"

What did you expect to see?
[info] Creating schema "otherSchema" ...

What did you see instead?

Duplicate of #1328


Add a requests example for JSON, update simpletest

Adding a more advanced example requests_json.py to demonstrate commonly-used requests functionality such as setting custom headers, sending data, sending json data, and parsing data from a response.
Updates simpletest to show automatically-decoded text response, the raw response (as bytes), the response's HTTP status code, and response's HTTP headers.

Closing, going to structure this differently...


No Python wheels for ARM64 Linux

I'm building an app inside a Docker container on my M1 Mac, and I was surprised to find that I could not install the oso Python module from PyPI because there are no arm64 wheels published for Linux. I was able to add another stage to my Dockerfile to build my own wheel (and verified that all tests pass) but it would be nice to install from PyPI.
I'd be happy to help with the GitHub workflow to get it to produce arm64 wheels but I think there's a couple different ways that it could be done so I thought I'd bring it up first before throwing diffs at you.

I would also appreciate this


Worked on the d3 tree diagram, also added an updated button

Merged files resolved

Resolving conflicts offline.


Unnecessary source code in a tutorial

Describe the documentation issue
A little issue with a PDB tutorial on the BioPandas website. Unnecessary code lines is present at the beginning of the tutorial:
import pandas as pd
import numpy as np
import sys
import gzip
from warnings import warn
try:
    from urllib.request import urlopen
    from urllib.error import HTTPError, URLError
except ImportError:
    from urllib2 import urlopen, HTTPError, URLError  # Python 2.7 compatible
from biopandas.pdb.engines import pdb_records
from biopandas.pdb.engines import pdb_df_columns
from biopandas.pdb.engines import amino3to1dict
import warnings
from distutils.version import LooseVersion

class PandasPdb(object):
    """
    Object for working with Protein Databank structure files.

...

    def parse_sse(self):
        """Parse secondary structure elements"""

ppdb = PandasPdb().fetch_pdb('3eiy')
ppdb.df

Suggest a potential improvement or addition
Delete the PandasPdb class source code from this section.
Thank you!

Ooops, good catch. Must have left it in there by accident. Should be fixed now. Thanks!


SESSION_SECRET is empty when generate arch=app

I ran:
$ lotus new sampleapp -d postgresql --test=rspec --arch=app
      create  sampleapp/.lotusrc
      [...]

And my .env.development and .env.test was:
$ cat sampleapp/.env.development
# Define ENV variables for development environment
SAMPLEAPP_DATABASE_URL="postgres://localhost/sampleapp_development"
SAMPLEAPP_SESSIONS_SECRET=""

But, in arch=container:
lotus new samplecontainer -d postgresql --test=rspec
      create  samplecontainer/.lotusrc
      [...]

I received:
$ cat samplecontainer/.env.development
# Define ENV variables for development environment
SAMPLECONTAINER_DATABASE_URL="postgres://localhost/samplecontainer_development"
WEB_SESSIONS_SECRET="4a48ce5873497d8375f8908c1be776aba4df406b095ae9c67afc3c3553ec5769"

@vyper this is a trivial fix for app generator, do you want to give it a try? ;)

@joneslee85 the @AlfonsoUceda was more quickly than me!


v2 build fails

I can no longer build v2.
https://ci.appveyor.com/project/vmarkovtsev/hercules/builds/19769146#L280
https://travis-ci.org/src-d/hercules/jobs/445897269#L1698

I don't see the Gopkg.lock or any other dependency lock. Are you using go get directly? I would strongly suggest adding it.
In any case, I will remove that definition from v2.

Yeah, switching to dep is on my list. Thanks!

Should be fixed in the latest v2 release.


Faster text annotations and contours layer

Description:
When there are many objects, the GUI is too slow. Refactor code to include a single scatter plot contours layer and test alternative options to LabelItem, such as TextItem or a QLabel. See here: https://stackoverflow.com/questions/66327667/fixed-text-position-using-an-imageview-within-pyqtgraph-pyside2
https://stackoverflow.com/questions/70096424/symbol-in-pyqtgraph

https://stackoverflow.com/questions/17103698/plotting-large-arrays-in-pyqtgraph?rq=1


Weather implementation (WIP)

This PR closes: #218

These commits are from #233, I'm working off of the master branch on my fork so that's why you see them.
If all goes well and #233 gets merged, you can ignore these commits.


[resolves #541] Add support for wildfly-9.0.x docker image

Refer to this link for build results (access rights to CI server needed):
https://fabric8-ci.fusesource.com/job/wildfly-camel-pullreq/503/
Test FAILed.

retest this please

Refer to this link for build results (access rights to CI server needed):
https://fabric8-ci.fusesource.com/job/wildfly-camel-pullreq/504/
Test FAILed.

retest this please

Refer to this link for build results (access rights to CI server needed):
https://fabric8-ci.fusesource.com/job/wildfly-camel-pullreq/505/
Test FAILed.

Refer to this link for build results (access rights to CI server needed):
https://fabric8-ci.fusesource.com/job/wildfly-camel-pullreq/506/
Test PASSed.


Fix logging bug

Fix bug where error was logged everytime an assignment was removed from an issue.

LGTM

LGTM


Getting HLS link without opening VLC

I would like to just get the link given to HLS when using the --player-passthrough hls option.
If I add the -v option, i see VLC recieves a .m3u8 link. How can I get that link from the API or the CLI without opening VLC?

http://docs.livestreamer.io/cli.html#cmdoption--stream-url

Thanks but how could I pass that to a program. If I was using Livestrreamer for an App how could I pass that url along?


In App Messaging trigger pages condition

Hi team,
We are trying to implement the "In-App Message" function which works but there are some details i want to know.
As we are using Segment, we are sending data through their screen function.
Our Customer account receives the data of Segment including "Page view" event but we are unable to use the "page rules" function on a Customer campaign with this Segment event.
When we sending screen event from Customer SDK the page rules works, i compare the payload of both event and i don't see any differences.
I think the Customer SDK seems to use the screen function to know locally where the user is to show the message ?
We don't to send extra-data to Customer, we all ready sending this data on Segment and we want to keep that way.
It is possible to use Segment event for this ?
Thanks

Hey @MatiasLjubica, thank you for reaching out.
You are correct, currently, in CIO SDKs, when a user sends in a screen event, we use that set current page/route.
What we can do in the next releases is, If you don't want to send this data, what we can do is provide an additional parameter in the screen method, which takes a boolean track, by default it would be true, but if you set the value to false we would just use it to set the route locally and not track the event in CIO.
Note: Everywhere you are sending the Page view via segment, you will have to call the CIO SDK, screen method, but by providing the track as false there won't be any duplication just the local variable to be updated so the in-app routing works for you.

It would be great, thank @Shahroz16

Hi @Shahroz16, it is for fixing this issue ?
commit : https://github.com/customerio/customerio-reactnative/commit/07e38f721acb7a613371c2fc3ac6872c3ea8cb38

Hi @MatiasLjubica,
Thanks for submitting this feedback! I am a Product Manager for the mobile squad here and will be making note of this request to go through backlog prioritization for a future release. I can circle back here with you once this work has been slotted for commitment to pick up!

Hi @StephMoreno. We are also using Segment to send the events to Customer.io and the page rule condition is not working for in-app messaging. We have to manually call CustomerIO.screen method but then we have duplicated events.
Were you able to prioritize this? Thanks!

Hey @Kerumen, thank you for reaching out. We are working on its support and it has been prioritized. Having said that, it's going to take some time before we release it on react native as we are working on its support in other clients too. I'll update here once we do, thanks for your patience.
Meanwhile, maybe just utilize CustomerIO.screen instead of Segment? and forward that data to Segment if needed.?


switched to preact compatability layer

Description
Closes #13
Type of changes made
Please delete options that are not relevant.

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

What changes were made
The main motivation behind this change was to replace React with a more lightweight solution. In previous production builds, the content script would get as big as 302kb, which could negatively affect user performance. Using the Preact compatibility layer, we were able to reduce the content script size to just 193kb! This is a big step in making Tab Butler as small and efficient as possible.

Won't merge this in immediately as more testing needs to be done.


Portable version

OS
Windows
ISSUE DESCRIPTION
Is there any way i can run this app as portable?
Thanks
Great App

v1.7.0 has supported portable, download the zip file


refactor(protocol-designer): remove basename from router

Overview
I guess hash router does not need a basename 🤷🏽  This PR fixes an issue where no route gets picked up by the router due to the route not matching a basename. This only affects sandbox links.
Test Plan and Hands on Testing
Visit https://sandbox.designer.opentrons.com/pd_fix-router and play around with the different routes and try refreshing/copying urls and pasting them into the browser. you should not get a 404.
Risk assessment
Low

sounds good ill merge for now


Fix default command in backend Dockerfile

Since argparse was added

Thanks for surfacing this! Got fixed as part of this commit along with other breaking changes


Add a switch to zip files instead of always zipping...

I want to keep my NoNpDrm dumps as one file. It's easier to manage storage this way. It's also faster to copy it around, instead of sometimes hundreds if not thousands of small files. And it gives you automatic checksums, so you can later detect if file is corrupted. Zip file it creates is not compressed, it uses "store" method, because almost all files are encrypted anyway  so there is no performance penalty of creating zip file - only advantages (performance, checksums, accidentally deleting some files).

yeah, but this way it's the same as the vpk which will take double space when transferring and installing it in PSVita, also each PKG has it's own sha1 checksum so you can check if it's corrupted.
Thx for the tool :)

Why not creat a simply folder of game without zip file ?

@alpakeno You don't need to transfer zip file. Open it up in your favorite archiver program, or even Windows Explorer, and then drag&drop files to connected Vita device. Or if you use command-line - cd to vita drive/mounted folder and execute "unzip path/to/file.zip".
Yes, pkg has checksum, but after it is unpacked, there are not checksum.
@chronoss09 because of reasons I mentioned above.

Ok thanks !

So one question: Does the tool create a zip file out of the pkg or does it extract the files in a folder atm? That‘s not clear to me.
And would it be ok for you (the creator) if i use the shell script to create a Gui Version for macOS? I can share it with you if you want to :)
Thanks in advice for an answer to my questions :)

It creates zip file out of files that are extracted from contents of pkg file. pkg itself doesn't contain zip file, although its structure is very similar to zip files.
How can you use shell script to create GUI? Do you mean TUI?
You can create whatever you want based on my tool, but I'm not sure if I want non-crossplatform code back in my repo...


Additional functionality

Have the node working with my Huawei E5577Cs-321 and have no issues, able to receive details of devices on the router network, works really well. Would it be possible to add additional functionality to include Signal and Status for example? These additional functions (and others that are available with the API) could be selectable in the node to request required data. Unfortunately I am not a coder so unable to help, however can assist on testing and developing the node further.

Please give more info - I decided to only make the API calls i use until some features was requested.
Do you mean able to receive 3G/4G signal strength? And what is "Status" ?
If you could look into the api calls here and tell me. I can try to test if i can get it working :)

Personally I am only looking for signal strength data from the router, the status was only a nice to have. I looked at the "api calls here" and don't see anything relevant. The information I looked at was https://github.com/ishan-marikar/dialog-router-api#readme ,this shows getSignal which is the data I am looking for, hopefully this helps.

Looked into this, Please try version 0.0.5 of this node to see the signal strength node,
It returns an awful long list of data as seen here:
msg.payload = {
  pci: '245',
  sc: '',
  cell_id: '6687312',
  rsrq: '-15dB',
  rsrp: '-75dBm',
  rssi: '>=-51dBm',
  sinr: '5dB',
  rscp: '',
  ecio: '',
  mode: '7',
  ulbandwidth: '20MHz',
  dlbandwidth: '20MHz',
  txpower: 'PPusch:-1dBm PPucch:-12dBm PSrs:17dBm PPrach:-19dBm',
  tdd: '',
  ul_mcs: 'mcsUpCarrier1:22',
  dl_mcs: 'mcsDownCarrier1Code0:19 mcsDownCarrier1Code1:19 ',
  earfcn: 'DL:1300 UL:19300',
  rrc_status: '1',
  rac: '',
  lac: '',
  tac: '2500',
  band: '3',
  nei_cellid: 'No1:280No2:25No3:93',
  plmn: '23801',
  ims: '0'
}

Reading up on this blog here the quality of the signal strength is made from a calculated mix of RSRP, RSRQ and SNIR. I would have a hard time calculating the signal streng exactly like Huawei to it if you dont want the raw value.
How did you expect to receive the signal streng back from this node? A percentage from 100-0%, a varied string like["Excellent", "Good", "Medium", "Weak"], or maybe the raw signal data?
Definitions
RSRP = Reference Signal Received Power.
RSRQ = Reference Signal Received Quality.
SNIR = Signal to Noise plus Interference Ratio.

Have tried version 0.0.5 of the node and the results for me are very positive. On connection the router (HUAWEI E5577Cs-321) returned the following:
pci: "446"
sc: ""
cell_id: "1372487"
rsrq: "-11dB"
rsrp: "-110dBm"
rssi: ""
sinr: "3dB"
rscp: ""
ecio: ""
psatt: "1"
mode: "7"
lte_bandwidth: ""
lte_bandinfo: ""
(above figures taken with router on desk with no external aerial connected)
This looks like a reduced subset of what you received with your router, however the message includes what I require - RSRQ, RSRP and SINR, RSSI is not returned. I checked the router URL with /API/DEVICE/SIGNAL and this confirmed RSSI is not returned from this router.
The raw signal data is preferred, I have created Red-Node Dashboard with 3 gauges configured to RSRQ, RSRP and SINR, I am able to check signal indication from these and adjust to suit. From this I can use chart nodes to monitor the signals ongoing. The gauges use ranges configured as "Stats for HUAWEI LTE Routers" app:
RSRQ -20dBm to -3dBm
RSRP -110dBm to -70dBm
SINR 0dBm to 30dBm
(RSSI -113dBm to -51dBm) for reference
Later I may look at configuring gauge for RSSI using formula.
For information my application is router installed in Motorhome (RV), I have the router installed in a small cupboard within, I have a Poynting 5G/4G directional aerial mounted on a 3m mast at the rear of the Motorhome bike rack, at the bottom of the mast I developed an aerial rotator that communicates through ESP32 device to Red-Node. This enables me to monitor the Huawei app with the "5 bar signal" indicator and move the mast to obtain best signal. This worked reasonably well however the limitation was the feedback from the router app - the "5 bar signal".
I tried the system with your new node and the results are really encouraging, with the RSRQ, RSRP and SINR gauges I can adjust the aerial in small increments to fine tune the signals, initial testing showed gains of -5dBm for RSRP even although the Huawei app continued to show "5 bars" throughout the tests.
Trust the above information is of use, many thanks for taking the time to further develop the node.

Perfect. I'll leave the node as it is now then.
Sounds like a nice setup you got with external antenna. Motorized to autotune to the right angle toward the signal tower. Just love the idea.


docker compose with nginx as front-end does break

I noted that sometimes docker with nginx as front-end breaks, we'll fix this but for now just use the version without front-end compose_debug_env.yaml

Fixed on 66dbe0a


CNN - JAX vs Keras (Channels First vs Last)

Hello JAX Team,
I was recently working on designing a Convolutional Neural Network using JAX higher-level API available through jax.example_libraries.stax.
I noticed that it only supports channels last implementation. When we give channels first, it does not properly perform operations.
I designed the same CNN in Jax and Keras. I noticed that Keras handled Channels First and Channels Last scenario properly.
I have given a link to the Kaggle kernel where I have done a comparison. I noticed that it works the same on CPU and GPU.
CNN - JAX vs Keras (Channels First vs Last)
Please let me know whether I am making any mistake or not setting some parameters in the case of channel first case or it is not supported by Jax.
Regards,
Sunny

Never mind. Sorry but i found solutions by using jax.example_libraries.stax.GeneralConv.
stax.GeneralConv(("NHWC", "HWIO", "NHWC"), 15, (3,3))
stax.GeneralConv(("NCHW", "HWIO", "NCHW"), 15, (3,3))
stax.GeneralConv(("NCHW", "IOHW", "NCHW"), 15, (3,3))


Inline math at arbitrary position in text

Suppose
var text = 25 is $5^2$
and we only want to render 5^2 but we don't know what the text is beforehand. Is this possible?
Mathjax node would render the entire string if we we wrapped it around text.

are you saying you'd like to render the entire text string and inline?
@SamyPesse I'm happy to make an example, I found a way to pull this off with your library.
In fact, you don't even need to use the nodes, only the context is required:
const defaultOptions = {
  showProcessingMessages: false,
  messageStyle: 'none',
  showMathMenu: false,
  tex2jax: {
    processEnvironments: true,
    inlineMath: [['$', '$'], ['\\(', '\\)']],
    displayMath: [['$$', '$$'], ['\\[', '\\]']],
    preview: 'none',
    processEscapes: true
  }
};

class App extends Component {
  render() {
    return (
      <Context options={defaultOptions}>
        <div>
          25 is $5^2$
        </div>
      </Context>
    );
  }
}

here's a pull request to add to the readme so future users can find how to achieve this: https://github.com/SamyPesse/react-mathjax/pull/12

@SamyPesse is there a way to support this original issue? I noticed you have to create all of the inline nodes, when it's not necessary as MathJax with parse text + tex as in this example.
I personally don't want to use the MathJax.Node, I think it's too granular to type for every equation, as it defeats the purpose of writing LaTeX. Is there a way to make something like this MathJax.Context example work?


How to override vboxmanage --type headless

I am trying to run a molecule test using the vagrant driver inside a container using virtualbox installed inside the container.
To do this the vboxmanage startvm command needs to be passed "--type seperate" however it is currently sending "--type headless".
When I run molecule test, how can I override --type headless?
app1_1  |
app1_1  | playbook: playbook.yml
app1_1  | --> Creating instances...
app1_1  | Bringing machine 'default' up with 'virtualbox' provider...
app1_1  | ==> default: Clearing any previously set forwarded ports...
app1_1  | ==> default: Clearing any previously set network interfaces...
app1_1  | ==> default: Preparing network interfaces based on configuration...
app1_1  |     default: Adapter 1: nat
app1_1  | ==> default: Forwarding ports...
app1_1  |     default: 22 (guest) => 2222 (host) (adapter 1)
app1_1  | ==> default: Running 'pre-boot' VM customizations...
app1_1  | ==> default: Booting VM...
app1_1  | There was an error while executing `VBoxManage`, a CLI used by Vagrant
app1_1  | for controlling VirtualBox. The command and stderr is shown below.
app1_1  |
app1_1  | Command: ["startvm", "0ba301c4-c1fa-4c55-ba17-d8f373e44d33", "--type", "headless"]
app1_1  |
app1_1  | Stderr: VBoxManage: error: The virtual machine 'deploy_default_1502838767714_8341' has terminated unexpectedly during startupwith exit code 1 (0x1)
app1_1  | VBoxManage: error: Details: code NS_ERROR_FAILURE (0x80004005), component MachineWrap, interface IMachine
app1_1  | ERROR: Command '['/usr/bin/vagrant', 'up', '--no-provision']' returned non-zero exit status 1

@jamesla please provide the version of molecule you are using.

1.25

Found that it isn't currently supported by vagrant. Closing.


Update main.css

hey @vsiddharth365 i can understand that you want to contribute for hacktoberfest and earn tshirt but i request you to create the issue first and wait till i assign you. once it gets assigned to you , then you can start opening PR .
thank you


Tomcat JDBC support

Codecov Report

Merging #5834 into master will decrease coverage by 0.04%.
The diff coverage is 6.48%.

@@            Coverage Diff             @@
##           master    #5834      +/-   ##
==========================================
- Coverage   40.72%   40.68%   -0.05%
==========================================
  Files        2935     2944       +9
  Lines       88161    88269     +108
  Branches    11591    11603      +12
==========================================
+ Hits        35904    35912       +8
- Misses      49159    49261     +102
+ Partials     3098     3096       -2

Impacted Files
Coverage Δ

...t/jdbc/interceptor/DataSourceCloseInterceptor.java
0% <0%> (ø)

...erceptor/DataSourceCloseConnectionInterceptor.java
0% <0%> (ø)

...npoint/plugin/tomcat/jdbc/TomcatJdbcConstants.java
0% <0%> (ø)

.../interceptor/DataSourceConstructorInterceptor.java
0% <0%> (ø)

...plugin/tomcat/jdbc/TomcatJdbcMetadataProvider.java
0% <0%> (ø)

.../pinpoint/plugin/tomcat/jdbc/TomcatJdbcPlugin.java
0% <0%> (ø)

...nterceptor/DataSourceGetConnectionInterceptor.java
0% <0%> (ø)

...oint/plugin/tomcat/jdbc/JdbcDataSourceMonitor.java
0% <0%> (ø)

.../pinpoint/plugin/tomcat/jdbc/TomcatJdbcConfig.java
100% <100%> (ø)

...p/pinpoint/rpc/client/WriteFailFutureListener.java
56.25% <0%> (-18.75%)
:arrow_down:

... and 19 more

Continue to review full report at Codecov.

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

Codecov Report

Merging #5834 into master will decrease coverage by 0.03%.
The diff coverage is 6.48%.

@@            Coverage Diff             @@
##           master    #5834      +/-   ##
==========================================
- Coverage   40.72%   40.69%   -0.04%
==========================================
  Files        2935     2944       +9
  Lines       88161    88269     +108
  Branches    11591    11603      +12
==========================================
+ Hits        35904    35918      +14
- Misses      49159    49256      +97
+ Partials     3098     3095       -3

Impacted Files
Coverage Δ

...oint/plugin/tomcat/jdbc/JdbcDataSourceMonitor.java
0.00% <0.00%> (ø)

...npoint/plugin/tomcat/jdbc/TomcatJdbcConstants.java
0.00% <0.00%> (ø)

...plugin/tomcat/jdbc/TomcatJdbcMetadataProvider.java
0.00% <0.00%> (ø)

.../pinpoint/plugin/tomcat/jdbc/TomcatJdbcPlugin.java
0.00% <0.00%> (ø)

...erceptor/DataSourceCloseConnectionInterceptor.java
0.00% <0.00%> (ø)

...t/jdbc/interceptor/DataSourceCloseInterceptor.java
0.00% <0.00%> (ø)

.../interceptor/DataSourceConstructorInterceptor.java
0.00% <0.00%> (ø)

...nterceptor/DataSourceGetConnectionInterceptor.java
0.00% <0.00%> (ø)

.../pinpoint/plugin/tomcat/jdbc/TomcatJdbcConfig.java
100.00% <100.00%> (ø)

...vercorp/pinpoint/rpc/packet/ServerClosePacket.java
52.00% <0.00%> (-16.00%)
:arrow_down:

... and 21 more

Continue to review full report at Codecov.

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


Fix predict_proba method of KerasClassifier

KerasClassifier was returning a single probability when n_outputs was 1.
However, scikit requires the predict_proba method to return 2 columns in the case of binary classification.
This is needed for using threshold based evaluation metrics such as roc_auc.
Fixes #2864

Right, thanks


Test faliure on 3.14

See: https://bugzilla.redhat.com/show_bug.cgi?id=2326933
=================================== FAILURES ===================================
____ TestBaseManager.test_can_provide_signal_handler_initializers_to_start _____
self = <tests.unit.test_compat.TestBaseManager testMethod=test_can_provide_signal_handler_initializers_to_start>
@skip_if_windows('os.kill() with SIGINT not supported on Windows')
def test_can_provide_signal_handler_initializers_to_start(self):
    manager = self.create_pid_manager()

  manager.start(signal.signal, (signal.SIGINT, signal.SIG_IGN))

tests/unit/test_compat.py:97:

/usr/lib64/python3.14/multiprocessing/managers.py:565: in start
self._process.start()
/usr/lib64/python3.14/multiprocessing/process.py:121: in start
self._popen = self._Popen(self)
/usr/lib64/python3.14/multiprocessing/context.py:300: in _Popen
return Popen(process_obj)
/usr/lib64/python3.14/multiprocessing/popen_forkserver.py:35: in init
super().init(process_obj)
/usr/lib64/python3.14/multiprocessing/popen_fork.py:20: in init
self._launch(process_obj)
/usr/lib64/python3.14/multiprocessing/popen_forkserver.py:47: in _launch
reduction.dump(process_obj, buf)

obj =
file = <_io.BytesIO object at 0x7f2b60580630>, protocol = None
def dump(obj, file, protocol=None):
    '''Replacement for pickle.dump() using ForkingPickler.'''

  ForkingPickler(file, protocol).dump(obj)

E       _pickle.PicklingError: Can't pickle local object <class 'tests.unit.test_compat.TestBaseManager.create_pid_manager..PIDManager'>
E       when serializing tuple item 0
E       when serializing method reconstructor arguments
E       when serializing method object
E       when serializing dict item '_target'
E       when serializing multiprocessing.context.ForkServerProcess state
E       when serializing multiprocessing.context.ForkServerProcess object
/usr/lib64/python3.14/multiprocessing/reduction.py:60: PicklingError
According to https://docs.python.org/dev/whatsnew/3.14.html#multiprocessing
The default start method (see Contexts and start methods) changed from fork to forkserver on platforms other than macOS & Windows where it was already spawn. If you require the threading incompatible fork start method you must explicitly request it using a context from multiprocessing.get_context() (preferred) or change the default via multiprocessing.set_start_method(). (Contributed by Gregory P. Smith in gh-84559.)

Thanks for the issue @limburgher. The 3.14 alpha is still relatively new (<1 month old). We generally will not start looking at work to resolve compatibility issues until the build is at least in beta. We can keep this to track the issue for later work.

Sounds good. If neither of us have fixed this by the time we start building Fedora with 3.14, I'll just skip that test.


Don't merge! Regression PR perf testing without metadata validation

Docs Build status updates of commit 6d18724:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

TestingPullRequest.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.


Get right of MkDocs Theme ._vars deprecation warning

As discussed in #205, I changed the code to avoid using the deprecated Theme._vars.
I suspect that the case where the theme does not have a locale is dead code because MkDocs seems to always set a locale?
I did not change it because I want to tread carefully. I don't quite understand the logic in Theme as it seems to turn ._vars['locale'] into a Locale object but not self.locale in the case where the constructor argument for locale is None. Perhaps I am holding the wrong end of the stick here but if not then that would seem to be bug.

Ups, I just realized that a) the commit message says "get right" instead of "get rid".

Yep, fine with me.


Take dependency on rai_test_utils for some common model pipelines in tests

Codecov Report
Patch has no changes to coverable lines.

:exclamation: Current head f8476db differs from pull request most recent head 42397bb. Consider uploading reports for the commit 42397bb to get more accurate results

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
:loudspeaker: Thoughts on this report? Let us know!.


any @adminjs/upload example codes?

Hi. I've been using this great project a lot thank you
I have hard time uploading image with @adminjs/upload
Is there any example code that developer like me can start with?

Here is an example for your reference.
https://github.com/SoftwareBrothers/adminjs-upload/blob/master/example-app/src/index.ts


Add OLAP in YQL tutors, PSQL, quick start

Changelog category

Documentation (changelog entry is not required)

@Pseudolukian there're a lot of conflicts that need to be resolved

Rebase: https://github.com/ydb-platform/ydb/pull/9672


Discovering nearby users

Prerequisites

[X] I checked the documentation and FAQ without finding a solution
[X] I checked to make sure that this issue has not already been filed
[X] I'm sure that question is related to the library itself and not Bluetooth Low Energy or Classic in general. If that so, please post your question on StackOverflow.
[X] I'm running the latest version

Question
Hi, I am stuck at my MVP process. Can this library be used to detect nearby users/devices that are running the same application?
For example, device A sees device B and vice-versa? Or does the Android/iOS have rolling bluetooth identifier that cannot be tied to a specific device for identification?
Question related code
No response

Hi @intent-kacper-cyranowski,
thanks for the info.
Creating a library react-native-discovery inspired by an older lib which has not been maintained.


'open_mfdataset' zarr zip timestamp issue

What happened?
We have been collecting Satellite data and we save each image as one {time}.zarr.zip file.
We then collate the images using xr.open_mfdataset and same them to large.zarr.zip file.
When loading this file the timestamps are all the same.
This bug did not appear in 2022.3.0 but it did in 2022.6.0
I tried to keep this as minimum as possible, but its a bit of a long example. Hopefully the comments help.
Sorry if this has already been reported, but I could not find it in the issue list
What did you expect to happen?
Expected the time stamps to reflect the data that went in
Minimal Complete Verifiable Example
import pandas as pd
import xarray as xr
import numpy as np
from datetime import datetime, timedelta
import zarr
import os
import glob

# ids and times
path = "tmp.zarr.zip"
ids = np.array(range(0, 10))
times = [datetime(2022, 9, 1) + timedelta(minutes=60 * i) for i in range(0, 10)]

# make 10 random zipp files
for time in times:
    dataset = xr.DataArray(
        np.random.uniform(size=(1, len(ids))),
        coords=(("time", [time]), ("id", ids)),
        name="data",
    ).to_dataset(name="data")

    file_name = f"tmp_dir/{time.isoformat()}.zarr.zip"

    if os.path.exists(file_name):
        os.remove(file_name)
    with zarr.ZipStore(file_name) as store:
        dataset.to_zarr(store)

# load them all together
files = list(glob.glob(f"tmp_dir/*.zarr.zip"))
dataset = xr.open_mfdataset(files, engine="zarr").sortby("time")

# this is fine!
assert pd.to_datetime(dataset.time.values[0]) == times[0]
assert pd.to_datetime(dataset.time.values[1]) == times[1]

# save to file
if os.path.exists(path):
    os.remove(path)
with zarr.ZipStore(path) as store:
    dataset.to_zarr(store)

# read the file
dataset_read = xr.open_dataset(path, engine="zarr")
print(dataset_read)

# this casues an error
assert pd.to_datetime(dataset_read.time.values[0]) == times[0]
assert pd.to_datetime(dataset_read.time.values[1]) == times[1]

MVCE confirmation

[X] Minimal example — the example is as focused as reasonably possible to demonstrate the underlying issue in xarray.
[X] Complete example — the example is self-contained, including all data and the text of any traceback.
[X] Verifiable example — the example copy & pastes into an IPython prompt or Binder notebook, returning the result.
[X] New issue — a search of GitHub Issues suggests this is not a duplicate.

Relevant log output
/Users/peterdudfield/Documents/Github/nwp/venv/lib/python3.8/site-packages/xarray/core/dataset.py:2060: SerializationWarning: saving variable None with floating point data as an integer dtype without any _FillValue to use for NaNs
  return to_zarr(  # type: ignore
<xarray.Dataset>
Dimensions:  (time: 10, id: 10)
Coordinates:
  * id       (id) int64 0 1 2 3 4 5 6 7 8 9
  * time     (time) datetime64[ns] 2022-09-01 2022-09-01 ... 2022-09-01
Data variables:
    data     (time, id) float64 ...
Traceback (most recent call last):
  File "/Users/peterdudfield/Documents/Github/nwp/venv/lib/python3.8/site-packages/IPython/core/interactiveshell.py", line 3251, in run_code
    exec(code_obj, self.user_global_ns, self.user_ns)
  File "<ipython-input-16-45f86e8a5977>", line 36, in <module>
    assert pd.to_datetime(dataset_read.time.values[1]) == times[1]
AssertionError

Anything else we need to know?

Yea the same bug appeared. So this appears at 2022.6.0 and onwards.

I took a minute to look into this and think I understand what is going on. First, a little debugging:
for name in [files[0], files[1], path]:
    print(name)
    ds = xr.open_zarr(name, decode_cf=False)
    print('  > time.attrs', ds.time.attrs)
    print('  > time.encoding', ds.time.encoding)

tmp_dir/2022-09-01T03:00:00.zarr.zip
  > time.attrs {'calendar': 'proleptic_gregorian', 'units': 'days since 2022-09-01 03:00:00'}
  > time.encoding {'chunks': (1,), 'preferred_chunks': {'time': 1}, 'compressor': Blosc(cname='lz4', clevel=5, shuffle=SHUFFLE, blocksize=0), 'filters': None, 'dtype': dtype('int64')}
tmp_dir/2022-09-01T04:00:00.zarr.zip
  > time.attrs {'calendar': 'proleptic_gregorian', 'units': 'days since 2022-09-01 04:00:00'}
  > time.encoding {'chunks': (1,), 'preferred_chunks': {'time': 1}, 'compressor': Blosc(cname='lz4', clevel=5, shuffle=SHUFFLE, blocksize=0), 'filters': None, 'dtype': dtype('int64')}
tmp.zarr.zip
  > time.attrs {'calendar': 'proleptic_gregorian', 'units': 'days since 2022-09-01'}
  > time.encoding {'chunks': (1,), 'preferred_chunks': {'time': 1}, 'compressor': Blosc(cname='lz4', clevel=5, shuffle=SHUFFLE, blocksize=0), 'filters': None, 'dtype': dtype('int64')}

A few things that I noticed:

the dtype of the time variable is int64.
the units attr is days since ....

open_mfdataset tends to take the units of the first file and doesn't check if all the others agree. It also does not clear out the dtype encoding.
One quick solution here is that you could add
del dataset['time'].encoding['units']

to the line right after your open_mfdataset call. You could also update the dtype of your time variable to be a float64.

After thinking about this for a bit longer, I think we should be strongly considering dropping source encoding for datasets generated by open_mfdataset. Or, if nothing else, thinking about ways to alert the user that encoding was not consistent across all of the datasets loaded.
Other relevant issues:

https://github.com/pydata/xarray/issues/1614
https://github.com/pydata/xarray/issues/7039

Thanks @jhamman for looking into this. I'll try your suggestions


Add Drum Kit

Issue Type:
[ ] Feature Request
Describe the bug

I would like to add a Drum Kit project made using HTML, CSS and Javascript that would play sounds on keypresses as well as clicks.

Please assign me this issue.

go ahead @ri-tae-ka

@ri-tae-ka do not download or copy paste code from anywhere .
write your own code please

@ri-tae-ka you want to work on it ?

I have already completed the task.
Sorry I got confused if I needed to close the issue or it is the maintainer that should close the issue.

ok no problem @ri-tae-ka


RFC: unify all developer CLI tools

We have accumulated a lot of dev automation tools, and our homegrown runtests.py CLI which is slightly clumsy. Here is an overview:

runtests.py - and its sibling dev.py for Meson
doc/Makefile - build docs and upload them
pavement.py - uses Paver for some release tasks
tox.ini - contains flake8 and pycodestyle config, we don't use Tox itself anymore
tools/authors.py / tools/gh_lists.py / tools/download-wheels.py release scripts
tasks for which we have no CLI, just docs that we hope people read before doing the thing they need:

dev environment setup - apt-get xxx && pip install yyy or conda env create -n environment.yml
git - for a lot of things, but with submodules it is getting less intuitive
docker - for Gitpod config, see tools/docker_dev
act - for running GitHub Actions jobs locally

Many of these things are badly maintained or only half in use. runtests.py has been the best maintained so far, but it's not ideal because task dependencies are manually dealt with in if args.some_task: ... logic.
Proposal: let's create a new and more ergonomic CLI for all development tools.
Ideally it has these properties:

Completeness: we have all normal/recurring development tasks implemented in it
Conciseness: (for example) do bench instead of python runtests.py --bench
Self-documenting: it should be easy to read the CLI implementation and figure out what actual commands are being run (or maybe the CLI can print the command)
Hierarchical: if there are a number of docs-related tasks, they should be discoverable and runnable like: do doc build, do doc show, do doc upload, etc. Same for CI and release tasks; top-level tasks should be for regular contributions/development
Genericity: it should make as few assumptions as possible (e.g., don't assume you're developing in a virtualenv), it should be implemented in a way where the non-SciPy-specific parts can be reused in other projects that use pytest/asv/meson/sphinx, and it should work in harmony with the tools it wraps so one can use those directly

There will be tools where it doesn't make sense to wrap them (e.g., gh) however it would be great if those tools could be made discoverable as well so it doesn't take new contributors years to find out about all of them.
I don't have a proposal (yet) for which framework or task runner to use. There are many. It looks like we need a straightforward task runner that understands dependencies between tasks and makes it easy to implement a CLI. Something like:

Airflow
Celery
doit
Invoke

Ones that I know of but aren't good choices: Paver (obsolete), Fabric (superceded by Invoke), Luigi (superceded by Airflow), Tox/Nox (they insist on environment activation/updates for every task).
Airflow is on the complicated (but powerful) side, doit is on the simple side. I don't have a lot of experience with any of these tools, so don't have a good sense for the features vs. simplicity tradeoff or other pros/cons. Suggestions very welcome.

There's also stuff like openblas_support.py and refguide_check.py. I'm not taking any particular side, but a detailed discussion might also consider the merits of avoiding "mega-tools" in favor of Unix Philosopy:

Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features".

If say the NumPy and SciPy core teams can both be convinced that something like this is needed, that might help establish confidence that we're not building our own little magical thing. If both projects were to be convinced, where might the tool reside?

For completeness, in the list we can add

Click
Typer

And what about an unpopular option, make? BUT, it must be simple without wizardry.
Otherwise doit is the new cool kid in town and looks indeed cool. If we make it simple, it could also be plugged with Gooey to make a GUI.
No matter the solution we select, I think it's important we keep it simple so that we use and update it. If you need to sit down and dig into it to make some adjustment, it will likely not happen.

(side question - what's the invocation for running the lint check locally?)

python tools/lint_diff.py. Accepts --files scipy/optimize/test_linprog.py etc..

If say the NumPy and SciPy core teams can both be convinced that something like this is needed, that might help establish confidence that we're not building our own little magical thing. If both projects were to be convinced, where might the tool reside?

If there's a generic part, it could live under the numpy or scipy org, doesn't really matter to me. That may be minor though, I'm not sure how separable it is into its own repo (my guess is it won't be). It's more a pattern that can be synced. But well, TBD.

I'm not taking any particular side, but a detailed discussion might also consider the merits of avoiding "mega-tools" in favor of Unix Philosopy:

I don't think it'll be a mega-tool, we won't get rid of (e.g.) refguide_check.py or authors.py. We just make it more discoverable and with a uniform interface. This is a real problem - most maintainers can't even keep track of all the scripts and tools we have, and contributors have no chance at all to find it all.

For completeness, in the list we can add Click, Typer

Interesting question. From what I can tell these are kind of different (more like "argparse on steroids" than "a modern make"). I'm thinking the task runner is the more important part, but having a polished CLI will be quite nice as well. I also just saw the announcement of rich-cli, which is in the same bucket as Click and Typer it looks like, and rich is wildly popular right now (it's even in pip 22.0).

And what about an unpopular option, make?

Can I just say "no" without further comment?

No matter the solution we select, I think it's important we keep it simple so that we use and update it. If you need to sit down and dig into it to make some adjustment, it will likely not happen.

Agreed.
I wanted to get some initial feedback, and the questions helped trigger some ideas. Maybe the next step is to build a small prototype to get a better sense for how much room for improvement there is.

Interesting question. From what I can tell these are kind of different (more like "argparse on steroids" than "a modern make"). I'm thinking the task runner is the more important part, but having a polished CLI will be quite nice as well. I also just saw the announcement of rich-cli, which is in the same bucket as Click and Typer it looks like, and rich is wildly popular right now (it's even in pip 22.0).

Seeing rich-cli now! Looks nice.

And what about an unpopular option, make?

Can I just say "no" without further comment?

😅 sure, I trust your judgment.

I wanted to get some initial feedback, and the questions helped trigger some ideas. Maybe the next step is to build a small prototype to get a better sense for how much room for improvement there is.

Once we have a requirement list, I could help with that if wanted. I think that would be on scope with what I could do.

Given SciPy is committing to Meson + ninja, any unpopular make option should realistically be automatically superseded in favor of ninja, which is essentially "make except no pattern rules, use a ninja generator".
Specifically, you could create meson.build run_target()s or alias_target()s for each tool tied to convenient target names instead of script file paths.
It does of course support depending on built targets (and other run_targets), but the discoverability of targets would be hindered by tab completion of ninja listing tons of buildable files in among the handful of tool names. I guess you could add another tool called ninja help -> ./tools/help.py to print some kind of guidance. Although that may be trying too hard to shoehorn ninja into working.
Anyway, make has a superset of the reasons why ninja might not be strictly appealing, on top of requiring both make and ninja which feels... bizarre.

I am in favor of such CLI but I think much of the mystery comes from the undocumented "clever" code. Otherwise we can always pick a DAG and be done with it. But the clever code has so many "refactored" pieces that doesn't make any sense to a person who is coming in with fresh gray-matter. Hence I agree with all points but "Genericity" and I'd say let others shoot their own feet. I think much of the clever code is a result of that grand but unrealistic goal making the code way too abstract than necessary.
And please let make and if possible cmake die, it is long overdue. Seemingly nobody is compiling this many wild pieces into one wheel on every possible architecture thus contrary to whatever some die-hard proponent might say, I am willing to die on that hill.

@eli-schwartz - just checking I didn't miss anything - but am I right in saying that using run_target or alias_target will mean that we end up typing something like:
meson compile refguide_check

or similar?

Many of these things are badly maintained or only half in use. runtests.py has been the best maintained so far, but it's not ideal because task dependencies are manually dealt with in if args.some_task: ... logic.

I'd be willing to bet that the overwhelming majority of interactions with scripts will be people wanting to:

build scipy, so python dev.py --build-only (or historically pip install .)
use runtests.py to run tests.

If this thesis is true, then the majority of our time should be getting the functionality in runtests.py/dev.py to be smooth sailing. In addition, if the majority of time is spent using a single script then it may not justify a big do-it-all tool.
The other tools are mainly used by devs, and cleaning those tools up may not give as much a return as one would suppose.
However, these points fade into the background if someone wants to spend time creating the replacement tooling.

@matthew-brett
Yes.

I'm looking at rich-cli, and it doesn't look like a fancy argparser; more like a highlighter of sorts?
Here's another one: https://github.com/google/python-fire

Here's another one: google/python-fire

For various reasons, I would not build any long term project based on any GG technology 😅

I've always found the Rust community cargo tool to be pretty ergonomic. From uploading packages/releases to compiling, linting, building docs, running (doc) tests, etc.
A single abstracted tool with its own thorough maintenance and documentation is probably bigger than our scope, though some aspects of the design may merit emulation.

Just tried $ python do.py doc. Works great!
A minor gripe is that it ends with
dumping object inventory... done
build succeeded.

The HTML pages are in build/html-scipyorg.

Build finished. The HTML pages are in build/html-scipyorg.

and it took me a while to figure out it's not scipy/build (that's meson/ninja stuff) but scipy/doc/build. The path relative to doc/ was natural in the previous workflow, which has cd doc && make html-scipyorg, but I'd rather not even remember that that even existed :-).

A minor gripe is that it ends with

I'll get rid of that last line in the Makefile, it's duplicate anyway. The lines above it come from Sphinx, so we can't remove them. Instead, we should end with a new message. @schettino72 I'm trying to add it, but I'm not sure how - the pydoit docs on delayed task creation don't show how to add a message to this doc build command after it is done:
    def task_meta(...):
        ...
        return {
            'actions': [
                # move to doc/ so local scipy does not get imported
                (f'cd doc; env PYTHONPATH="{dirs.site}" '
                 f'make {" ".join(make_params)} {targets}'),
            ],
            'task_dep': task_dep,
            'io': {'capture': False},
        }

Is it possible to append a message?

Ah, easy enough - thanks!

I found this thread as a first-time contributor, who struggles with the fact that the developer docs recommend to run python dev.py lint but this command does not do the same as python tools/lint_diff.py. Wouldn't it be useful for first-timers if the two should do the same?
Besides, python dev.py lint takes a good while to run and shows stuff unrelated to me.

It would also be more developer-friendly if python dev.py test would forward all arguments to pytest. I missing -k from pytest and --pdb in particular.
python dev.py test -t scipy.stats.tests.test_multivariate::TestConditionalTable
is quite a mouthful to write compared to (theoretically) python dev.py test -k TestConditionalTable

Excellent, thank you for the hint. Now that I look at the docus for dev.py test, I see that this was actually documented and I just missed it. Sorry for the noise! 🤦

I think it would be nice to have something like $ python dev.py lint -b main to run $ python tools/lint_diff --branch main.
As a data point, I was just earlier today looking into the azure yml file to find out the CI linting invocation.

On the linting part, at the risk of repeating myself, I really think it would be better to rely on pre-commit hooks so we don't have to care anymore. We keep circling around the matter and saying it's not worth it since we don't have styling discussions, but it seems like we do and it does take more maintenance time than it should.

I've started working on a tool that generalizes dev.py across projects. It's not as fancy as SciPy's version, but it is configurable, and does the basic build, install, shell, etc. Next step is to add custom scripts, and once that's ready any project will be able to customize it fully.
However, after writing this first version, I've come to the same conclusion as @andyfaff: the tool is not really necessary once we get Meson to do in-place developer wheels. Once we can do that, workflows can be standardized across projects:
developer install: pip install -e .
wheel install: pip install . --no-build-isolation
testing: pytest --pyargs modulename
But, this really does require implementing the Meson-built developer wheels (as I discussed with @eli-schwartz), because developers depend on in-place installations for fast edit-test cycles. FWIW, while the current SciPy approach (setting the PYTHONPATH) is workable for most of us, those who use Advanced(TM) IDEs struggle, since the IDEs expect the build product to live alongside the code. I'm not 100% sure whether the developer wheels will address that, although it might.
(With "developer wheels" I mean: build into a target directory by symlinking all unmodified files, and adding in compiled products.)

After having been forced to use pre-commit in a few other projects recently, I now have an opinion: it's a really bad experience. It typically doesn't work out of the box, it doesn't work with conda-forge at all, and it tends to point at lots of forks of tools of random individuals I don't know (but have to trust). If folks who like it want to add pre-commit to make their lives easier, sure. But to require it seems like a nonstarter.

I was surprised to read this! My experience has been quite the opposite: install the hook, commit twice (since code gets reformatted on the first commit), and forget about it. Compare that to the experience of working on SciPy: commit, wait for CI to fail, commit again, etc.
Either way, I don't think we have to force anyone to use it. As long as we use pre-commit to do the CI run, those who like it can run it locally, and the rest can use the CI to check their code the way it currently does.
A recommendation by @jarrodmillman that I like: only use linting tools that can auto-fix. Otherwise, it becomes a frustrating contributing experience (where you have to work hard to satisfy the linter, instead of the linter helping you).

ISTM there are two separate discussions here, as long as using these hooks is optional (and I'm rather strongly into them being optional):

evangelizing (is that a word?) their use --- sounds like a blog post with instructions would be a helpful first step
how to simplify and streamline user experience for those who are not using them. In that vein, a command-line improvement to ti fix the "wait for the CI to fail" part of https://github.com/scipy/scipy/issues/15489#issuecomment-1281170323 would be helpful.

My 2c

* evangelizing (is that a word?) their use --- sounds like a blog post with instructions would be a helpful first step

I'm not sure how much there is to communicate here.
pip install pre-commit
pre-commit install  # do this once

Then just continue to develop as usual. When you commit, some checks will be done. If they fail, formatting fixes will be made to your code, and you commit the resulting files.

Oh, forgot to mention, the simple generalized version of dev.py is at https://github.com/scientific-python/dev.py.  It's very alpha, but feel free to check it out.  I'll probably implement external hooks today.

It typically doesn't work out of the box, it doesn't work with conda-forge at all

Do you refer to having to install the hooks? Or that the hooks install in their own venv? I don't see how that's a problem.

No, literally what I said: despite multiple tries, I did not get it to work at all, after following both project instructions and the pre-commit docs. So I'm back to debug by CI, except projects using pre-commit also have the annoying habit of turning on a ton of very picky checkers, so things like not alphabetically ordering imports or using double instead of string quotes is now an unnecessary CI error.
I think the problem was that a venv need a base interpreter, and it doesn't work well if the only Python available is an unusual one (to pre-commit) like a conda-installed one.

However, after writing this first version, I've come to the same conclusion as @andyfaff: the tool is not really necessary once we get Meson to do in-place developer wheels. Once we can do that, workflows can be standardized across projects:

I'm not sure I agree. Part of the problem the CLI is addressing is that everything is discoverable. It's one interface, rather than 10+. If you go back to everyone needing to know pytest, asv, mypy, sphinx, linters, and a bunch of one-off scripts - that's not a good thing.
Not every project is as complex as SciPy and needs as many things, but we have enough evidence that even maintainers don't know all the interfaces needed in the old way of doing things.

Not every project is as complex as SciPy and needs as many things, but we have enough evidence that even maintainers don't know all the interfaces needed in the old way of doing things.

Well, here's a first attempt at a generic solution then: https://github.com/scientific-python/dev.py
(I finished implementing custom hooks.)
Take a look and let me know what you think. It's not as full-featured as the SciPy one, but hopefully a simple, clean, generalizable start for other projects to adapt.  I've used it to build and test scikit-image, and It Works (TM).
The built-in build commands only work for Meson-based projects ATM (but, of course, a project can write their own hooks that use setuptools instead).

BTW I tend to agree with @rgommers about pre-commit being annoying and painful to deal with, from a slightly different perspective.
I don't love tools that try to create even more venvs for me, when I have perfectly good versions of these tools available in a managed system python that keeps very much up to date for me, and even does something that PyPI cannot do, and in fact basically removed support for, which is codesigning (no, having the PyPI website itself generate error-detecting checksums is not the same as codesigning; PyPI never really offered codesigning as a first-class feature, but it used to display PGP signatures, and that got removed since "only distros use it". Meanwhile, we are at 9 years and counting for PEP 458 deployment, which only covers the minimum security model, securing software immediately after upload to PyPI -- end to end security is still a draft PEP). And people who use pre-commit tend to use tons of projects I've never heard of, by people I've never heard of, which I would rather not use unless I've put in much more effort than it is worth to investigate the trustworthiness of running these peoples' software. I can't get the software from my distro that I do trust, and, half the time (I'm sure conda has the same problem) I cannot even check if people I trust do in turn trust said project.
So actually I don't use pre-commit, but just wait for CI to fail. Then pre-commit running in the cloud decides to append to my PR, messing up my clean commit history with "fixup" commits that don't survive local iteration. :D
What it amounts to, then, is yet another way to run a linter in CI, then apply recommendations locally. But this particular way of running a linter in CI is... really noisy. In the sense that there are repositories where there are weekly or more commits that just update the pre-commit configuration, usually submitted by bots, and, sometimes, that means a project which seems to be regularly committed to, until you realize that every commit for the past 4 months is just pre-commit configuration commits.
This makes me feel like pre-commit is just a bad idea, implemented inelegantly, and my opinion on the service as a whole just tanked.
You don't even need it. It's reasonably trivial to implement a git-pre-commit hook that simply runs a command such as python dev.py .... My private implementation doesn't mess with the current working directory (staging and hopefully restoring uncommitted changes), which, while implemented badly, is the only interesting feature I see in pre-commit.
...
Contrast that to "just install the latest version of flake8, pylint, and mypy in CI, and twice a year fix the failing CI when a new version of the linter learns to complain about something new by default". In practice, at least for meson, that only really tends to happen with mypy.
I have once or twice pondered trying to do for our linter runs, what we do for OS tests. Which is to have a dedicated workflow that runs once a week, tries to build fresh docker containers with updated OS runtimes, and the latest versions of various dependencies, run the testsuite in those docker containers, and then if everything passes, upload the fresh docker container to the docker hub. These images are then used to run Pull Request CI using the latest versions of all dependencies that definitely passed CI on git master. If the images fail to build, this might be a temporary failure or indicate something is actually broken/incompatible with newer versions of $WHATEVER, and that can be investigated at leisure without interrupting normal development.
Hooking something like that up for the linter runs never really felt worth it for me because of the low risk of regressions, but of course YMMV. I do think if you DO want pinned linters, the approach as a whole is significantly more pleasant than dealing with that noise in constantly drip-fed micro updates to the main repo. You literally don't have to do ANYTHING, and you automatically get the advantage of being able to test PRs using the latest version of the linter that also cleanly passes on git master.

Meanwhile, we are at 9 years and counting for PEP 458 deployment, which only covers the minimum security model, securing software immediately after upload to PyPI -- end to end security is still a draft PEP).

Security in the Python ecosystem is a major concern.

So actually I don't use pre-commit, but just wait for CI to fail. Then pre-commit running in the cloud decides to append to my PR, messing up my clean commit history with "fixup" commits that don't survive local iteration. :D

I don't think tools should be making commits on your behalf, ever!

What it amounts to, then, is yet another way to run a linter in CI, then apply recommendations locally.

The idea, really, is the other way around: to be able to run whatever is run on CI locally.  You don't need pre-commit to do that, dev.py or whatever other avenue you choose would be fine. Having it as a pre-commit hook is very convenient, though.

But this particular way of running a linter in CI is... really noisy. In the sense that there are repositories where there are weekly or more commits that just update the pre-commit configuration, usually submitted by bots
...
This makes me feel like pre-commit is just a bad idea, implemented inelegantly, and my opinion on the service as a whole just tanked.

I agree that regularly updating linter configs is a dumb idea, and we shouldn't do that! But I also don't think we should blame the tool for the crazy things people do.

Contrast that to "just install the latest version of flake8, pylint, and mypy in CI, and twice a year fix the failing CI when a new version of the linter learns to complain about something new by default". In practice, at least for meson, that only really tends to happen with mypy.

This is exactly what pre-commit automates. And I don't see how your security concern is addressed by this method: you're installing the same software as pre-commit would into an isolated environment, except into your default development environment?

I have once or twice pondered trying to do for our linter runs, what we do for OS tests. Which is to have a dedicated workflow that runs once a week, tries to build fresh docker containers with updated OS runtimes, and the latest versions of various dependencies, run the testsuite in those docker containers, and then if everything passes, upload the fresh docker container to the docker hub. These images are then used to run Pull Request CI using the latest versions of all dependencies that definitely passed CI on git master. If the images fail to build, this might be a temporary failure or indicate something is actually broken/incompatible with newer versions of $WHATEVER, and that can be investigated at leisure without interrupting normal development.

I'm curious whether you've tried https://github.com/nektos/act.  I wish we could run Windows images on Linux; that would really help things along!
This tmate action is the best alternative I've found so far.
FWIW, re: the pre-commit comments, my gentle pushback is just that—some points to think about. I am not too invested in changing the linting system, but would like to see an easy way to get python runtests.py --pep8 --mypy—applied only to the diff—into a pre-commit hook. Maybe that option already exists?

I agree that regularly updating linter configs is a dumb idea, and we shouldn't do that! But I also don't think we should blame the tool for the crazy things people do.

Well, but pre-commit's design is that the version tag to use is inherently part of the per-linter config.
And also, the same Github App (https://pre-commit.ci) that checks out your repo and runs pre-commit in order to submit CI statuses, also submits those (weekly) PRs to update the linter config.
The only options it seems to offer are whether you want to get those PRs weekly, monthly, or quarterly. Setting the target branch to empty doesn't mean disable the auto-update, it means target the default branch.
So IMHO it's impossible to use it sensibly unless you only use it locally. But the point is to run the same thing locally as well as in CI... might as well investigate allowing dev.py to run as a git-pre-commit hook instead.

This is exactly what pre-commit automates. And I don't see how your security concern is addressed by this method: you're installing the same software as pre-commit would into an isolated environment, except into your default development environment?

Yes, but importantly, I can opt into making that default development environment use a package manager such as apt, pacman, rpm, or conda, which have solved the supply chain security issue and which I already trust for the vast majority of the software on my system. So I know that the connection between me and PyPI the Linux distro repository was not intercepted by malware, and that's a whole class of worries I just... don't even need to think about.

I am not too invested in changing the linting system, but would like to see an easy way to get python runtests.py --pep8 --mypy—applied only to the diff—into a pre-commit hook. Maybe that option already exists?

This fairly Meson-specific script in .git/hooks/pre-commit might serve as inspiration for the general approach:
#!/bin/bash

mapfile -d '' changed < <(git diff --cached --name-only -z --diff-filter=ACM mesonbuild/'*.py')

# create a temporary copy of what would get committed, without unstaged modifications
workdir=$GIT_DIR/.pre-commit-workdir
fakecommit=$(git commit-tree -p HEAD $(git write-tree) -m ...)

if ! [[ -d $workdir ]]; then
    git clone -qns "$GIT_DIR" "$workdir" || exit
fi

unset "${!GIT_@}"
cd "$workdir"
git checkout -q $fakecommit

# run a couple of repo-specific lints; if any of them fail, remember that, and set an overall hook failure status
ret=0

flake8 "${changed[@]}" || ret=1
pylint "${changed[@]}" || ret=1
./run_mypy.py "${changed[@]}" || ret=1

exit $ret

Because I wrote this to run linters only, it's a safe assumption that I don't need cached state such as configured build directories. In theory, some people do run build+test cycles in their pre-commit hooks, personally I do not see such value for that.

I'm curious whether you've tried https://github.com/nektos/act. I wish we could run Windows images on Linux; that would really help things along!
This tmate action is the best alternative I've found so far.

I tried it once or twice, it's pretty cool. But I'm also very fond of https://man.sr.ht/builds.sr.ht/ -- which automatically exposes any failing build via ssh, limited to the actor. It doesn't provide Windows images either, though.

FWIW, re: the pre-commit comments, my gentle pushback is just that—some points to think about. I am not too invested in changing the linting system, but would like to see an easy way to get python runtests.py --pep8 --mypy—applied only to the diff—into a pre-commit hook. Maybe that option already exists?

flake8 --diff exists, but it is deprecated and slated for removal, because it doesn't detect new lint issues that are triggered by the diff, but appear elsewhere in the file. It's probably not required unless you're incrementally fixing a codebase -- running on all files produces correct results, and running only on modified files produces correct results faster.

EDIT: I thought the answer might be python dev.py lint, which says ":dash: run flake8, and check PEP 8 compliance on branch diff", but when I run it on a checked out main branch, it still returns a bunch of errors (and unfortunately also does not auto-fix anything).

Not all linters can auto-format a fix, IIRC flake8 has rejected suggestions to implement such a thing because it's too complex to get correct.

Well, but pre-commit's design is that the version tag to use is inherently part of the per-linter config.

I think there's some confusion here between the Github app (which I haven't seen used in any of our projects) and the tool (https://pre-commit.com/).

Yes, but importantly, I can opt into making that default development environment use a package manager such as apt, pacman, rpm, or conda, which have solved the supply chain security issue and which I already trust for the vast majority of the software on my system. So I know that the connection between me and ~PyPI~ the Linux distro repository was not intercepted by malware, and that's a whole class of worries I just... don't even need to think about.

This could be a good feature to add to pre-commit: see if the current environment satisfies the required dependencies, and fail otherwise.

This fairly Meson-specific script in .git/hooks/pre-commit might serve as inspiration for the general approach:

:pray:

flake8 --diff exists, but it is deprecated and slated for removal, because it doesn't detect new lint issues that are triggered by the diff, but appear elsewhere in the file. It's probably not required unless you're incrementally fixing a codebase -- running on all files produces correct results, and running only on modified files produces correct results faster.

For SciPy, the time to run on the total repo is unfortunately non-trivial:
python dev.py lint  71.94s user 0.97s system 968% cpu 7.526 total

Thanks @eli-schwartz, I got it working for SciPy!
#!/bin/bash

mapfile -d '' changed < <(git diff --cached --name-only -z --diff-filter=ACM -- '*.py')

# create a temporary copy of what would get committed, without unstaged modifications
GIT_DIR=${GIT_DIR:-.git}
workdir=$GIT_DIR/.pre-commit-workdir
fakecommit=$(git commit-tree -p HEAD $(git write-tree) -m ...)

if ! [[ -d $workdir ]]; then
    echo $workdir
    git clone -qns "$GIT_DIR" "$workdir" || exit
fi

unset "${!GIT_@}"
cd "$workdir"
git checkout -q $fakecommit

# run a couple of repo-specific lints; if any of them fail, remember that, and set an overall hook failure status
ret=0

echo -e "** pre-commit linter **\n"
flake8 --config=tools/lint_diff.ini "${changed[@]}" || ret=1

if [[ $ret -ne 0 ]]; then
    echo -e "\n!! Linting failed; please make fixes, \`git add\` files, and re-commit."
fi
exit $ret

It runs on any file touched (not just the diff on those files).
To install as a pre-commit hook:
ln -s $PWD/pre-commit.sh .git/hooks/pre-commit

python dev.py lintshould also runflake8`, but for the PEP8 part should be the same. Can you point to a branch where you see one failing but the other passing?

Sorry, I don't have a clean reproducer, but I think this patch here
https://github.com/scipy/scipy/pull/17237/commits/0545e5e0c3e6601e584e3afda88a8df0cec74795
was a change that I made after python dev.py lint gave me no complains (about my new code), but python tools/lint_diff.py run by the CI job found those issues. I haven't looked into the implementation, but these two commands apparently do not apply the same rules.

I am inclined to close this issue, since the initial RFC was accepted and fully implemented. We now have at least two new discussions going on, one about a change needed in dev.py lint and one about git hooks / pre-commit. Unless there are objections, I'm going to move those things to two new separate issues.

I am inclined to close this issue, since the initial RFC was accepted and fully implemented. We now have at least two new discussions going on, one about a change needed in dev.py lint and one about git hooks / pre-commit. Unless there are objections, I'm going to move those things to two new separate issues.

Makes sense, thanks!

Okay that took me a while - I will close this issue now. I opened gh-17434 to follow up on the potential issue with lint. I'm not opening a new issue for pre-commit, because there's too much back and forth there that I don't know how to summarize (or if there's anything in particular that is actionable). If that does need follow-up, it would be great if someone can take that action.
After re-reading the recent comments to be able to open a new issue, I did want to expand on the below comments. Also because I saw scikit-learn devs just make the same wrong assumption / misconception of what this CLI is about - and it's fairly core to the whole point of writing the CLI in the first place:

However, after writing this first version, I've come to the same conclusion as @andyfaff: the tool is not really necessary once we get Meson to do in-place developer wheels. Once we can do that, workflows can be standardized across projects:

I'm not sure I agree. Part of the problem the CLI is addressing is that everything is discoverable. It's one interface, rather than 10+. If you go back to everyone needing to know pytest, asv, mypy, sphinx, linters, and a bunch of one-off scripts - that's not a good thing.

It is extremely helpful for all commands, and the options they each take, to be in a single place and self-documenting with --help. I know I still cannot remember all the obscure invocations one only occasionally does, like getting the durations of slowest tests or building with gcov or Asan. So I'm fairly sure most contributors don't know either - and often won't even realize such things are possible. Therefore:

The CLI exposes those things (and in a better way than a ton of outdated html docs do), and
It shows the commands that it wraps, so that it actually teaches folks the CLIs of the underlying tools as they go, rather than obscuring them. That way they can dig in further if and when they are ready:

$ python dev.py build
💻  meson setup /home/rgommers/code/scipy/build --prefix /home/rgommers/code/scipy/build-install

...
💻  ninja -C /home/rgommers/code/scipy/build

...
💻  meson install -C build --only-changed

@rgommers What do you think of adding the pre-commit hook above into the repo with instructions for those who want to lint before committing?

Can it turn into a tools/lint_diff.py improvement? I'm not against adding a pre-commit hook for those folks that want to use it, but it's not a good idea to make it do anything but call out to the tools that are used in the recommended development workflow(s).


RRNN does not necessarily work on 16.04 / Kinetics

The neural network may or may not work on the new version of ROS and Ubuntu. We need to make sure it builds and runs correctly.

Tested and works on 16.04 and Kinetics.


fix: remove node export map entries

These entries cause node to resolve to commonjs in all cases, rather than respecting the consumer's module type.
For example, a consumer with "type": "module" will still resolve to the commonjs entrypoint since node will choose the node entry before the default entry.

this has now uncovered that the published ESM doesn't work in node anyhow, since rxjs' type is not "module".
it means we resolve to the esm entrypoint successfully now (and didn't before), but the resolved file is treated as commonjs.
we would have to rename all the esm output to *.mjs as far as i can tell

abandoning this since it sounds like there's a plan to do it as part of a larger change further ahead in future
will just have to manage for now


Old Program disposal (memory leak)

Fixes #58137

@sheetalkamat or @jakebailey do you think the fix for #58138 is likely to be close to this PR? If so, let's keep it open. If not, let's close it and wait until one of us can get the repro to work for us. (Either way, one of the reviewers needs to repro locally to find out if this PR works.)

#58138 is this PR, did you mean something else?

If we have a repro, I can imagine there being a fix, but this change itself still looks incorrect. I believe we are waiting for some kind of repro.


[WIP] fix(GuildAuditLogs): webhook prop nonexistant

Please describe the changes this PR makes and why it should be merged:
This aims to properly cache webhooks or retrieve them when building the GuildAuditLogs structure.
Semantic versioning classification:

[ ] This PR changes the library's interface (methods or parameters added)

[ ] This PR includes breaking changes (methods removed or renamed, parameters moved or removed)

[ ] This PR only includes non-code changes, like changes to documentation, README, etc.

webhooks are always sent even if its just an empty array


Whether the animationData property is reactive when using the component in vue3

<script setup lang="ts">
import { ref } from 'vue'
import { Vue3Lottie } from 'vue3-lottie'
import AstronautJSON from './astronaut.json'
import AstronautJSON2 from './astronaut2.json'
const data = ref(AstronautJSON)
function change(){
  // The data has changed, but Vue3Lottie will not run again
  data.value = AstronautJSON2
}
</script>

<template>
  <Vue3Lottie :animationData="AstronautJSON" :height="200" :width="200" />
  <button @click="change">change</button>
</template>

expect
animationData or animationLink property is reactive

This is intentional. Having the animation data update dynamically would cause many issues with the event listeners for the lottie-web library. This would also require me to destroy and reset all the custom loop timings to ensure everything plays as intended.
I would suggest rerendering the component after removing it, using the key prop, or having both present and show and hiding the correct one based on some conditions.

Thank you for the PR. This is marked as complete in v3.2.0


Updating the Workflow in the ReadMe to include information on how to …

…access PDFs
The ReadMe now has information on where to find the PDFs for scraping that were put in GitIgnore (so won't show up on the Repository)

Great!


fixed sft trainer docs

What does this PR do?
Fixes # (issue)
Before submitting

[ x ] This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
[ ] Did you read the contributor guideline,
Pull Request section?
[ ] Was this discussed/approved via a GitHub issue? Please add a link
to it if that's the case.
[ ] Did you make sure to update the documentation with your changes? Here are the
documentation guidelines.
[ ] Did you write any new necessary tests?

Who can review?
Anyone in the community is free to review the PR once the tests have passed. Feel free to tag
members/contributors who may be interested in your PR.

Fixes #2400

@qgallouedec Hello, can you merge? or something else needed from me?


OnBehalfOfContentOwner for PlaylistItems

<EMAIL_ADDRESS>on 6 Nov 2013 at 10:26:
There is no `OnBehalfOfContentOwner()` method for `PlaylistItems` as specified
by https://developers.google.com/youtube/v3/docs/playlistItems/insert
(or any other method).

Successfully auto-migrated from code.google.com:
https://code.google.com/p/google-api-go-client/issues/detail?id=47

Fixed by https://github.com/google/google-api-go-client/commit/b4b0a7000d149b24f3d52242d4e626d14c1c4269
Closing.


workload cmd: set discoveryaddress via ISTIOD_ADDRESS

safer, less robust, alternative to #35290

@stevenctl: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

release-notes_istio
7b8eca038b5a676c8ea55cad1204000371ebb1fa
link
true
/test release-notes_istio

gencheck_istio
7b8eca038b5a676c8ea55cad1204000371ebb1fa
link
true
/test gencheck_istio

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

@stevenctl: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

gencheck_istio
7b8eca038b5a676c8ea55cad1204000371ebb1fa
link
true
/test gencheck_istio

lint_istio
7b8eca038b5a676c8ea55cad1204000371ebb1fa
link
true
/test lint_istio

release-notes_istio
1f7c0d2661972cce799b2fef24054655545a4283
link
true
/test release-notes_istio

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

@stevenctl: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

release-notes_istio
1f7c0d2661972cce799b2fef24054655545a4283
link
true
/test release-notes_istio

unit-tests_istio
1f7c0d2661972cce799b2fef24054655545a4283
link
true
/test unit-tests_istio

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

@stevenctl: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

release-notes_istio
1f7c0d2661972cce799b2fef24054655545a4283
link
true
/test release-notes_istio

unit-tests_istio
1f7c0d2661972cce799b2fef24054655545a4283
link
true
/test unit-tests_istio

integ-distroless-k8s-tests_istio
1f7c0d2661972cce799b2fef24054655545a4283
link
true
/test integ-distroless-k8s-tests_istio

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

@stevenctl: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

release-notes_istio
1f7c0d2661972cce799b2fef24054655545a4283
link
true
/test release-notes_istio

unit-tests_istio
1f7c0d2661972cce799b2fef24054655545a4283
link
true
/test unit-tests_istio

integ-distroless-k8s-tests_istio
1f7c0d2661972cce799b2fef24054655545a4283
link
true
/test integ-distroless-k8s-tests_istio

integ-pilot-multicluster-tests_istio
1f7c0d2661972cce799b2fef24054655545a4283
link
true
/test integ-pilot-multicluster-tests_istio

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

@stevenctl: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

unit-tests_istio
1f7c0d2661972cce799b2fef24054655545a4283
link
true
/test unit-tests_istio

integ-distroless-k8s-tests_istio
1f7c0d2661972cce799b2fef24054655545a4283
link
true
/test integ-distroless-k8s-tests_istio

integ-pilot-multicluster-tests_istio
1f7c0d2661972cce799b2fef24054655545a4283
link
true
/test integ-pilot-multicluster-tests_istio

release-notes_istio
788fac272689570f799589aa7a9eb55445a6b152
link
true
/test release-notes_istio

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

Did we ever figure out why the test wasn't effective?

One issue is that we didn't actually pass --revision to istioctl, so we weren't even setting the value.
This means the discovery address was defaulting to istiod.istio-system... which I guess still exists in the revisions test.

@stevenctl: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

release-notes_istio
bf3448f99cd96b8c88e37afd9fc9fa7556a431aa
link
true
/test release-notes_istio

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

@stevenctl: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

integ-pilot-k8s-tests_istio
bf3448f99cd96b8c88e37afd9fc9fa7556a431aa
link
true
/test integ-pilot-k8s-tests_istio

integ-cni-k8s-tests_istio
bf3448f99cd96b8c88e37afd9fc9fa7556a431aa
link
true
/test integ-cni-k8s-tests_istio

release-notes_istio
4b801d935286c3695d2dc97f40ff5720842c2c99
link
true
/test release-notes_istio

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

@stevenctl: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

integ-pilot-k8s-tests_istio
bf3448f99cd96b8c88e37afd9fc9fa7556a431aa
link
true
/test integ-pilot-k8s-tests_istio

integ-cni-k8s-tests_istio
bf3448f99cd96b8c88e37afd9fc9fa7556a431aa
link
true
/test integ-cni-k8s-tests_istio

release-notes_istio
4b801d935286c3695d2dc97f40ff5720842c2c99
link
true
/test release-notes_istio

integ-istiodremote-k8s-tests_istio
4b801d935286c3695d2dc97f40ff5720842c2c99
link
true
/test integ-istiodremote-k8s-tests_istio

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

@stevenctl: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

integ-pilot-k8s-tests_istio
bf3448f99cd96b8c88e37afd9fc9fa7556a431aa
link
true
/test integ-pilot-k8s-tests_istio

integ-cni-k8s-tests_istio
bf3448f99cd96b8c88e37afd9fc9fa7556a431aa
link
true
/test integ-cni-k8s-tests_istio

release-notes_istio
4b801d935286c3695d2dc97f40ff5720842c2c99
link
true
/test release-notes_istio

integ-istiodremote-k8s-tests_istio
4b801d935286c3695d2dc97f40ff5720842c2c99
link
true
/test integ-istiodremote-k8s-tests_istio

lint_istio
4b801d935286c3695d2dc97f40ff5720842c2c99
link
true
/test lint_istio

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

@stevenctl: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

integ-pilot-k8s-tests_istio
bf3448f99cd96b8c88e37afd9fc9fa7556a431aa
link
true
/test integ-pilot-k8s-tests_istio

integ-cni-k8s-tests_istio
bf3448f99cd96b8c88e37afd9fc9fa7556a431aa
link
true
/test integ-cni-k8s-tests_istio

release-notes_istio
4b801d935286c3695d2dc97f40ff5720842c2c99
link
true
/test release-notes_istio

integ-istiodremote-k8s-tests_istio
4b801d935286c3695d2dc97f40ff5720842c2c99
link
true
/test integ-istiodremote-k8s-tests_istio

lint_istio
4b801d935286c3695d2dc97f40ff5720842c2c99
link
true
/test lint_istio

unit-tests_istio
4b801d935286c3695d2dc97f40ff5720842c2c99
link
true
/test unit-tests_istio

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


amCalendar upgraded to accept a timezone parameter

thanks!

Hey @urish, could you push a new tag so we can get the new merged updates from bower?

@DiegoZoracKy yes, will do it today.

Thanks!
Em 28/07/2015 18:56, "Uri Shaked"<EMAIL_ADDRESS>escreveu:

@DiegoZoracKy https://github.com/DiegoZoracKy yes, will do it today.
—
Reply to this email directly or view it on GitHub
https://github.com/urish/angular-moment/pull/152#issuecomment-125764906.

Just released at 0.10.2


Metadata about IPFS CID

TODO
Decide if we need to store more metadata about generate IPFS hashes so they can be re-created at a future date in the same way from the original file.
Best solution is to keep the original CAR file, but this may not be practical.
ISSUE Described
Although IPFS CID = 1 File the inverse is not true
1 File = Many IPFS CID not just one. This is dependent on how the file is parsed.
The main IPFS options are that change the CID are
--raw-leaves
--trickle
--wrap-with-directory
--chunker

Note from the help file
Almost all the flags provided by this command will change the final CID, and
new flags may be added in the future. It is not guaranteed for the implicit
defaults of 'ipfs add' to remain the same in future Kubo releases, or for other
IPFS software to use the same import parameters as Kubo.

If you need to back up or transport content-addressed data using a non-IPFS
medium, CID can be preserved with CAR files.
See 'dag export' and 'dag import' for more information.

This means if we ever need to put a file back into an IPFS swarm, we have to make sure we use the right parameters to create the CAR file that will eventually go into IPFS otherwise the IPFS CID will be different.
We may need to store some additional metadata on how we arrived at a CID
Currently we use
ipfs add hello --cid-version=1

--cid-version=1 also triggers
--cid-base base32
and
--raw-leaves=true

See https://hyphahq.slack.com/archives/C02LDUFLSR2/p1671557371355179 for details


the ecm marmots need to say wheeeeeeeeee.......

what is this?

ecm = eris chain manager = the shell scripts in erisdb/DOCKER


RoutingError: No route matches [GET] "/active_admin/datepicker/datepicker-input-icon.png"

I'm using activeadmin 1.1.0 with formadmin 0.2.0 and it's throwing this error:
Started GET "/active_admin/datepicker/datepicker-input-icon.png" for <IP_ADDRESS> at 2017-10-12 09:13:41 -0300

ActionController::RoutingError (No route matches [GET] "/active_admin/datepicker/datepicker-input-icon.png"):

actionpack (5.1.3) lib/action_dispatch/middleware/debug_exceptions.rb:63:in `call'
actionpack (5.1.3) lib/action_dispatch/middleware/show_exceptions.rb:31:in `call'
railties (5.1.3) lib/rails/rack/logger.rb:36:in `call_app'
railties (5.1.3) lib/rails/rack/logger.rb:24:in `block in call'
activesupport (5.1.3) lib/active_support/tagged_logging.rb:69:in `block in tagged'
activesupport (5.1.3) lib/active_support/tagged_logging.rb:26:in `tagged'
activesupport (5.1.3) lib/active_support/tagged_logging.rb:69:in `tagged'
railties (5.1.3) lib/rails/rack/logger.rb:24:in `call'
sprockets-rails (3.2.1) lib/sprockets/rails/quiet_assets.rb:13:in `call'
actionpack (5.1.3) lib/action_dispatch/middleware/remote_ip.rb:79:in `call'
actionpack (5.1.3) lib/action_dispatch/middleware/request_id.rb:25:in `call'
rack (2.0.3) lib/rack/method_override.rb:22:in `call'
rack (2.0.3) lib/rack/runtime.rb:22:in `call'
activesupport (5.1.3) lib/active_support/cache/strategy/local_cache_middleware.rb:27:in `call'
actionpack (5.1.3) lib/action_dispatch/middleware/executor.rb:12:in `call'
actionpack (5.1.3) lib/action_dispatch/middleware/static.rb:125:in `call'
rack (2.0.3) lib/rack/sendfile.rb:111:in `call'
railties (5.1.3) lib/rails/engine.rb:522:in `call'
puma (3.10.0) lib/puma/configuration.rb:225:in `call'
puma (3.10.0) lib/puma/server.rb:605:in `handle_request'
puma (3.10.0) lib/puma/server.rb:437:in `process_client'
puma (3.10.0) lib/puma/server.rb:301:in `block in run'
puma (3.10.0) lib/puma/thread_pool.rb:120:in `block in spawn_thread'

How to reproduce
I have a this where created_at is a date:
ActiveAdmin.register Payment do
  ...
  filter :created_at
end

The date_picker itself works. The image was there in the branch 0-6-stable but was removed in version 1.1 by this pull request
Workaround
As a workaround I downloaded the image from 6-0-stable and added it to my app at assets/images/active_admin/datepicker/datepicker-input-icon.png
_form.scss is asking for the image here

Close #20.


Avoid assuming an integer PK named 'id' on multiple upload views

Fixes #6512. Eliminate int() casting in JSON responses and use .pk rather than .id to accommodate the possibility of non-standard PK fields.
This isn't really testable without either wider changes to support non-integer IDs in the images app (e.g. in URL routes), or setting up a custom 'multiple upload' app within the test apps, both of which are probably overkill for such a niche requirement - so this is best considered code cleanup rather than a full-fledged new feature.

Nice! I've been meaning to do the same changes in views/generic/models.py so that the Snippets views can override less code, but I haven't checked whether that would break anything (I assume not).

@laymonage  - not sure if it is the same but this issue has been raised recently https://github.com/wagtail/wagtail/issues/9205


betterlockscreen: init at 3.0.1

Motivation for this change
Getting betterlockscreen into the repo
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"
[ ] 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)
[ ] Assured whether relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

@grahamc all checks passed


Panel returns 500 internal server error

I have a panel with 11 querys that works fairly well but every few minutes it returns a 500 internal server error. The grafana log files only says:
t=2020-04-06T14:31:49-0300 lvl=eror msg="Request Completed" logger=context userId=1 orgId=1 uname=admin method=POST path=/api/datasources/proxy/1/introscope-web-services/services/MetricsDataService status=500 remote_addr=<IP_ADDRESS> time_ms=574 size=504 referer="http://...:3000/d/JVgCECrZk/**?orgId=1&refresh=1m"
And the error description on the panels gives this:
Object
status:500
statusText:"Internal Server Error"
data:Object
error:"Internal Server Error"
response:"<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">soapenv:Bodysoapenv:Faultsoapenv:Server.userExceptionjava.util.ConcurrentModificationException<ns1:hostname xmlns:ns1="http://xml.apache.org/axis/">PWINMOM</ns1:hostname></soapenv:Fault></soapenv:Body></soapenv:Envelope>"
message:"Internal Server Error"
message:"Internal Server Error"

It may be related to the patch notes of the CA APM Connector 3.6.4
https://techdocs.broadcom.com/content/broadcom/techdocs/us/en/ca-enterprise-software/it-operations-management/service-operations-insight-connectors/connectors/ca-application-performance-management-connector-4-0-0/release-notes-for-ca-apm-connector-3-6-4.html

APM Connector resets with java.util.ConcurrentModificationException
When one connector on a server encounters java.util.ConcurrentModificationException,
the whole server and all running connectors on that server are affected. Due to this defect, the monitoring of monitoring software is affected.

Is there any way to catch this error and retry the query ? I may not be able to patch the APM Connector for sometime

Hi,
the error behavior you describe is a product bug related to the old Apache Axis version used by CA APM 10.7. The behavior occurs when there are many parallel requests to the APM web services. To my knowledge, the vendor is aware of this issue and I expect them to release a HotFix soon.
I thought about implementing a retry mechanism, but now I'm confident Broadcom/CA will solve this properly on the server side. I will update this issue once the corresponding HotFix is available.

Is there any news on this topic? I cant find anything on a hotfix for this. Maybe you could reconsider a retry mechanism?

As far as I know, the official hotfix release has been delayed. I suggest you contact Broadcom/CA support and mention your issue to get a test hotfix.
I don't have the time to implement a retry mechanism and in our environments we use a test hotfix, so the issue is solved for us for the time being.

I just got word that APM 10.7 HF61 is now available through Broadcom support. The hotfix addresses the HTTP 500 error codes.

Thanks for the news, I'm closing this issue.