"Feedback" links missing from most sections under Docs / SQL / Reference / ...

For some reason, the "Feedback" link (at the top of the page, between "Bookmark" and "Edit") and the entire "Feedback" section (at the bottom of the page) are missing from most, but not all, pages within the Docs / SQL / Reference / ... area.
For example (neither of the following lists is exhaustive):
Has link and section:

Install the SQL Server PowerShell module

Missing link and section:

Errors and Events Reference
System Catalog Views
System Dynamic Management Views
Transact-SQL Reference

@srutzky -- Solomon, thank you again for your considered feedback.
@WilliamDAssafMSFT -- William, please look into this issue.

Thanks @srutzky for the feedback. Many reference articles do have the feedback option enabled. Some of these articles are procedurally generated based off source code, or in the past attracted a high amount of feedback that was low-quality. You can still submit a pull request by clicking the Edit button in the top-right hand corner to submit your suggestions for article improvements. By opening a pull request, you're helping the author add your approved change directly to the documentation. After the updated article is published, GitHub lists you as an article contributor. Once the PR is open, the content team can fine tune your suggestions, so don’t worry about getting everything formatted or capitalized just right. For a complete walkthrough of the the PR process in the browser, check out https://docs.microsoft.com/contribute/.
Thanks again for your attention to these articles, this feedback helps improve our documentation.

Hi @WilliamDAssafMSFT (and @WilliamAntonRohm ): Thanks for the reply, but um, is this a joke? Where are you seeing these "many" articles with Feedback links? Nearly all of the pages I checked in the Docs  / SQL  / Reference area no longer have Feedback links or sections. What does being procedurally generated have to do with anything? Is that something new, because all of these pages, as far as I had seen, had Feedback links and sections until recently. And thank you, I think, for the info about submitting PRs, but I don't see how that's relevant to this issue given that:

they clearly don't get the same level of engagement from the MS Docs team as issues do
they don't have the auto-populated info that points to the actual page on the web, the path to the source file, etc.
they don't work in situations such as #6297 where I know what's missing, but either I don't know what wording to use (in this case for the column descriptions), or it would be inappropriate for me to do that type and/or amount of work without being paid (as a contractor).

So, if I understand your response correctly, you are saying that Microsoft is intentionally making it harder for it's customers to volunteer time and effort to do Microsoft's QA work because some end-users were abusing this feature and either requesting changes that were possibly incorrect, and/or asking questions here instead of in an appropriate forum? Couldn't someone just add language to the "Feedback" section and/or auto-populated info that states appropriate usage and gives a link to the newer https://docs.microsoft.com/en-us/answers/products/ ?

Thanks @srutzky, I hear you and the frustration. I do apologize, I obviously had a typo: I was acknowledging that many reference articles do NOT have the feedback option enabled for Github issues.
I'm sorry it's not been your experience but be assured the same teams and internal collaborations are involved with both Issues and PRs.
If in the case you know what is missing but don't have all the details to fill in or time to research them, starting a PR for the article (and even leaving some things blank) is still the best way to get it fixed and to get recognition for contributing. Content teams will always review, edit to fine tune, and validate PRs before they are merged.


[Test-Proxy] Add more support for Uri sanitization

Right now you can use the UriRegexSanitizer, but ideally there would be a simple sanitizer that accepts the query param keys to sanitize. This could be used for both the request URI as well as request body for content-type of application/x-www-form-urlencoded.
There should also be a simple way to sanitize the other parts of the URI

host
path
query params

To be clear there is a viable work around for this right now.

As a concrete example, here is what we would have to do right now to sanitize a host name:
UriRegexSanitizers.Add(
    new UriRegexSanitizer(@"^((http[s]?|ftp):\/)?\/?(?<host>[^:\/\s]+)((\/\w+)*\/)([\w\-\.]+[^#?\s]+)(.*)?(#[\w\-]+)?$", FAKE_HOST)
    {
        GroupForReplace = "host"
    });

Urls are not secrets we need to stop doing this.

I agree with Pavel here.  Closing.
CC: @scbedd

@pakrym is there no case where secrets might show up in the uri? I'm thinking cases like a SAS token as part of the uri?

Yes, they can be in the query (sanitizing which we already support) but never in the path.

Actually, I might be wrong. @JoshLove-msft  @scbedd do we support query parameter sanitization?

Actually, I might be wrong. @JoshLove-msft @scbedd do we support query parameter sanitization?

There is a UriRegexSanitizer which lets you apply a regex to the entire URI. The point of this issue was to ask for an easier way to handle sanitizing the various parts of the URI. E.g. for query params, a key could be specified.

Assigning to @scbedd for consideration...


MSID: 94842 Version: 2 DOI: 10.1101/2<IP_ADDRESS>2166

MSID: 94842
Version: 2
Preprint DOI: https://doi.org/10.1101/2<IP_ADDRESS>2166
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=94842
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>2166

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/94842v2
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>2166
Confirm reviews returned by EPP: https://prod--epp.elifesciences.org/api/reviewed-preprints/94842/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!

warn: [mixed-citation-other-publication-flag] mixed-citation in reference (id=c33) has a publication-type='other'. Is that correct?

Hi @acollings, we have some (broken) citations/links in the author response:

Please can these be removed?

Hi @fred-atherden yep: done!

Thanks!


feat(all): Create Common DTOs with ServiceName

Included on Ping, Version, Config and Metrics responses.
Fixes #3868
Signed-off-by: Alex Ullrich<EMAIL_ADDRESS>

If your build fails  due to your commit message not passing the build checks, please review the guidelines here: https://github.com/edgexfoundry/edgex-go/blob/main/.github/Contributing.md
PR Checklist
Please check if your PR fulfills the following requirements:

[x] I am not introducing a breaking change (if you are, flag in conventional commit message with BREAKING CHANGE: describing the break)
[x] I am not introducing a new dependency (add notes below if you are)

go.mod diff from contract changes

[x] I have added unit tests for the new feature or bug fix (if not, why?)
[ ] I have fully tested (add details below) this the new feature or bug fix (if not, why?)
unit tests sufficient
[ ] I have opened a PR for the related docs change (if not, why?)
not sure needed

Testing Instructions

New Dependency Instructions (If applicable)

Codecov Report

Merging #3870 (dc47fff) into main (d438b00) will increase coverage by 0.00%.
The diff coverage is 42.85%.

@@           Coverage Diff           @@
##             main    #3870   +/-   ##
=======================================
  Coverage   45.77%   45.78%
=======================================
  Files         112      112
  Lines        9640     9641    +1
=======================================
+ Hits         4413     4414    +1
  Misses       4844     4844
  Partials      383      383

Impacted Files
Coverage Δ

internal/pkg/controller/http/common.go
39.58% <42.85%> (+1.28%)
: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 d438b00...dc47fff. Read the comment docs.

this PR should be hold until we resolve the breaking changes of edgexfoundry/go-mod-core-contracts#695

@cloudxxx8 , we agreed that those are not true breaking changes:
https://github.com/edgexfoundry/go-mod-core-contracts/pull/695#discussion_r791829383


call action handlers after action, in c++ server

Changelog

Guarantees that action handlers in C++ ws server are called after the action has been applied.
Docs

https://github.com/orgs/foxglove/discussions/1049
Description

Problem
In C++ server, handlers for below events are called before the internal states are fully updated:

subscribe
unsubscribe
client advertise
client unadvertise
subscribe connection graph

As a consequence, some user behavior does not work as expected, such as calling sendMessage() for messages of the requested topic inside of subscription handler. When subscription handler is called, the internal state does not recognize the requested topic as subscribed, and sendMessage() filters out this unsubscribed topic.
This seems to be a bug rather than a spec, because typescript and python server implementations calls listener/emit event after all internal tables are updated.
Changes
For the above events, switch the order of handler call and internal map updates.

https://linear.app/foxglove/issue/FG-9181/c-foxglove-websocket-server-ambiguous-handler-invoke-timing

Thanks!


Make label extractor generic so that it can return label of any type not only string.

The example used in PSIMINER is extracting the method name which is single string as label. And the granularity is method level. That means I can get label for a method. For example if my problem is to get the names of parameter in the method. I need to return more than one string for a method. So, I feel it is better to make label extractor generic so that I can extend the label extractor to return any type.
I feel this could increase extensibility of the label extractor

Instead of having LabeledTree is a type of relationship, have a label interface that can be extended to different types and has "has-a" relationship for Label and its value. The label implementation can be used by the extraction implementation.

I would like to suggest a simple solution. Please let me know if it works. Instead of having LabeledTree, having a Label interface that encapsulates a value of different type in its implementation. The implementation of interface Label can be used by the extraction implementation.

Thank you for contributing to PSIMiner @koushik1703 !
The new label extraction mechanism looks useful, good idea :)


Using WebView in Android v7.0 hangs the app.

Description
What I did: Tried to open WebView in Android Emulator v7.0.0 (API 24)
What I expected to happen: Open the url provided in a webview
What actually happens: The app hangs without loading the webpage
I had used Genymotion Emulator for this.
Some of the errors which I was able to see while running adb logcat were:
04-06 04:03:11.218  1802  1833 W unknown:ViewManagerPropertyUpdater: Could not find generated setter for class com.facebook.react.views.art.ARTGroupViewManager
04-06 04:03:11.219  1802  1833 W unknown:ViewManagerPropertyUpdater: Could not find generated setter for class com.facebook.react.views.art.ARTGroupShadowNode
04-06 04:03:11.223  1802  1833 W unknown:ViewManagerPropertyUpdater: Could not find generated setter for class com.facebook.react.views.art.ARTShapeViewManager
04-06 04:03:11.223  1802  1833 W unknown:ViewManagerPropertyUpdater: Could not find generated setter for class com.facebook.react.views.art.ARTShapeShadowNode
04-06 04:03:11.223  1802  1833 W unknown:ViewManagerPropertyUpdater: Could not find generated setter for class com.facebook.react.views.art.ARTTextViewManager

04-06 04:03:12.395  1802  1862 E chromium: [ERROR:gles2_cmd_decoder.cc(2167)] [.CommandBufferContext.RenderWorker-0xd517d5c0]GL ERROR :GL_INVALID_OPERATION : GLES2DecoderImpl::DoBindTexImage2DCHROMIUM: <- error from previous GL command

Full logs at : https://gist.github.com/chiraggshah/b57b0eb6c67cd5ee4d9acc4033b809a4
Reproduction Steps and Sample Code
A simple application using WebView inside index.android.js should be able to reproduce this
import React, { Component } from 'react';
import { AppRegistry, WebView } from 'react-native';

export default class SampleAndroidTest extends Component {
  render() {
    return (
      <WebView
        source={{uri: 'https://www.facebook.com'}}
        style={{
          backgroundColor: 'rgba(255,255,255,0.8)',
          height: 300,
        }}
        scalesPageToFit={true}
      />
    );
  }
}

AppRegistry.registerComponent('SampleAndroidTest', () => SampleAndroidTest);

Additional Information

React Native version: I tried on 0.41.0 and 0.43.0, but I think it should be reproducable on other versions as well
Platform: Android
Development Operating System: MacOS

Found this in Android Docs for Android N(7.0) https://developer.android.com/about/versions/nougat/android-7.0.html#webview
Maybe its related to this

Did you also test on Android devices lower than 7.0? For example what happens with Lollipop or Marshmallow?

@hey99xx : Yes, I had tried on Android devices lower than 7.0, and they work fine.

I can confirm this is happening on older versions of Android. It's related specifically to the Android System Webview update (v 57.0.2987.132, Updated May 29, 2017). Our app was working before installing, installed JUST that update, now it hangs.
I now have reports from:

Android 7 (2017-03-01 security)
Android 6 (2016-08-1 security)

I'm personally testing on Android 5.1 with security patch level 2016-03-01.
This must be a chrome update problem.

Google released a 126 version and then a couple days later the 132 version above. I believe the problem exists in both as 132 was just a security fix. Here is the changelog from the previous stable 108 to 126: https://chromium.googlesource.com/chromium/src/+log/57.0.2987.108..57.0.2987.126?pretty=fuller&n=10000
Here's a bug I logged with Chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=709507

@ghidinelli In your bug report to Chromium, you've written

Update to Android System Webview 57.0.2987.126 or .132

So do you think it's between 126 -- 132 or 108 -- 126. I am confused reading your post here and the bug report. Anyways thanks for notifying, I will also try to test this, as we also use webviews in react-native.

@hey99xx I think it's between 108-126 because the 126-132 was just a security regression patch. We only started getting reports of this about 7-8 days ago and that's when .126 started rolling out.
FWIW, uninstalling the update does restore working behavior.

Looks to be same issue https://jira.appcelerator.org/browse/TIMOB-24540 ( at least same stack trace )

Hi there! This issue is being closed because it has been inactive for a while. Maybe the issue has been fixed in a recent release, or perhaps it is not affecting a lot of people. Either way, we're automatically closing issues after a period of inactivity. Please do not take it personally!
If you think this issue should definitely remain open, please let us know. The following information is helpful when it comes to determining if the issue should be re-opened:

Does the issue still reproduce on the latest release candidate? Post a comment with the version you tested.
If so, is there any information missing from the bug report? Post a comment with all the information required by the issue template.
Is there a pull request that addresses this issue? Post a comment with the PR number so we can follow up.

If you would like to work on a patch to fix the issue, contributions are very welcome! Read through the contribution guide, and feel free to hop into #react-native if you need help planning your contribution.


Alias timer interface for event-loop 0.4 and 0.5 compatibility

In react/event-loop 0.5 we moved the TimerInterface in https://github.com/reactphp/event-loop/pull/138. This PR adds a compatibility file to make sure this package keeps working with event-loop 0.4 and 0.5.

@elazar as discussed updated this PR to drop react/event-loop 0.4 support

Looks good to me. We'll need to document that Client->isTimerActive() has been removed when these changes are released. Since this is technically a major API change, I'd assume it would require a major version bump.

:tada:


Serve static pages by webpack-dev-server

This is probably not an issue, but feature request. Is there a way to serve html files generated by this plugin by webpack-dev-server dynamically? I can get the dev server to serve already generated files from the output directory, but I would like the webpack-dev-server to rerun generation by the plugin whenever sources change and serve this up-to-date html files. Any ideas how to do this?

I just had this same problem myself and found that soulution is to use BrowserSync instead of Webpack dev server. This is my webpack.config.js:
const StaticSiteGeneratorPlugin = require('static-site-generator-webpack-plugin');
const BrowserSyncPlugin = require('browser-sync-webpack-plugin');

const path = require('path');
const data = require('./app/data');

module.exports = {

    entry: {
        main: './app/entry.js'
    },

    output: {
        filename: 'bundle.js',
        path: path.join(__dirname, 'build'),
        libraryTarget: 'umd',
        publicPath: '/'
    },

    module: {
        loaders: [
            {
                test: /\.js$/,
                loader: 'babel',
                include: [
                    path.join(__dirname, 'app')
                ],
                query: {
                    presets: ['es2015', 'react']
                }
            },
        ]
    },

    plugins: [
        new StaticSiteGeneratorPlugin('main', data.routes, data),
        new BrowserSyncPlugin({
            host: 'localhost',
            port: 3000,
            server: { baseDir: ['build'] }
        })
    ]
}

...and when I run webpack --watch my build/ directory is served on localhost:3000 and files are regenerated on change.

Wait. I don't agree with using browser sync to solve this issue. What if I want the HMR module?

This issue seem related to my problem:
When I remove static site generator from my webpack config I get the following error. Anyone have any advice on how I can track the issue down?
ERROR in ReferenceError: self is not defined
    at Object.<anonymous> (static:18380:18)
    at Object.<anonymous> (static:18416:30)
    at __webpack_require__ (static:672:30)
    at fn (static:98:20)
    at Object.<anonymous> (static:36502:1)
    at __webpack_require__ (static:672:30)
    at module.exports (static:718:39)
    at static:721:10
    at webpackUniversalModuleDefinition (static:3:20)
    at static:10:3

Im having the same problem

Try adding inline: false in devServer.
https://stackoverflow.com/a/41492420/592641

@Birowsky brilliant - that solved my problem.

I do not need this feature any more others seem happy with the workarounds discussed => closing this almost 4 years old feature request.


Examples on how to edit start up script!

Can someone show me how to modify the start up script? How i add the commands. I dont know.
 :)

Hi @labaland,
There is an example in https://github.com/joedwards32/CS2/blob/main/examples/cs2.cfg.tgz
What you need to do is construct a Tar GZip like that one, containing your scripts.
Host that TGZ somewhere and use CS2_CFG_URL to download it.
Alternatively, you can bind mount in a specific script file:
-v ./pre.sh:/etc/pre.sh


[PDI-18091] Preview data for Transformation Executor step shows conve…

…rsion error when using parameters
Analyzing this case there is in fact a previous behavior (bug?) related with the TransExecutor stepMeta, since the rowMeta provided is related with the previous step, but the rowData shows values after execution.
In this particular case the preview step we will have one Column with only one  header "example1" (provided by the DataGrid step - previous step) but our data will have 3 Columns with different headers (as result of the TransExecutor execution itself). With BACKLOG-22742 we started to use indexing to find those Columns, that now fails validating them. They don't match.
Since this was working this way before this PR ensures the old behavior again, keeping the BACKLOG-22742 logic.
No unit tests provided due to SWT items to mock.
@pentaho-lmartins

:white_check_mark: Build finished in 10m 45s
Build command:
mvn clean verify -B -e -Daudit -amd -pl ui

:ok_hand: All tests passed!
Tests run: 1126, Failures: 0, Skipped: 0    Test Results

:information_source:  This is an automatic message

:white_check_mark: Build finished in 10m 14s
Build command:
mvn clean verify -B -e -Daudit -amd -pl ui

:ok_hand: All tests passed!
Tests run: 1126, Failures: 0, Skipped: 0    Test Results

:information_source:  This is an automatic message

:white_check_mark: Build finished in 14m 17s
Build command:
mvn clean verify -B -e -Daudit -amd -pl ui

:ok_hand: All tests passed!
Tests run: 1126, Failures: 0, Skipped: 0    Test Results

:information_source:  This is an automatic message

:white_check_mark: Build finished in 11m 14s
Build command:
mvn clean verify -B -e -Daudit -amd -pl ui

:ok_hand: All tests passed!
Tests run: 1126, Failures: 0, Skipped: 0    Test Results

:information_source:  This is an automatic message

:white_check_mark: Build finished in 15m 50s
Build command:
mvn clean verify -B -e -Daudit -amd -pl ui

:ok_hand: All tests passed!
Tests run: 1126, Failures: 0, Skipped: 0    Test Results

:information_source:  This is an automatic message

:white_check_mark: Build finished in 14m 23s
Build command:
mvn clean verify -B -e -Daudit -amd -pl ui

:ok_hand: All tests passed!
Tests run: 1126, Failures: 0, Skipped: 0    Test Results

:information_source:  This is an automatic message

:white_check_mark: Build finished in 15m
Build command:
mvn clean verify -B -e -Daudit -amd -pl ui

:ok_hand: All tests passed!
Tests run: 1130, Failures: 0, Skipped: 0    Test Results

:information_source:  This is an automatic message

:white_check_mark: Build finished in 14m 3s
Build command:
mvn clean verify -B -e -Daudit -amd -pl ui

:ok_hand: All tests passed!
Tests run: 1131, Failures: 0, Skipped: 0    Test Results

:information_source:  This is an automatic message

:white_check_mark: Build finished in 14m 3s
Build command:
mvn clean verify -B -e -Daudit -amd -pl ui

:ok_hand: All tests passed!
Tests run: 1131, Failures: 0, Skipped: 0    Test Results

:information_source:  This is an automatic message


DashLogger breaks a callback that returns a dict

Hi, I'm outputting a dict to a store from a callback that has a DashLogger and the Notification object is getting merged into the dict. If I return a string or a list of strings it works fine, but not for a dict:
@app.callback(
  Output("store-notification", "data"),
  Input("stop-btn", "n_clicks"),
  log = True
)
def stop_btn(n_clicks, dash_logger: DashLogger):
  if not n_clicks:
      raise PreventUpdate()
  dash_logger.warning("stop btn was hit")
  return {"status":"new","msg":"new upload"}

Dash error:
dash._grouping.SchemaTypeValidationError: Schema: [<Output `{"id":"store-notification","idx":0,"prop":"data"}.data`>, <Output `notifications_provider.children`>]
Path: ()
Expected type: (<class 'tuple'>, <class 'list'>)
Received value of type <class 'dict'>:
{'status': 'new', 'msg': 'new upload', 1: [Notification(id='1d13fc57-fe59-440a-b5c2-72031bb62219', action='show', autoClose=False, color='yellow', message='stop btn was hit', title='Warning')]}

Returning the dict in a list does not error from the callback but breaks other store dependencies that are expecting a dict. Also tried returning a tuple without success.
Any workaround ideas?
Many thanks!

That sounds like a bug. Could you post a complete MWE? Then I'll take a look at a bugfix

MWE with error. I included some working variants too.
Thanks!
from dash_extensions.enrich import Output, Input, html, dcc, State, DashProxy, LogTransform, DashLogger, MultiplexerTransform
from dash.exceptions import PreventUpdate
import dash_mantine_components as dmc

app = DashProxy(__name__,
          title="Test",
          update_title=None,
          url_base_pathname="/",
          transforms=[
            MultiplexerTransform(),
            LogTransform()
          ]
      )

app.layout = dmc.MantineProvider(
  withGlobalStyles = True,
  children = html.Div(
    [
      dcc.Store(id = "store", data = None),
      dmc.Button("Push Me", id = "btn", size = "lg"),
      html.Div(id = "billboard")
    ]
  )
)

# [Working]
# cb to save DICT to store, without notification
# @app.callback(
#   Output("store","data"),
#   Input("btn","n_clicks"),
#   prevent_initial_call = True
# )
# def cb1(n_clicks):
#   if n_clicks is not None:
#     return {"status":"click","msg":f"clicked {n_clicks} time{'s' if n_clicks > 0 else ''}"}
#   else:
#     return None

# [Working]
# cb to save TEXT to store, trigger notification
# @app.callback(
#   Output("store","data"),
#   Input("btn","n_clicks"),
#   log = True,
#   prevent_initial_call = True
# )
# def cb1(n_clicks, dash_logger: DashLogger):
#   dash_logger.warning("btn was clicked",autoClose = 2000)
#   if not n_clicks:
#     raise PreventUpdate()
#   else:
#     return f"clicked {n_clicks} time{'s' if n_clicks > 0 else ''}"

# [Not Working]
# cb to save DICT to store, trigger notification
@app.callback(
  Output("store","data"),
  Input("btn","n_clicks"),
  log = True,
  prevent_initial_call = True
)
def cb1(n_clicks, dash_logger: DashLogger):
  if not n_clicks:
    raise PreventUpdate()
  dash_logger.warning("btn was clicked",autoClose = 2000)
  if n_clicks is not None:
    return {"status":"click","msg":f"clicked {n_clicks} time{'s' if n_clicks > 0 else ''}"}
  else:
    return None

# cb to use store in ui
@app.callback(
  Output("billboard","children"),
  Input("store","data"),
  prevent_initial_call = True
)
def cb2(data):
  if data:
    if isinstance(data, str):
      return dmc.Alert(
        id = "alert",
        children = [data],
        title = "Clicked!",
        color = "blue",
        withCloseButton = True
      )
    else:
      return dmc.Alert(
        id = "alert",
        children = [data["msg"]],
        title = "Clicked!",
        color = "blue",
        withCloseButton = True
      )
  else:
    return "no clicks"

if __name__ == "__main__":
  app.run_server(debug = True)

# http://localhost:8050/

I have run into this, too. It happens on "dict-like" return values like dcc.send_file.
I am loving the LogTransform with the dash mantine components. Thanks for building it. Being able to pass user-notifications makes my (rather large) internal corporate app just much more robust and user-friendly.
Any updates on this issue?


Stop updating game-tick with server-tick

This caused SOME of the instability and "rubber banding", especially with animations that are entirely client-side.
This doesn't resolve all issues described in #6 since rubber banding between server-client can still happen for several other reasons.
Leaving it as a draft still because I am still trying to compare if the animation speed is correct... it looks better compared to the actual client now but I am unsure if these changes won't affect anything else:
self.client_tick.0 += (delta_time * 1000.0) as u32;

This is fixed as of https://github.com/vE5li/korangar/commit/6f48305b0b89fbb83d7b363d4eaadc0a3510a67a


[cli] args after positional context are ignored

Just a minor inconsistency for the CLI experience:
$ img build . -t foo -d
=> debug and tag will be set to false and "".

Is anyone working on this issue? It breaks build commands and requires us to change projects we don't have control over. Should breaking CLI compatibility with docker build be a bug and not an enhancement?


Is it possible that changes made by setup_var.efi don't persist?

Hello,
I have a Lenovo ThinkStation P360 Tiny that I am trying to flash a new BIOS to with microcode to support Intel 13th Generation CPUs.
I am getting this error when attempting to flash back my modified BIOS:
Error 167: Protected Range Registers are currently set by BIOS, preventing flash access. Please contact the target system BIOS vendor for an option to disabled Protected Range Registers.
I have full read access to the SPI chip so I dumped my BIOS and used IFR Extractor to see the system BIOS strings and searched for range registers and found this:

I booted into a UEFI shell and used setup_var to set 0x73D to 0x0 (with -n PchSetup) and I see it set when I read it back then and there; however when I reboot, I see the Lenovo splash screen, and my screen goes black as if it reboots and then I see the Lenovo splash screen again and then see the loading circle for booting into my Windows OS.
Is there a reason why the values don't persist over a reboot/why my BIOS seems like it reloads and possibly resets those variables? I have tried using fpt in the UEFI shell while the 0x73D offset is set to 0x0 and I still get the same Error 167 error, as if it doesn't make a difference. Not sure if it needs to reboot to go into effect, but if I reboot it seems like the BIOS resets those changed offsets.
I have tried disabling BIOS Lock (only and with FPRR) and that resets back to its default value as well.
Would you be able to provide assistance on why this may be happening, as well as any ideas on a resolution?
Thanks,
Chris

The dual reboot seems like firmware detects and tries to fix Flash Protection Lock by itself. There may be additional high-level protections in the firmware that can't be unlocked by just changing settings.
This tool (setup_var.efi) relies on "by-the-book" approaches (UEFI standard-defined services) rather than hacks to work, as bypassing firmware limitations can be very tricky, implementation-specific and often requires leaked information. In the case of standard setting values, most OEMs simply hide them from the Settings UI instead of protecting them from being overwritten. Therefore, this topic is not the primary focus of this repository.
Since you have tried FPRR, I don't think there are more methods I've learnt about BIOS modding that could help here. (Though this tool is all about BIOS modding, I haven't met many modding requirements myself and thus didn't learn or participate much into the community)
Using a SPI programmer to directly write BIOS image was the last resort, but given that nowadays the OEMs making many more security-related stuff into the firmware, I'm not sure if that would trigger more protections.
Besides, I've heard of a project called BITS that can load microcode and chainload other UEFI OS. You might find it interesting if you only want to boot an OS that doesn't have support for live microcode loading.


Updated analytics to use a non-random uid and a minor log string change.

Travis has finished - errors are unrelated to this CL.

Both known failures are unrelated to the CI. Re-running them and I'll merge this.


Is it possible to build against Apple's OpenSSL?

pkg-config seems to know where Apple's OpenSSL is, but there do not seem to be headers installed by default. So, not sure that this is possible

using python now


[Bug] Sidebar Clipping through header navigation bar

I am not sure if this should be resolved or just be ignored with the addition of the menu bar mason is working to implement currently. But the sidebar clips the navigation bar which is an issue if the menu isn't going to be implemented soon. We just need the sidebar to start below the navigation bar.

Can i solve this issue?
Please assign this issue to me. so i will contribute in this issue.


[Question] Onnx -> TF

Could you please clarify what is the reason for using tf.compat.v1.Session() instead of TF 2 eager execution? Is it related to computing the gradient for the model converted from onnx?

Yes, I vaguely recall that this was the easiest way for me to get gradients through the ONNX model. I don't remember if eager mode wasn't supported, or if I just got this version working first and moved on.


Remove reference to Apache Incubator status.

TVM is no longer in the Apache Incubator; moving mentors to the end of the doc.

I think this is accurate; let me know if not. @tqchen @jroesch


docker

Can you make docker image for Etopa server?

Thanks for the suggestion.
I have created a Docker image for the Etopa server (backend + web frontend): d7bbe12b15d706f6edc918f86aa26aad400f53ec
Feedback would be very much appreciated, if you have some experience with Docker images :)

Everything works great...config is simple.....i deploy my etopa server on vps, create user, import database from my account on etopa.de....perfecto:). Thank You very much.


Bugfix/Change ConfigurationAttr unexported fields to exported fields

Fixed ConfigurationAttr unexported fields issue
Updated documentation, changelog

Codecov Report

Merging #49 (71c8cef) into develop (406e538) will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##           develop       #49   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files           14        14
  Lines          498       498
=========================================
  Hits           498       498

Impacted Files
Coverage Δ

server.go
100.00% <ø> (ø)

configuration.go
100.00% <100.00%> (ø)

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 406e538...71c8cef. Read the comment docs.


Problem emails do not get to gmail addresses

Example URL(s)
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
<EMAIL_ADDRESS>host gmail-smtp-in.l.google.com [2a00:1450:4010:c0b::1a]
SMTP error from remote mail server after pipelined end of data:
550-5.7.26 This mail has been blocked because the sender is unauthenticated.
550-5.7.26 Gmail requires all senders to authenticate with either SPF or DKIM.
550-5.7.26
550-5.7.26  Authentication results:
550-5.7.26  DKIM = did not pass
550-5.7.26  SPF [clinpharm-spbgmu.ru] with ip:
[2a02:408:7722:1:77:222:41:79] =
550-5.7.26 did not pass
550-5.7.26
550-5.7.26  To mitigate this issue, please visit Gmail's authentication guide
550-5.7.26 for instructions on setting up authentication:
550 5.7.26  https://support.google.com/mail/answer/81126#authentication f18-20020a2e1f12000000b002c50bd6d1c8si1069648ljf.488 - gsmtp
Reporting-MTA: dns; smtpout13.sweb.ru
Action: failed
Final-Recipient<EMAIL_ADDRESS>Status: 5.0.0
Remote-MTA: dns; gmail-smtp-in.l.google.com
Diagnostic-Code: smtp; 550-5.7.26 This mail has been blocked because the sender is unauthenticated.
550-5.7.26 Gmail requires all senders to authenticate with either SPF or DKIM.
550-5.7.26
550-5.7.26  Authentication results:
550-5.7.26  DKIM = did not pass
550-5.7.26  SPF [clinpharm-spbgmu.ru] with ip: [2a02:408:7722:1:77:222:41:79] =
550-5.7.26 did not pass
550-5.7.26
550-5.7.26  To mitigate this issue, please visit Gmail's authentication guide
550-5.7.26 for instructions on setting up authentication:
550 5.7.26  https://support.google.com/mail/answer/81126#authentication f18-20020a2e1f12000000b002c50bd6d1c8si1069648ljf.488 - gsmtp
Actual Behavior
emails from<EMAIL_ADDRESS>do not get to all gmail  addresses    (ex<EMAIL_ADDRESS>Displaied error:
<EMAIL_ADDRESS>host gmail-smtp-in.l.google.com [2a00:1450:4010:c0b::1a]
SMTP error from remote mail server after pipelined end of data:
550-5.7.26 This mail has been blocked because the sender is unauthenticated.
550-5.7.26 Gmail requires all senders to authenticate with either SPF or DKIM.
550-5.7.26
550-5.7.26  Authentication results:
550-5.7.26  DKIM = did not pass
550-5.7.26  SPF [clinpharm-spbgmu.ru] with ip:
[2a02:408:7722:1:77:222:41:79] =
550-5.7.26 did not pass
550-5.7.26
550-5.7.26  To mitigate this issue, please visit Gmail's authentication guide
550-5.7.26 for instructions on setting up authentication:
550 5.7.26  https://support.google.com/mail/answer/81126#authentication f18-20020a2e1f12000000b002c50bd6d1c8si1069648ljf.488 - gsmtp
Reporting-MTA: dns; smtpout13.sweb.ru
Action: failed
Final-Recipient<EMAIL_ADDRESS>Status: 5.0.0
Remote-MTA: dns; gmail-smtp-in.l.google.com
Diagnostic-Code: smtp; 550-5.7.26 This mail has been blocked because the sender is unauthenticated.
550-5.7.26 Gmail requires all senders to authenticate with either SPF or DKIM.
550-5.7.26
550-5.7.26  Authentication results:
550-5.7.26  DKIM = did not pass
550-5.7.26  SPF [clinpharm-spbgmu.ru] with ip: [2a02:408:7722:1:77:222:41:79] =
550-5.7.26 did not pass
550-5.7.26
550-5.7.26  To mitigate this issue, please visit Gmail's authentication guide
550-5.7.26 for instructions on setting up authentication:
550 5.7.26  https://support.google.com/mail/answer/81126#authentication f18-20020a2e1f12000000b002c50bd6d1c8si1069648ljf.488 - gsmtp
Expected Behavior
Other
Additional information
No response

Howdy @ElenaVerbtskaya, it seems like you're experiencing issues... but unfortunately as a Docs team, this isn't something we can truly help out with.
You might be able to find your answer with this Email troubleshooting guide.
If not, recommend you reaching out to Cloudflare Support or looking in the Cloudflare community.


I have 2 warns

npm notice created a lockfile as package-lock.json. You should commit this file.
npm WARN<EMAIL_ADDRESS>No repository field.
npm WARN<EMAIL_ADDRESS>No license field.

You can ignore those. From what I've seen, it's inconsequential to the program running.


add columns to migration

I am looking to add two columns to the messages migration so that the messages can accept not only subject and body but also longitude and latitude. I put both in the initial migration and then when I try to submit through the form it say its taking them. When I look at the message in the console it shows !!null and the message.lat will not render anything. What should I do?

Is this possible or not - seems like there is no way to get other message fields to work properly

http://stackoverflow.com/questions/25706280/passing-object-with-mailboxer-notification. Refer to my answer for passing objects to notification.
You can pass lat long as part of the notified object and use it without the need of having migrations in place.


Option to use built-in default image

Feature request.
Using built-in default image option can significantly reduce url length.
For example default option:

built-in option:

Question: This is something you want to use for self-hosting I suppose? So you want to set it in the config-file?

I meant any image of your choice with appropriate license, that will work with images.weserv.nl hosting too. Is it technically possible?

That would be hard, as we need to write an interface to upload, review and address such images.


Performance numbers?

Hi,
We'd like to develop a C# wrapper on top of mvfst. Before doing that, we'd like to better understand mvfst performance. Are there any performance figure available? How mvfst compare with TCP and in which scenarios?
Thanks!

Hello!
What kind of performance numbers are you interested in? Single stream continuous throughput?
We have a tool for this in quic/tools, called "tperf". The defaults are not great though, and it needs some tuning to get right.
I can tell you that in good network conditions on modern Linux, mvfst can achieve > 3Gbps of single stream throughput on commodity server hardware.
When used as the transport for HTTP/3, it is not less performant than TCP + HTTP/2, albeit at a higher per-transaction CPU cost.

Thanks!
Yes, I'd like to understand how it compares to TCP under different scenarios. We'd like to use mvfst as our transport (optional) in our software, and that's why. So, any numbers comparing will be great :)

We have a tool for this in quic/tools, called "tperf". The defaults are not great though, and it needs some tuning to get right.

Any hints on how to use this?

Example:
# Server:
$BUILD_DIR/tperf -congestion=none -gso true --max_cwnd_mss=4294967295 --num_streams=10 &

# Client:
$BUILD_DIR/tperf -mode client -congestion=newreno  -window 256000 -duration=20

You can find more params from the quic/tools/tperf.cpp file, or run  $BUILD_DIR/tperf --help

@psantosl : i think we are good to close this? Let us know if there are more you'd like to know or if you run into any problem. Thank you!

Sure! Thank you!


Expose the CAS tiers as configuration options

Tiers may relate to pricing / gate features such as audit logging when CAS goes GA. This field should be exposed on the (Cluster)Issuer

We decided to keep the Issuer configuration simple


feat: Switch to the v2 Twitter API

breaking change: Moves to using the v2 API. Twitter apps need to be in a project to access the v2 API.
breaking change: When retweeting, the only URL returned now is the original tweet, not the retweeter's tweet.
Replaces the twitter library with twitter-api-v2, and switches the logic over to using the v2 Twitter API where possible.
This removes the need for the Ads API as the v2 tweet endpoint supports polls directly. This still uses the v1 API for media, but essentials API access will allow access to this as there is no v2 equivalent currently.

Only remaining work here now is to update the README and docs directory to remove references to the Ads API, to remove guidance on requesting elevated access as only essentials access is required now (v2 + v1 media), and to remove the comment that alt text cannot be set as it now can be.

I have extensively tested each tweet type in production of this branch over at  https://github.com/IstoraMandiri/twitter-together-testing and https://twitter.com/testing_tt_
Everything seems to be working other than some minor preview-related bugs and misc improvements, which I have added issues to this repo for.

Should I bump package.json to 3.0.0 at the same time, or should I leave that for the bot to handle still?

Should I bump package.json to 3.0.0 at the same time, or should I leave that for the bot to handle still?

that should be done by semantic-release via this configuration:
https://github.com/twitter-together/action/blob/dffa59cb5c1b16fd6aca5014c6c30cfc4e04d23f/package.json#L60-L67

Cool, will bump the workflow, pls hold

Nice, can confirm the Twitter App creation docs are also looking very good and match my recent experience.

@gr2m Is there anything blocking merging this? Wasn't sure if I can boop the button, or if you'd left it unmerged for a reason?

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

:sus: Why did it release it as minor

Gregor, can you do some magic to unrelease that minor release, 'cause this is very likely a breaking change for some folks 🤔

Pretty sure @MattIPv4 is right, @gr2m, as presumably current v1 API users would need to set up new keys to use the v2 endpoints?
I cannot easily test this unfortunately.

Most users should be safe, it's only breaking for those that're using apps outside a project, as legacy apps only have v1 access.
I'm guessing the bot didn't look at the PR body, only the commit body (which just had the normal commit log w/o the breaking change warnings). Automation 😓

I notice that the build is also built under
/***/ 4147:
/***/ ((module) => {

"use strict";
module.exports = {"i8":"2.1.2"};

Perhaps bump the package.json to 3.0.0 and rebuild?

:sus: Why did it release it as minor

Ouch, sorry :(
semantic-release needs a BREAKING CHANGE: ... in the commit body in order to do a breaking release.
I've documented the conventions here: https://github.com/twitter-together/action/blob/main/CONTRIBUTING.md#merging-the-pull-request--releasing-a-new-version
As we don't release to npm, we can just delete the git tag/github release and have semantic-release do a breaking release with an empty commit. I'm on it

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

the above comment makes no sense to me 🤷🏼
Here are the two relevant releases

https://github.com/twitter-together/action/releases/tag/v2.2.1
https://github.com/twitter-together/action/releases/tag/v3.0.0

2.x maintenance releases can be done with pull requsets against the 2.x branch

Ty for the fix -- yah, figured it was probably the lack of breaking change mention in the commit. I'd read the doc before but I think parsed it as needing breaking change in the PR body, not commit body (though commit makes far, far more sense).

semantic-release only works on git. The interaction with GitHub is just a plugin. Hence the need to have correct commit messages. I'd love a better integration with GitHub using an app for a long time now. The day just need more hours 🤣

Makes total sense, I just had a lapse in brain function 😂

To Istora's point above though, https://github.com/twitter-together/action/blob/v3/dist/index.js does declare itself as v2 still though 'cause it was built before the package.json bump was done.
Is there a semantic-release plugin that can run the build command after the version bump, and then commit both the updated package.json and dist.js? (Which I think is really all that's needed to solve for #205)

I think this can be done via https://github.com/semantic-release/git


Update README.md

@googlebot I signed it!
On Sat, Jul 4, 2020 at 12:45 PM googlebot<EMAIL_ADDRESS>wrote:

Thanks for your pull request. It looks like this may be your first
contribution to a Google open source project (if not, look below for help).
Before we can look at your pull request, you'll need to sign a Contributor
License Agreement (CLA).
📝 Please visit https://cla.developers.google.com/
https://cla.developers.google.com/ to sign.
Once you've signed (or fixed any issues), please reply here with @googlebot
I signed it! and we'll verify it.
What to do if you already signed the CLA Individual signers

It's possible we don't have your GitHub username or you're using a
different email address on your commit. Check your existing CLA data
https://cla.developers.google.com/clas and verify that your email is
set on your git commits
https://help.github.com/articles/setting-your-email-in-git/.

Corporate signers

Your company has a Point of Contact who decides which employees are
authorized to participate. Ask your POC to be added to the group of
authorized contributors. If you don't know who your Point of Contact is,
direct the Google project maintainer to go/cla#troubleshoot (Public
version https://opensource.google/docs/cla/#troubleshoot).
The email used to register you as an authorized contributor must be
the email used for the Git commit. Check your existing CLA data
https://cla.developers.google.com/clas and verify that your email is
set on your git commits
https://help.github.com/articles/setting-your-email-in-git/.
The email used to register you as an authorized contributor must
also be attached to your GitHub account
https://github.com/settings/emails.

ℹ Googlers: Go here
https://goto.google.com/prinfo/https%3A%2F%2Fgithub.com%2FGoogleContainerTools%2Fjib%2Fpull%2F2566
for more info.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/GoogleContainerTools/jib/pull/2566#issuecomment-653732384,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AO6AG2H3SM6BNOLJ4BFDPB3RZ3JJXANCNFSM4OQI2MYA
.


Symbol hiding when using GNU linker in the Meson build should be implemented

We're using a build_ext override in setup.py to insert a linker script that does symbol hiding for Python extension modules with GCC on Linux: https://github.com/scipy/scipy/blob/main/setup.py#L166-L206. See gh-8463 for why.
The script tools/check_pyext_symbol_hiding.sh is run in CI on Azure (see below CI config snippet), but not in combination with a Meson build yet:
- script: ./tools/check_pyext_symbol_hiding.sh build
  displayName: "Check dynamic symbol hiding works"
  condition: ne(variables['Build.SourceBranch'], 'refs/heads/main')
  failOnStderr: true

I just ran it locally on a Meson build and get:
$ ./tools/check_pyext_symbol_hiding.sh ./build-install/lib/python3.10/site-packages/scipy/linalg/_cythonized_array_utils.cpython-310-x86_64-linux-gnu.so: too many public symbols!
000000000005c550 T _fini
0000000000008000 T _init
000000000000d791 T PyInit__cythonized_array_utils
00000000000734a0 B __pyx_module_is_main_scipy__linalg___cythonized_array_utils

Note that the script exits after the first non-compliant extension module is encountered. If I delete this one, I get the same on the next .so. Meson does have a builtin feature for this: https://mesonbuild.com/Release-notes-for-0-48-0.html#keyword-argument-for-gnu-symbol-visibility and the description in https://mesonbuild.com/Reference-manual_functions.html#arguments9. If I try to use that, I then get:
$ ./tools/check_pyext_symbol_hiding.sh
./build-install/lib/python3.10/site-packages/scipy/linalg/_matfuncs_expm.cpython-310-x86_64-linux-gnu.so: too many public symbols!
0000000000050744 T _fini
0000000000008000 T _init
000000000000bdc7 T PyInit__matfuncs_expm

So that hides the B (global uninitialized data) symbols, but not the T (global text symbol) ones. (see this link) for symbol explanations).
I've also tried 'inlineshidden' instead of 'hidden' with the same result, plus a warning which seems to be a minor issue in Meson:
cc1: warning: command line option '-fvisibility-inlines-hidden' is valid for C++/ObjC++ but not for C

Trying on special/_specfun.<>.so gives me a huge amount of symbols, but I see the same in a conda-forge installed SciPy:

$ cd build-install/lib/python3.10/site-packages/scipy/
$ nm -D --defined-only special/_specfun.cpython-310-x86_64-linux-gnu.so
0000000000044560 T airya_
000000000001d7a0 T airyb_
000000000002b860 T airyzo_
0000000000019080 T ajyik_
000000000000dab0 T array_from_pyobj
0000000000037120 T aswfa_
00000000000458f0 T aswfb_
0000000000028a00 T bernoa_
00000000000288c0 T bernob_
000000000001af30 T beta_
00000000000264b0 T bjndd_
0000000000013040 T cbk_
000000000003cdd0 T cchg_
000000000001c430 T cerf_
000000000002c030 T cerror_
00000000000385b0 T cerzo_
00000000000182d0 T cfc_
00000000000174c0 T cfs_
0000000000015c90 T cgama_
0000000000049af0 T ch12n_
000000000003aeb0 T chgm_
0000000000038af0 T chgu_
000000000001afa0 T chgubi_
000000000001b820 T chguit_
000000000001be80 T chgul_
000000000001c150 T chgus_
000000000000fa50 T cik01_
0000000000039c80 T ciklv_
0000000000052bc0 T cikna_
0000000000022550 T ciknb_
000000000004d5f0 T cikva_
000000000004b580 T cikvb_
000000000002a4e0 T cisia_
000000000002a1a0 T cisib_
000000000001ad70 T cjk_
0000000000029620 T cjylv_
00000000000204d0 T cjynb_
000000000002e780 T cjyva_
00000000000328e0 T cjyvb_
0000000000027490 T clpmn_
00000000000398b0 T clpn_
0000000000050ee0 T clqmn_
000000000002ae20 T clqn_
0000000000039390 T comelp_
000000000000e7f0 T copy_ND_array
00000000000460c0 T cpbdn_
0000000000016210 T cpdla_
0000000000026820 T cpdsa_
0000000000054150 T cpsi_
000000000001e7d0 T cv0_
000000000002c880 T cva1_
000000000001f3a0 T cva2_
000000000001e360 T cvf_
000000000001e000 T cvql_
000000000001e250 T cvqm_
0000000000014440 T cy01_
00000000000485d0 T cyzo_
00000000000169a0 T dinf_
000000000000ef00 T dnan_
000000000001cad0 T dvla_
000000000001ce90 T dvsa_
0000000000045410 T e1xa_
0000000000011110 T e1xb_
000000000001a560 T e1z_
000000000003ac00 T eix_
000000000003adb0 T eixz_
000000000003a6d0 T elit_
000000000003a9c0 T elit3_
0000000000020180 T envj_
0000000000050690 T enxa_
00000000000501a0 T enxb_
000000000002be70 T error_
000000000002a400 T eulera_
000000000002c730 T eulerb_
000000000000eeb0 T F2PyCapsule_AsVoidPtr
000000000000eee0 T F2PyCapsule_Check
000000000000e810 T F2PyCapsule_FromVoidPtr
000000000000d700 T F2PyDict_SetItemString
000000000000d850 T F2PyGetThreadLocalCallbackPtr
000000000000d750 T F2PySwapThreadLocalCallbackPtr
000000000000ef10 T fcoef_
000000000004f6b0 T fcs_
0000000000044d30 T fcszo_
0000000000043c10 T ffk_
000000000005486c T _fini
0000000000026740 T gaih_
000000000001d740 T gam0_
00000000000112a0 T gamma2_
0000000000012d40 T gmn_
000000000004fe40 T herzo_
000000000003b630 T hygfx_
000000000003e190 T hygfz_
000000000001a000 T ik01a_
0000000000046b40 T ik01b_
0000000000042810 T ikna_
0000000000042bd0 T iknb_
000000000004ab00 T ikv_
00000000000394f0 T incob_
0000000000035260 T incog_
0000000000006000 T _init
0000000000042310 T itairy_
00000000000358d0 T itika_
00000000000354c0 T itikb_
0000000000047d30 T itjya_
0000000000047910 T itjyb_
0000000000038210 T itsh0_
000000000002ab40 T itsl0_
0000000000045ad0 T itth0_
000000000002d720 T ittika_
000000000002cfb0 T ittikb_
0000000000028f00 T ittjya_
0000000000028b30 T ittjyb_
0000000000028140 T jdzo_
0000000000054650 T jelp_
0000000000034aa0 T jy01a_
000000000001d140 T jy01b_
00000000000375c0 T jyna_
0000000000024000 T jynb_
0000000000023850 T jynbh_
0000000000024180 T jyndd_
0000000000035c90 T jyv_
000000000004a1d0 T jyzo_
0000000000011f50 T klvna_
0000000000048c20 T klvnb_
00000000000496b0 T klvnzo_
00000000000137f0 T kmn_
000000000002e490 T lagzo_
0000000000038f60 T lamn_
000000000002dab0 T lamv_
0000000000036db0 T legzo_
0000000000045d80 T lgama_
00000000000431b0 T lpmn_
00000000000165f0 T lpmns_
0000000000045550 T lpmv_
0000000000016cd0 T lpmv0_
0000000000047080 T lpn_
0000000000048380 T lpni_
0000000000026d30 T lqmn_
00000000000252f0 T lqmns_
0000000000045f30 T lqna_
000000000002d310 T lqnb_
0000000000020380 T msta1_
00000000000201f0 T msta2_
00000000000437a0 T mtu0_
0000000000053710 T mtu12_
0000000000065170 B _npy_f2py_ARRAY_API
0000000000049520 T othpl_
00000000000379d0 T pbdv_
0000000000050770 T pbvv_
0000000000047470 T pbwa_
00000000000169b0 T psi_spec_
000000000000d920 T PyFortranObject_New
000000000000d8c0 T PyFortranObject_NewAsAttr
0000000000064f80 D PyFortran_Type
000000000000caa0 T PyInit__specfun
00000000000135d0 T qstar_
000000000004fb80 T rctj_
0000000000048190 T rcty_
000000000001e630 T refine_
0000000000024580 T rmn1_
000000000001f9c0 T rmn2l_
00000000000252a0 T rmn2so_
0000000000025c70 T rmn2sp_
00000000000499c0 T rswfo_
000000000002a090 T rswfp_
0000000000044790 T scka_
0000000000014160 T sckb_
0000000000011770 T sdmn_
0000000000052590 T segv_
0000000000047200 T sphi_
0000000000024280 T sphj_
0000000000050490 T sphk_
000000000001f7c0 T sphy_
000000000001ccb0 T vvla_
0000000000011470 T vvsa_

The reason the symbols are visible in a conda build is because the check in setup.py probes for gcc/g++ in the compiler name, however the conda compilers are named like: x86_64-conda-linux-gnu-cc, x86_64-conda-linux-gnu-c++.
Looking at the build.ninja file, the C++ extensions seem to default to -fvisibility=hidden -fvisibility-inlines-hidden already in Meson. C and Fortran extensions do not. And the C++ extension modules still have a large number of symbols, so it looks like the effect of these flags is different from the linker script we're using.
This needs more investigation. It's a pretty niche issue, because no one complained about symbols not being hidden in the conda build. That said, we shouldn't regress on this so I marked it for 1.9.0.
The Meson docs link to https://gcc.gnu.org/wiki/Visibility, which says:
Some people may suggest that GNU linker version scripts can do just as well. Perhaps for C programs this is true, but for C++ it cannot be true - unless you laboriously specify each and every symbol to make public (and the complex mangled name of it), you must use wildcards which tend to let a lot of spurious symbols through. And you have to update the linker script if you decide to change names to the classes or the functions. In the case of the library above, the author couldn't get the symbol table below 40,000 symbols using version scripts. Furthermore, using linker version scripts doesn't permit GCC to better optimise the code.
The reason that that comment doesn't apply for Python extensions, I think, is that there's only a single PyInit_ symbol that needs to be public. Public symbols are coming from https://github.com/python/cpython/blob/75eee1d57eb28283a8682a660d9949afc89fd010/Lib/distutils/command/build_ext.py#L686-L698
@eli-schwartz do you have any insights or advice here?

In setup.py, you currently have the following logic:
For each extension:

given an extension named foo.bar
write a file link-version-foo.bar.map, with the text contents: {global: PyInit_foo_bar; local: *; };
pass '-Wl,--version-script=path/to/link-version-foo.bar.map' as a link_args

You can pass a version script as a link_args with Meson as well (perhaps first checking that the compiler get_argument_syntax() is gcc rather than msvc).
In the process, I suggest the following optimization. Rather than generating per-extension linker version maps containing the exact name of the PyInit function, simply use the following version map:
diff --git a/link-version-foo.bar.map b/link-version-pyinit.map
similarity index 61%
rename from link-version-foo.bar.map
rename to link-version-pyinit.map
index a82d35f..ceb90ae 100644
--- a/link-version-foo.bar.map
+++ b/link-version-pyinit.map
@@ -1,6 +1,6 @@
 {
     global:
-        PyInit_foo_bar;
+        PyInit_*;
     local:
         *;
 };

ld itself already supports wildcards, and you know you want all "PyInit_" style functions exported, and nothing else... so there's no reason to specialize the file for each extension, especially if it requires doing file I/O during the build.
Add e.g. version_link_args = ['-Wl,--version-script=' + meson.project_source_root() / 'link-version-pyinit.map']) and apply version_link_args to each extension_module().
In the long run it's on my TODO list to add support for passing an ld version script as a kwarg to library/shared_module/py.extension_module, and also smooth over handling for msvc/gcc/apple differences in how such things work (see for example GNU libtool's -export-symbols option).

Looking at the build.ninja file, the C++ extensions seem to default to -fvisibility=hidden -fvisibility-inlines-hidden already in Meson. C and Fortran extensions do not. And the C++ extension modules still have a large number of symbols, so it looks like the effect of these flags is different from the linker script we're using.

Note that they are indeed very different, because:

version scripts hide all symbols at link time, due to wildcard fallthrough
GCC symbol visibility hides whichever symbols you mark as internal/private at compile time, doing aggressive codegen optimizations in the process

Notice that in the above listed examples, you show:

a cythonized module, which exports an extraneous _fini and _init
a fortran module, which exports tons of functions

cython already behaves pretty well here IIRC, because it knows that it's generating python modules and optimizes the symbol table for this use case (everything is static).
Other code that isn't generated may very well need / be able to take advantage of gnu_symbol_visibility to hide everything other than PyMODINIT_FUNC (which automatically has Py_EXPORTED_SYMBOL applied).
Regardless, you do end up by default (and without the use of ld version scripts) with two text symbols that the compiler/linker implementation create for internal reasons, which may be ugly and may be unneeded but should not cause symbol clashes. These symbol clashes as per gh-8130 are the original reason for implementing this symbol hiding anyway. So I think you don't need to worry about those two symbols, particularly.
In that case, just using gnu_symbol_visibility may be fine.

Thanks for the detailed replies @eli-schwartz!

In the process, I suggest the following optimization. Rather than generating per-extension linker version maps containing the exact name of the PyInit function, simply use the following version map:

That makes sense. We can then also just store that script, rather than writing it out dynamically.

In that case, just using gnu_symbol_visibility may be fine.

Your analysis sounds right to me. I'm considering treating Cython extension modules the same as all other extension modules, which could be nice for review/maintenance. But on the other hand, using gnu_symbol_visibility will be slightly faster probably. I don't have a good feeling for how slow a linker script is, but probably negligible compared to overall build time.

I don't know that a linker script is meaningfully slow at link time.
On the other hand, symbol visibility has (some) runtime performance benefits. It can generate smaller code that doesn't have to go through the symbol table.
That might not be all that noticeably faster either, but every little bit helps and micro-optimization of runtime performance has bigger payoffs than micro-optimization of build-time performance.
...
Now I wonder if maybe Meson should default gnu_symbol_visibility to 'hidden' for py.extension_module, since we know that it should always work (python itself guarantees that the init function when declared via the Python macro uses public visibility where the compiler supports it).
Users who find that that "somehow" breaks (I can't think why but anything is possible) can of course manually set the kwarg to 'default' and get back the old behavior.

Now I wonder if maybe Meson should default gnu_symbol_visibility to 'hidden' for py.extension_module, since we know that it should always work

That sounds like a good idea.
Related: dependencies: [py3_dep] should probably also be added automatically. I can't think of a reason not to do that (any extension module should need this), and it would save a lot of boilerplate.

Other code that isn't generated may very well need / be able to take advantage of gnu_symbol_visibility to hide everything other than PyMODINIT_FUNC (which automatically has Py_EXPORTED_SYMBOL applied).

Now I wonder if maybe Meson should default gnu_symbol_visibility to 'hidden' for py.extension_module, since we know that it should always work (python itself guarantees that the init function when declared via the Python macro uses public visibility where the compiler supports it).

My attempts to add this by default ran into trouble. I tracked the trouble down to https://bugs.python.org/issue11410
Apparently, CPython only actually defined this since 3.9, despite the original patch to implement it being submitted in 2011. This makes it somewhat more compelling to have Meson handle it, in order to if/else based on the version... also looks like PyPy supported it since sometime in the 2.7 series.

Adding it conditional on Python version sounds useful indeed. We're dropping Python 3.8 in one year from now (https://numpy.org/neps/nep-0029-deprecation_policy.html), so it's not too far off to have complete support.

Your analysis sounds right to me. I'm considering treating Cython extension modules the same as all other extension modules, which could be nice for review/maintenance. But on the other hand, using gnu_symbol_visibility will be slightly faster probably. I don't have a good feeling for how slow a linker script is, but probably negligible compared to overall build time.

As discussed in https://github.com/scikit-build/scikit-build/issues/668 and https://github.com/scikit-build/scikit-build/pull/703 the linker script approach invalidates the required function markup to ensure that function level static variables are correctly fused across multiple compilation units.
In general the compile time visibility controls are the safest / correct approach as it allows projects to still express any required external unique symbols for correct execution. This doesn't happen with the linker script approach.

Yeah, if people want the linker script approach they are free to manually define it in their projects, but I wouldn't consider it reasonable to have Meson automatically define one you didn't ask for. Setting the default visibility is a much safer and more moderate approach (which I plan to implement).

I have posted a PR for Meson to set the default visibility: https://github.com/mesonbuild/meson/pull/10369

With gnu_symbol_visibility: 'hidden', which will arrive in Meson 0.63.0, more symbols indeed get hidden - although f2py is still a bit leaky. Currently:
$ nm -D --defined-only build/scipy/linalg/_flapack.cpython-310-x86_64-linux-gnu.so
000000000011c6d0 T array_from_pyobj
000000000011d410 T copy_ND_array
000000000011dad0 T F2PyCapsule_AsVoidPtr
000000000011db00 T F2PyCapsule_Check
000000000011d430 T F2PyCapsule_FromVoidPtr
000000000011c320 T F2PyDict_SetItemString
000000000011c470 T F2PyGetThreadLocalCallbackPtr
000000000011c370 T F2PySwapThreadLocalCallbackPtr
000000000011ba00 T f2pywrapclange_
000000000011b960 T f2pywrapdlamch_
000000000011b9d0 T f2pywrapdlange_
000000000011b980 T f2pywrapslamch_
000000000011b9a0 T f2pywrapslange_
000000000011ba30 T f2pywrapzlange_
000000000011db78 T _fini
0000000000027000 T _init
000000000020d998 B _npy_f2py_ARRAY_API
000000000011c540 T PyFortranObject_New
000000000011c4e0 T PyFortranObject_NewAsAttr
000000000020d780 D PyFortran_Type
000000000011b260 T PyInit__flapack
000000000011db20 T wcdotc_
000000000011db30 T wcdotu_
000000000011db60 T wcladiv_
000000000011db40 T wzdotc_
000000000011db50 T wzdotu_
000000000011db70 T wzladiv_

With gnu_symbol_visibility: 'hidden':
$ nm -D --defined-only build/scipy/linalg/_flapack.cpython-310-x86_64-linux-gnu.so
000000000011b9c0 T f2pywrapclange_
000000000011b920 T f2pywrapdlamch_
000000000011b990 T f2pywrapdlange_
000000000011b940 T f2pywrapslamch_
000000000011b960 T f2pywrapslange_
000000000011b9f0 T f2pywrapzlange_
000000000011db48 T _fini
0000000000027000 T _init
000000000011b220 T PyInit__flapack
000000000011daf0 T wcdotc_
000000000011db00 T wcdotu_
000000000011db30 T wcladiv_
000000000011db10 T wzdotc_
000000000011db20 T wzdotu_
000000000011db40 T wzladiv_

Cython also isn't always nicely clean. E.g. for _qmc_cy (both with and without gnu_symbol_visibility: 'hidden'):
$ nm -D --defined-only build/scipy/stats/_qmc_cy.cpython-310-x86_64-linux-gnu.so
0000000000029438 T _fini
0000000000008000 T _init
000000000000aa74 T PyInit__qmc_cy
0000000000035460 B __pyx_module_is_main_scipy__stats___qmc_cy
000000000000b3f0 W _ZNSt6thread11_State_implINS_8_InvokerISt5tupleIJPFP7_objectllll18__Pyx_memviewsliceS4_EllllS5_S4_EEEEE6_M_runEv
000000000000cb10 W _ZNSt6thread11_State_implINS_8_InvokerISt5tupleIJPFP7_objectllll18__Pyx_memviewsliceS5_EllllS5_S5_EEEEE6_M_runEv
000000000000b4a0 W _ZNSt6thread11_State_implINS_8_InvokerISt5tupleIJPFvPFd18__Pyx_memviewslicellERdS3_llP7_objectES5_St17reference_wrapperIdES3_llS8_EEEEE6_M_runEv
0000000000021da0 W _ZNSt6vectorISt6threadSaIS0_EE12emplace_backIJS0_EEERS0_DpOT_
0000000000021c20 W _ZNSt6vectorISt6threadSaIS0_EE17_M_realloc_insertIJS0_EEEvN9__gnu_cxx17__normal_iteratorIPS0_S2_EEDpOT_
0000000000021be0 W _ZNSt6vectorISt6threadSaIS0_EED1Ev
0000000000021be0 W _ZNSt6vectorISt6threadSaIS0_EED2Ev
0000000000032738 V _ZTINSt6thread11_State_implINS_8_InvokerISt5tupleIJPFP7_objectllll18__Pyx_memviewsliceS4_EllllS5_S4_EEEEEE
0000000000032750 V _ZTINSt6thread11_State_implINS_8_InvokerISt5tupleIJPFP7_objectllll18__Pyx_memviewsliceS5_EllllS5_S5_EEEEEE
0000000000032720 V _ZTINSt6thread11_State_implINS_8_InvokerISt5tupleIJPFvPFd18__Pyx_memviewslicellERdS3_llP7_objectES5_St17reference_wrapperIdES3_llS8_EEEEEE
000000000002d840 V _ZTSNSt6thread11_State_implINS_8_InvokerISt5tupleIJPFP7_objectllll18__Pyx_memviewsliceS4_EllllS5_S4_EEEEEE
000000000002d8c0 V _ZTSNSt6thread11_State_implINS_8_InvokerISt5tupleIJPFP7_objectllll18__Pyx_memviewsliceS5_EllllS5_S5_EEEEEE
000000000002d7a0 V _ZTSNSt6thread11_State_implINS_8_InvokerISt5tupleIJPFvPFd18__Pyx_memviewslicellERdS3_llP7_objectES5_St17reference_wrapperIdES3_llS8_EEEEEE
0000000000032790 V _ZTVNSt6thread11_State_implINS_8_InvokerISt5tupleIJPFP7_objectllll18__Pyx_memviewsliceS4_EllllS5_S4_EEEEEE
00000000000327b8 V _ZTVNSt6thread11_State_implINS_8_InvokerISt5tupleIJPFP7_objectllll18__Pyx_memviewsliceS5_EllllS5_S5_EEEEEE
0000000000032768 V _ZTVNSt6thread11_State_implINS_8_InvokerISt5tupleIJPFvPFd18__Pyx_memviewslicellERdS3_llP7_objectES5_St17reference_wrapperIdES3_llS8_EEEEEE

This seems to happen when using cdef extern from. For this module it's:
cdef extern from "<thread>" namespace "std" nogil:

Related discussion: https://github.com/cython/cython/pull/360
These are probably all safe. It may be worth seeing if anyone complains for 1.9.0, and working on improvements in f2py and cython if needed - that way this is no longer a scipy-only solution, but helps other projects too.

This may be at least loosely related to https://github.com/scipy/scipy/issues/16540, which is indeed causing problems for me with release process now that 0.63.0 is out.

That regression is now fixed, and going forward, the CI will be using a version of Meson that does GNU symbol visibility automatically so there should not be any further regressions that aren't caught in CI before merging.
Is this ticket now effectively solved, or is there further symbol hiding that should be done?

Is this ticket now effectively solved, or is there further symbol hiding that should be done?

I think code-wise we're probably good, however I still need to re-enable this in CI somehow. The tools/check_pyext_symbol_hiding.sh checks that there's exactly one public symbol, while with the Meson build we are now getting 3-4 symbols in most extensions (at least _fini and init) - plus with Cython and F2py many more, see 3 comments up.
I think I'd prefer to fix this in Cython/F2py though, and not re-enable the SciPy-specific linker script.

plus with Cython and F2py many more, see 3 comments up.

Ah, right.
As far as the fortran situation goes, does fortran have some equivalent to __attribute__((visibility ("default")))? Based on essentially zero knowledge of the subject, but looking at the symbol table and comparing it to the sources, it appears that as a general rule of thumb, if a fortran subroutine foo exists it gets exported in the shared library as the foo_ symbol. This is also evident in the symbol table for my openblas/lapack shared libraries.

As far as the fortran situation goes, does fortran have some equivalent to __attribute__((visibility ("default")))?

It doesn't look like it. I can't find anything useful on Fortran symbol visibility, not in the gfortran docs nor in a blog post or other such resource. I guess it has to be managed with either a linker script or a post-processing tool like patchelf.
Side note: after I saw in the the Meson 0.63.0 release notes that mold is now supported, I had a look at mold and found these notes interesting/relevant: https://github.com/rui314/mold/blob/main/docs/design.md#linker-script

I'll try to implement the linker script now. It doesn't seem difficult, just tedious because there's no way to do this globally for all Python extension modules.


KAFKA-9312: Wait for splitted batches to be processed after a KafkaProducer#flush()

This commit adds the logic to wait for splitted batches to be processed after a Message Too Large Exception has been received.
Also, add a new test class to cover IncompleteBatches class.
This code adds a new constructor to the classes ProducerBatch and RecordAccumulator visible to the package, this decouples the dependency between ProduceRequestResult and IncompleteBatches respectively and allow to test the method RecordAccumulator#awaitFlushCompletion()
The Jira ticket provides a test here that prove the error without these changes.
This PR does not include that specific test since it involves sleeping the thread and could lead to indeterminate behavior.

retest this please

Hi @lbradstreet this solves the bug reported by you at Jira, can you take a look, please?

@jonathansantilli thanks for the PR, and some much better test cases!
One potential problem with this approach is that in relatively degenerate cases, I do not think we are guaranteed that a record batch will not have to be split again. Given that we only wait for batches that are splitted after the first phase, I think we could still end up returning from the flush early. These cases are not ideal, given that splitting record batches is a relatively expensive process requiring multiple round trips, but I believe it's still possible in cases where compression predictions are way off.
A second lesser problem is that we can end up waiting on batches that were not sent before the flush call, but ended up being split.
The only way I can think of to solve the above problems are to have the produceFuture(s) be considered completed when their children (split) batches are all completed. In this design, awaitFlushCompletion could likely stay as it is, and we would not end up waiting for batches that had not been produced at the time of the flush call, or end up returning too early in cases where multiple splits have occurred.

Thanks a lot for your reply @lbradstreet, about your comments:

"...I do not think we are guaranteed that a record batch will not have to be split again."
Oh, this is not the behavior I was expecting, I guess the design should have a reason for that. Although I have no much experience with this code, I thought after a batch is splitted, I will be splitted on N baches whose size is less than the configured/desired batchSize, for each new batch.
I think I need to check that part of the code to understand it better. Thanks for the heads-up.

"A second lesser problem is that we can end up waiting on batches that were not sent before the flush call, but ended up being split."
I think even today we have the same issue/behavior
According to the documentation:
"Other threads can continue sending records while one thread is blocked waiting for a flush call to complete, however no guarantee is made about the completion of records sent after the flush call begins."

About your proposal, If I got it right, we need a way to track each batch and children (splitted batches) created after the original batch.
Something like:

Batch_1 creates Batch_2 and Batch_3
-- Batch_1 needs to wait for Batch_2 and Batch_3 to be finished.
Batch_2 creates Batch_4
-- Batch_2 needs to wait for Batch_4 to finish

So, each ProducerBatch.produceFuture has associated with itself, each ProducerBatch (children) created after receiving a RecordBatchTooLargeException
I will revise the code, please tell me whatever comes to your mind after this comment or future thoughts.
BTW, Happy new year!

Thanks a lot for your reply @lbradstreet, about your comments:

"...I do not think we are guaranteed that a record batch will not have to be split again."
Oh, this is not the behavior I was expecting, I guess the design should have a reason for that. Although I have no much experience with this code, I thought after a batch is splitted, I will be splitted on N baches whose size is less than the configured/desired batchSize, for each new batch.
I think I need to check that part of the code to understand it better. Thanks for the heads-up.

Actually, you may be right that it will only split by the producer's configured batch.size. If this size is still too large, then it may not be able to split it further anyway, if this is the way that it splits, as it may end up making the same choices as before? I'm not positive though, I believe the compression estimates make this pretty non-deterministic, so it would be good to investigate this further before going ahead with any of the changes I've suggested.

"A second lesser problem is that we can end up waiting on batches that were not sent before the flush call, but ended up being split."
I think even today we have the same issue/behavior
According to the documentation:
"Other threads can continue sending records while one thread is blocked waiting for a flush call to complete, however no guarantee is made about the completion of records sent after the flush call begins."

That is true, though I think we may end up waiting longer in this case, since we will wait for the first set of futures to complete before building the list of the second (split) set of futures. On the positive side, your code doesn't retry the overall awaitFutureCompletion, which wouldn't be guaranteed to ever complete if other threads continue to produce messages at the same time.

About your proposal, If I got it right, we need a way to track each batch and children (splitted batches) created after the original batch.
Something like:

Batch_1 creates Batch_2 and Batch_3
-- Batch_1 needs to wait for Batch_2 and Batch_3 to be finished.
Batch_2 creates Batch_4
-- Batch_2 needs to wait for Batch_4 to finish

So, each ProducerBatch.produceFuture has associated with itself, each ProducerBatch (children) created after receiving a RecordBatchTooLargeException

Yes, that's the idea. Essentially when Batch_2 and Batch_3 are completed, Batch_1's future would end up being completed too. It'd be worth checking whether any code other than awaitFlushCompletion depends on the split batch's future being completed to ensure that it isn't processed further. It would obviously be bad if the producer code could end up retrying and re-splitting a batch more than once because we did not set the original batch to done after the first split.

I will revise the code, please tell me whatever comes to your mind after this comment or future thoughts.
BTW, Happy new year!

Great! thanks for the reply, am doing some changes and I will take this into consideration:

It'd be worth checking whether any code other than awaitFlushCompletion depends on the split batch's future being completed to ensure that it isn't processed further

retest this please

Hello, @lbradstreet please take a look at the additions/updated and let me know what you think, please.

retest this please

@jonathansantilli thanks, I'll give it a look :).

Thanks for the PR. I will try to take a look before end of day

retest this please

retest this please

retest this please

Thanks for looking at the PR @abbccdda about you comment I did not add @lbradstreet test to this PR, as I explain in the PR description:

The Jira ticket provides a test here that proves the error without these changes.
This PR does not include that specific test since it involves sleeping the thread and could lead to indeterminate behavior.

However, I can add another test where the batch gets splitted twice.

retest this please

Hi @jonathansantilli . Are you still working on this PR?

Hi there @d8tltanc sorry about the delay with my reply.
I would like to continue working on this PR. There was some consensus at the beginning about a possible solution, the one implemented in this PR, but then @lbradstreet raised some valid concerns about possible locking.
I did ask for some guidance to implement the needed changes but I guess this PR got forgotten.
Would be fantastic to get some input from the people mentioned in this PR.

@jonathansantilli are you willing/able to work on this still?

Hi @kirktrue, yes, I was pending on @lbradstreet guidance or anyone else since there was a potential blocking issue.


Improved pretty

Hi @apdavison These pretty representations are only used by the ipython lib or is there any way on how these are used by python itself? What is the advantage of having this verbose representation instead of the __repr__ implementation?

Yes, these are used in IPython and Jupyter notebooks. Python also has the pprint module. This PR is basically just improving the "pretty" representations for Epoch, Event and SpikeTrain; the representations for AnalogSignal, Segment, Block are already ok.


Some image sizes not working

First of all, thank you for this repo, it is by far the best html renderer for React Native that I've tried.
The problem I'm having is that not all images are being sized correctly. I'm using the  Dimensions.get('window').width trick but some images are rendered at full size and spill off the screen. I'm not sure exactly what the cause is but it seems to only apply to images who have their sizes specified in this format: sizes: "(max-width: 100px) 100vw, 603px"
I'm building a rss feed reader using the Feedly API so I've been noting which feeds give me problems with their images and they all have that sizing format in common. Some examples of the feeds that do this:
https://postsecret.com/
https://waitbutwhy.com/
http://www.poorlydrawnlines.com/
Here's a screencap of the debug output when the screen is rendered:

And the html I'm rendering look like this:

I'm sure I didn't do a great job explaining all this but I'm happy to provide any additional information needed to figure this out.

I don't know if this is a related issue but all youtube embedded videos also spill off the screen.
Oh and I'm currently using 3.5.0-rc.3 of react-native-render-html

Hi @chadmorrow, thanks for the kind words !
As documented in the README :

Please note that if you set width AND height through any mean of styling, imagesMaxWidth will be ignored.

In your example with the ghost comic, you do have height and width, so imagesMaxWidth isn't doing anything.
It resizes properly as long as I remove them

I'm not sure what's the best in your situation, because I guess you can't make sure these attributes aren't in your HTML. Well, you could use alterChildren to remove them but it feels like hacking. I really think height and width should override anything if they're supplied.
Please tell me if you have some ideas to resolve this.
Regarding your other issue, at the moment, there is no behavior regarding  to make sure it's not rendered off-screen, it depends on height and width attributes, or defaults to 200x200, which is kinda terrible I guess.
It would be nice to add a fallback depending on the width of the screen instead of a static value.

Oh, the iframe issue might just be a misunderstanding on my part. I thought I had read on a different issue that had been closed that there was support added for iframes similar to images but now I don't see where I would have read that.
Thanks for looking into the issue with the images. I can't quite figure out why the height and width attributes are always set to 1 on some of these problem images and it doesn't seem to matter what I try to override them to, they always render full size. I'll keep working on it though and let you know if I figure anything out. Thank you again for taking the time to look into this!

When I request the image of your example it's actually a 1x1 image, so your issue must come from your feed.
I'll think about improving the iframe renderer and keep you posted.

I improved the iframe renderer in 3.5.0. It's not perfect, but at least, iframes cannot be rendered with a width superior to your device's viewport. That's a little better, but for advanced usage you'll need to write your own renderer.
Feel free to re open another issue if your image rendering problem actually comes from this plugin.

The image size issue is still a problem for me as well. It seems like this did not get resolved

@Stevevelt
Try this

Try adding ignoredStyles


Typescript support

It would be nice to have typescript/tslint  support as part of the configuration

This feature request is available on Nuxt.js community (#c16)

I suggest a refinement of tyoescript-template containing vuex-typex and cleaned up dependencies.

Hmm. I didn't read it all and misunderstood the enhancement request.

It would be great to incorporate existing nuxt-community/typescript-template inside create-nuxt-app
As far as I understand the related issue was already logged by @pkej

Indeed, we need to finish @nuxtjs/typescript so we will able to add it inside create-nuxt-app.

cc @breakingrobot

I'm currently exploring Nuxt for a new project and was wondering if there was any update on TS support? Thanks!

@karellm not a lot, we still have a long way to go with TS. In case you plan to build full-featured heavy SPA - TS currently is not the way to go since you will face quite a lot of bugs in Nuxt dependencies, most of which weren't even build with TS in mind, but again, that's just my experience.

@AndrewBogdanovTSS Thanks for sharing. I wanted to give TS a spin but I guess it will wait.

Does the create-nuxt-app support typescript now？

can use this package (https://github.com/wagerfield/nuxt-typescript) to configure the typescript, but may I know any support for typescript with express and nuxt?

I am currently working on adding features choice like in vue cli 3 (typescript, pwa, tests etc...). Though it will probably take some time to do them all, typescript will probably be done in a few days.
Please tell me if someone else is already working on it.

@sascha245 thanks for the work! I was wondering how to implement typescript with nuxt+express server (not a middleware), but only on server side. I am talking about something like this (https://github.com/pronist/nuxt-express-typescript-template), but since I am very bad with build tools like webpack and backpack, I am struggling to figure it out. (the example below looks outdated and I am hesitant to use this one). Maybe you will look into the issue and add the feature like this? I mean typescript support for the custom server. Thanks in advance!

Will typescript support land on nuxt-create-app?

First of all, Kudos to Nuxt team for Nuxt 2.4.0 and TypeScript integration! Being new to Nuxt, I tried a Nuxt+TypeScript project thanks for Hackernews-nuxt-ts and this helloworld
Nightmare started with testing, especially with Babel 6 -> 7 / Jest 23.6.0 -> 24.1.0 especially with [ts] cannot find module ... [2307] in testing files, please check this issue.

Question 1: Will the create-nuxt-app with TypeScript starts at Jest 24+?
Question 2: Apart from adding TypeScript specific dependencies, the only point would be fixing the point mentioned above by updating @nuxt/typescript/tsconfig and adding a ts-shim.d.ts. But I don't know where to comment it 😆
Question 3: How about migration of existing projects? I guess it should be handled in nuxt/docs?

Should use ESLint instead of TSLint: https://cmty.app/nuxt/nuxt.js/issues/c8742

@envision, I second that. We just switched from TSLint to ESLint within our nuxt project. The current ESLint config can be found over at https://gist.github.com/riddla/6e892375ff373cdc457bbf93da39ef58.

Nuxt 2.5 is out with typescript improvements! Is it time to get typescript support ?

It's been 2 months without an update here. When can we realistically expect TS as an option with create-nuxt-app?

Ping

I can't promise anything, but now that https://github.com/nuxt/nuxt.js/pull/5858 is through, we could tackle that issue :+1:

Nuxt 2.9 is out. I think the community needs this typescript option asap. Let's do it! 🎉

FYI for those interested, Next.js now supports TypeScript by default, no plugins or config needed:

https://nextjs.org/blog/next-9#built-in-zero-config-typescript-support

I just stumbled upon nuxt-app-ts. My problem is solved. Just try:
yarn create nuxt-app-ts you_app_name

or
npx create-nuxt-app-ts <my-project>

or
npm init nuxt-app-ts <my-project>

@coolsam726 unofficial library, with old version of nuxt (last updated 5 months ago) it's not the solution.
  "dependencies": {
    "nuxt": "^2.6.2",
    "vuetify": "^1.5.2"
  },

Have you seen https://typescript.nuxtjs.org/ ?

another pr being worked XD tracking #328 might be helpful

typescript-template https://github.com/nuxt-community/typescript-template

Implemented in #328


Checksum the volume name when the data mount point is created in the local driver

To avoid issues with unexpected volume names, we checksum the user input.
It keeps backwards compatibility by letting paths created before docker 1.9 to
remain as they are.
Closes #16132
Closes #16140
/cc @tiborvass, @thaJeztah
Signed-off-by: David Calavera<EMAIL_ADDRESS>

@calavera some tests are failing, I think we should base64-it so that information is not lost.

I don't like this


cannot import name 'ldos' from 'quspin.tools.measurements'

Describe the bug
A clear and concise description of what the bug is.
To Reproduce
Write a self-contained minimal code here to reproduce the bug.
Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):

OS: [e.g. iOS]

Additional context
Add any other context about the problem here.

I have installed quspin module by using "conda install -c weinbe58 quspin", tried uninstalling and installing again. Still I am getting errors " ImportError: cannot import name 'ldos' from 'quspin.tools.measurements' "

try the most recent version, quspin 1.0.0 (see docs for install instructions)


mujoco on GPU support

Hello!
After observing some of the samples of fully GPU training of OmniIsaccGymEnv, I noticed that the fully GPU traning system is the way to achive fastest traning method for any small physical interactions.
Typically, small Envirounments like Ant, Humanoid walking   can run  up to 4000 instancess in a single GPU in real -time.
Traning time also a lot more faster.
Any plans to support Mujoco on GPU? .

Hi,
May I ask why you closed this thread as completed? Did you find out any solutions?
Thank you.

Hi,
May I ask why you closed this thread as completed? Did you find out any solutions?
Thank you.

Hey!
After seeing  this closed issue
https://github.com/deepmind/mujoco/issues/85 , I noticed that the team is not actively involved to implament GPU version of MUJOCO.
My solution is just stick with Phyx 5.1 and Isacc gym. Since even for Nvidia team , it's too hard to properly implament GPU Physics version for low spec GPUs. only High end GPUs that have large VRAM can properly train on only inside a  GPU.
It might take too much time to implement mujoco-GPU to all  GPU vendors for OpenAI team.  And this requires high-end gpu all the time to simulate large environments and train them in a single GPU

Hi,
May I ask why you closed this thread as completed? Did you find out any solutions?
Thank you.

Hey! After seeing this closed issue #85 , I noticed that the team is not actively involved to implament GPU version of MUJOCO.
My solution is just stick with Phyx 5.1 and Isacc gym. Since even for Nvidia team , it's too hard to properly implament GPU Physics version for low spec GPUs. only High end GPUs that have large VRAM can properly train on only inside a GPU.
It might take too much time to implement mujoco-GPU to all GPU vendors for OpenAI team. And this requires high-end gpu all the time to simulate large environments and train them in a single GPU

Got it, thank you for the elaborated reply! I am also looking for a solution to boost up my RL + MuJoCo. Will try Isacc gym as well.


[Enhancement] Blast Mask with Powder Keg

Adds an enhancement that allows the Blast Mask to utilize Powder Keg explosive properties.

Build Artifacts

2ship-linux.zip
2ship-mac.zip
2ship-windows.zip

ahh it's beautiful! thanks!


Need a 'QUALIFIED_DIRTY' meta field to use in versionPattern definitions

Given a versionPattern definition as follows:
<versionPattern>${M}.${m}.${meta.COMMIT_DISTANCE}${-~meta.QUALIFIED_BRANCH_NAME}${-~meta.DIRTY}</versionPattern>

building on a branch feat/optimize-parsing yields:
demo 0.1.3-feat_optimize_parsing-false

when the commit is clean, and:
demo 0.1.3-feat_optimize_parsing-true

when the commit is dirty.
In order to maintain the previous behavior, I would like a new metadata setting ${meta.QUALIFIED_DIRTY} (or whatever you deem fit) that would behave as follows when put into the versionPattern definition string:
<versionPattern>${M}.${m}.${meta.COMMIT_DISTANCE}${-~meta.QUALIFIED_BRANCH_NAME}${-~meta.QUALIFIED_DIRTY}</versionPattern>

demo 0.1.3-feat_optimize_parsing

when the commit is clean, and:
demo 0.1.3-feat_optimize_parsing-dirty

when the commit is dirty.
If it isn't obvious at this point, I would like a way to append the word "dirty" to the version only when dirty is true, instead of "true/false", depending on the state of dirty.
Thank you.

[isn't [Metadatas.DIRTY_TEXT] what you are looking for?(https://github.com/jgitver/jgitver/blob/c7895668a5f27389bf208139fc565defdb64fd78/src/main/java/fr/brouillard/oss/jgitver/metadata/Metadatas.java#L37)

See: https://github.com/jgitver/jgitver.github.io/pull/4

thanks


Fixed #32145 - More helpful error, creating app locale if doesn't exist

https://code.djangoproject.com/ticket/32145
NOTE: I am currently working on the CLA document, I will update here when that is complete

CLA document has been signed, and approved... review away 👍

Any progress on this?

I'll try and finish this today @chinmoy12c

I'll try and finish this today @chinmoy12c

Oh sure no problem :)

@chinmoy12c it has been updated... I'll update the ticket now... it looks like the build is failing because of some expired git token or something?

@chinmoy12c it has been updated... I'll update the ticket now... it looks like the build is failing because of some expired git token or something?

DK maybe 🤔🤔

@jacobtylerwalls any idea how to fix this?
git fetch --no-tags --progress --depth=1 -- git://github.com/django/django.git +refs/pull/13616/merge:refs/remotes/origin/pull/13616/merge # timeout=10
ERROR: Error fetching remote repo 'origin'
hudson.plugins.git.GitException: Failed to fetch from git://github.com/django/django.git
	at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:996)
	at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1237)
	at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1297)
	at hudson.scm.SCM.checkout(SCM.java:505)
	at hudson.model.AbstractProject.checkout(AbstractProject.java:1206)
	at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:637)
	at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
	at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:509)
	at hudson.model.Run.execute(Run.java:1907)
	at hudson.matrix.MatrixRun.run(MatrixRun.java:153)
	at hudson.model.ResourceController.execute(ResourceController.java:97)
	at hudson.model.Executor.run(Executor.java:429)
Caused by: hudson.plugins.git.GitException: Command "git fetch --no-tags --progress --depth=1 -- git://github.com/django/django.git +refs/pull/13616/merge:refs/remotes/origin/pull/13616/merge" returned status code 128:
stdout:
stderr: error: object file .git/objects/0a/bf58741c15a5a2786f99be8372150d6a010d8f is empty
fatal: loose object 0abf58741c15a5a2786f99be8372150d6a010d8f (stored in .git/objects/0a/bf58741c15a5a2786f99be8372150d6a010d8f) is corrupt

Usually when CI blows up it's just result of a very low-level test having to do with caches or timeouts not going perfectly. I would just push to your branch again to get a fresh build. Since you'll be pushing again, I suggest taking the opportunity to rebase and squash the commits.

Ok, yeah I rebased already, but I'll squash the commute :)

@jacobtylerwalls this is ready for another review :)

@thatnerdjosh Do you have time to keep working on this?

@thatnerdjosh Do you have time to keep working on this?

Of course, are we experiencing another issue related to it?

Of course, are we experiencing another issue related to it?

Please check my comments.

Please check my comments.

@thatnerdjosh Do you have time to keep working on this?

I just saw your comments from 8 days ago, oddly it didn't notify me of these comments, I'll address these

@thatnerdjosh Do you have time to keep working on this?

I just saw your comments from 8 days ago, oddly it didn't notify me of these comments, I'll address these

@thatnerdjosh I pushed edits.

@felixxm ok... Apologies about my delay in getting back to this, been really busy at the new job it's been all I can think about

np


Fix internal memory leaks from OPENSSL_MALLOC_FAILURES

There is a rarely used feature that can be enabled with ./config enable-crypto-mdebug when additionally the environment variable OPENSSL_MALLOC_FAILURES is used. It turns out to be possible that CRYPTO_zalloc may create a leak when the memory is allocated and then the shouldfail happens, then the memory is lost.
Likewise when OPENSSL_realloc is used with size=0, then the memory is to be free'd but here the shouldfail check is too early, and the failure may prevent the memory to be freed thus creating a bogus memory leak.

ok, removed 1.1.1

This pull request is ready to merge

Merged to master, 3.0 and 3.1. Thank you.


Update links to new content on Read-Scale for Windows AG

Correcting incorrect reference to link I added in PR #690
Adding new content page to the TOC for AG/Windows.

@wsmelton : Thanks for your contribution! The author, @MikeRayMSFT, has been notified to review your proposed change.

@wsmelton it seems like we've got a merge conflict - probably because we updated TOC.md while you were updating TOC.md. Can you clarify what the change is here. The new content you provided in the earlier PR is already in the live table of contents. It just came in a later PR.
Thanks again for your contribution.

Yeah we can close this out since it already got updated... Don't know if the additional link on the other page is really necessary?

#please-close

@wsmelton -  I see the other change you were making I'll make that for you. Thanks.