Piece wise beadmotifconnector

Used pragma once
Const correctness applied
Improved testing
noexcept keyword added where appropriate
assertion test added in appropriate method

@JensWehner hey can you take a look when you get the chance?

I believe it is a better practice. For instance if you build the project and it has previously installed it can link to the wrong files.

It is safer to reserve global reference for the other repositories, and use the relative include paths internally, it doesn't look as nice though.

I think it doesn't hurt, we add the local include path here anyhow:
https://github.com/votca/csg/blob/master/src/libcsg/CMakeLists.txt#L32

My wording is probably a bit off, <> notation looks somewhere on the system, whereas "" will look in the current repo.

I have had issues with this in the past but I am not sure if they were before or after those lines were placed in the flame file.

@JensWehner please review

Ping @JensWehner


feat(esl-event-listener): add condition descriptor property to legally prevent subscription

Closes: #1947

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


When I run it I dont see the map

When I run  the webpack plugin sample, there is no map. just an interface with:
Winter
Spring
Summer
Fall
Flash Floods by Season
Flash Flood Warnings (2002 - 2012)

Hi @ionara  try updating webpack and webpack-cli then trying again.
Note that we also have an ES modules sample that you can try: https://github.com/Esri/jsapi-resources/tree/master/esm-samples/webpack.

I updated them and I got this error:
Using arcgis-js-api version: 4.18.1
[webpack-cli] TypeError: cli.isValidationError is not a function
at Command. (E:\Projects\WebpackEsri\node_modules@webpack-cli\serve\lib\index.js:97:25)
at async Promise.all (index 1)
at async Command. (E:\Projects\WebpackEsri\node_modules\webpack-cli\lib\webpack-cli.js:708:13)
PS E:\Projects\WebpackEsri>
Here is the package.json
{
"name": "demo",
"version": "0.0.1",
"devDependencies": {
"@arcgis/webpack-plugin": "~4.18.0",
"@types/sinon": "^9.0.7",
"@typescript-eslint/eslint-plugin": "^4.9.0",
"@typescript-eslint/parser": "^4.9.0",
"clean-webpack-plugin": "~3.0.0",
"copy-webpack-plugin": "~6.3.2",
"css-loader": "~5.0.1",
"eslint": "^7.14.0",
"eslint-config-prettier": "^6.15.0",
"eslint-plugin-prettier": "^3.1.4",
"html-loader": "~1.3.2",
"html-webpack-inline-source-plugin": "~0.0.10",
"html-webpack-plugin": "~4.5.0",
"husky": "~4.3.0",
"lint-staged": "~10.5.2",
"mini-css-extract-plugin": "~1.3.1",
"prettier": "^2.2.1",
"resize-observer-polyfill": "^1.5.1",
"resolve-url-loader": "~3.1.2",
"style-loader": "~2.0.0",
"terser-webpack-plugin": "~5.0.3",
"ts-loader": "~8.0.11",
"tslib": "~2.0.3",
"typescript": "~4.1.2",
"webpack": "^5.9.0",
"webpack-cli": "^4.3.1",
"webpack-dev-server": "~3.11.0"
},
"license": "Apache-2.0",
"scripts": {
"precommit": "lint-staged",
"start": "webpack serve --mode development",
"build": "webpack --mode production",
"prettier": "prettier --write "src//*.ts?(x)"",
"lint": "eslint --fix "src//.ts?(x)""
},
"lint-staged": {
".{ts,tsx}": [
"prettier --write",
"eslint --fix"
]
},
"eslintConfig": {
"parser": "@typescript-eslint/parser",
"plugins": [
"@typescript-eslint"
],
"extends": [
"eslint:recommended",
"plugin:@typescript-eslint/eslint-recommended",
"plugin:@typescript-eslint/recommended",
"prettier/@typescript-eslint",
"plugin:prettier/recommended"
]
},
"prettier": {
"singleQuote": true,
"tabWidth": 4
},
"arcgis": {
"type": "jsapi"
},
"dependencies": {
"arcgis-js-api": "~4.18.0"
}
}

Awesome, I'll close this out. TypeError: cli.isValidationError is not a function is a known webpack-cli problem that was fixed at<EMAIL_ADDRESS>We'll update the sample.


Waiting for http-01 challenge propagation: wrong status code '403', expected '200'

Waiting for http-01 challenge propagation: wrong status code '403', expected '200'
cert-manager-version: v0.15.1
In challenge stage. Please help us.

I recommend https://cert-manager.io/docs/faq/troubleshooting/

/triage support


WALSMatrixFactorization: Input matrix is not invertible. node cond/MatrixSolve

System information

Custom code: Yes
OS Platform and Distribution (e.g., Linux Ubuntu 16.04): Ubuntu 18.04
Mobile device: Noe
TensorFlow installed from (source or binary): binary
TensorFlow version (use command below): v1.13.0-rc2-0-gc865ec5621 / 1.13.0-rc2
Python version: 3.6
Bazel version (if compiling from source):
GCC/Compiler version (if compiling from source):
CUDA/cuDNN version:
GPU model and memory:

Describe the current behavior
Factorizing a small 4x4 (dense) matrix with WALSMatrixFactorizaion results in the following error:

InvalidArgumentError (see above for traceback): Input matrix is not invertible.
[[node cond/MatrixSolve (defined at /home/milad/PycharmProjects/wals_rec/temp.py:55) ]]

Describe the expected behavior
Factorize the matrix and evaluate without the error.
Code to reproduce the issue
import numpy as np
import tensorflow as tf
from tensorflow.contrib.factorization import WALSMatrixFactorization
import shutil

def make_input_fn(args):

	def to_sparse(values):
		indices = np.array([[0], [1], [2], [3]], dtype=np.int64)
		sp_tensor = tf.SparseTensor(indices=indices, values=values, dense_shape=values.shape)
		return sp_tensor

	def _input_fn():
		rows_dataset = tf.data.Dataset.from_tensor_slices(args['matrix_values']). \
			map(map_func=to_sparse). \
			repeat(count=None). \
			batch(batch_size=args['batch_size'])

		cols_dataset = tf.data.Dataset.from_tensor_slices(np.transpose(args['matrix_values'])). \
			map(map_func=to_sparse). \
			repeat(count=None). \
			batch(batch_size=4)

		features = {
			WALSMatrixFactorization.INPUT_ROWS: rows_dataset.make_one_shot_iterator().get_next(),
			WALSMatrixFactorization.INPUT_COLS: cols_dataset.make_one_shot_iterator().get_next(),
			WALSMatrixFactorization.PROJECT_ROW: tf.constant(True, name="PROJECT_ROW")
		}
		return features, None

	return _input_fn

def train_and_evaluate(args):

	def experiment_fn(output_dir):
		return tf.contrib.learn.Experiment(
			tf.contrib.factorization.WALSMatrixFactorization(
				num_rows=args["nrows"],
				num_cols=args["ncols"],
				row_weights=None,
				col_weights=None,
				regularization_coeff=0,
				embedding_dimension=args["n_embeds"],
				model_dir=output_dir),
			train_input_fn=make_input_fn(args),
			eval_input_fn=make_input_fn(args),
			train_steps=10,
			eval_steps=1,
			# Error doesn't happen if min_eval_frequency > train_steps
			min_eval_frequency=5)

	from tensorflow.contrib.learn.python.learn import learn_runner
	learn_runner.run(experiment_fn=experiment_fn, output_dir=args["output_dir"])

if __name__ == '__main__':

	K = 4
	args = {
		'ncols': K,
		'nrows': K,
		'output_dir': 'wals_temp',
		'n_embeds': 2,
		'n_steps': 5,
		'batch_size': K,
		'matrix_values': np.array([[1, 2, 3, 4],
								   [2, 4, 8, 12],
								   [3, 6, 7, 13],
								   [3, 5, 7, 9]], dtype=np.float32)

	}

	shutil.rmtree(args['output_dir'], ignore_errors=True)
	train_and_evaluate(args)

Other info / logs
The error happens on this line. The cause seems to be that the (column) Gramian suddenly becomes zero during evaluation and therefore the lhs of the normal equation is not invertible (training steps run fine). I confirmed this by running it step by step and using tfdbg.

Issue replicating with TF version-1.13,please find the gist of collab .Thanks!

Thanks for getting back. Do you mean you were not able to replicate the problem with TF 1.13?
Here is (part of) what I get when I run the collab you created.

InvalidArgumentError: Input matrix is not invertible.
[[{{node cond/MatrixSolve}}]]
During handling of the above exception, another exception occurred:
InvalidArgumentError                      Traceback (most recent call last)
/usr/local/lib/python3.6/dist-packages/tensorflow/python/client/session.py in _do_call(self, fn, *args)
1368           pass
1369       message = error_interpolation.interpolate(message, self._graph)
-> 1370       raise type(e)(node_def, op, message)
1371
1372   def _extend_graph(self):
InvalidArgumentError: Input matrix is not invertible.
[[node cond/MatrixSolve (defined at :49) ]]

Hi There,
We are checking to see if you still need help on this, as you are using an older version of tensorflow which is officially considered end of life . We recommend that you upgrade to the latest 2.x version and let us know if the issue still persists in newer versions. Please open a new issue for any help you need against 2.x, and we will get you the right help.
This issue will be closed automatically 7 days from now. If you still need help with this issue, please provide us with more information.


Update fuzz corpora to latest commit

I wonder if the corpora files need to be merged to the 3.0 and 3.1 branches as well
since #20243 was merged there and the x509 files not updated, or was that too eager?

This should get merged in all branches.

This should get merged in all branches.

This cannot get merged to all branches as it will conflict. A separate PR will be needed for 3.1 and 3.0 branches.

@t8m is there a reason you didn't remove the approval: otc review pending label?

This pull request is ready to merge

Merged to the master branch. Thank you for your contribution.


Some missing Boost Build constructs in generated tests for CMake for 1.64 branch

In looking at the Boost Build jamfile for tests in preprocessor, tti, and vmd I noticed a number of Boost Build constructs that are left out of the conversion to CMake, but which should have CMake equivalents. I do not know if you are generating the CMakeLIsts.txt files manually for each library or whether you have a script for doing so, but if it is the latter perhaps these conversion facilities from Boost Build to CMake can be added. Or perhaps you can offer some bcm equivalents for some of these things to ease the manual conversion which individual library developers will have to do in generating the correct CMake test scripts from their Boost Build equivalents.

Boost Build has the notion of a 'project' rule. The main use for the 'project' rule is to be able to specifying build requirements to each rule in the jamfile. For testing purposed the use of 'project' rule requirements is largely so that the same requirement for each individual test does not have to be repeated again and again. I believe the equivalent to this in CMake is the ability to set build properties for the entire CMakeLists.txt rather than to set target properties. I know the official Daniel Pfeiffer document frowns on setting global properties as opposed to specific target properties, but this is nonsense as far as I am concerned. If you have a group of tests, why should you have to repeat the same build requirement for each and every test repeatedly when you can set the build requirement once for all the tests. In your conversion from Boost Build to CMakeLists.txt you ignored the 'project' rule entirely.

Boost Build has the notion of conditional requirements using the property:property syntax. This is the equivalent of testing for some value in CMake with an 'if(something)', and then setting some CMake value based on that test. I noticed that you ignored conditional requirements completely in your converted CMakeLists.txt files for library tests.

Boost Build has the ability to specify particular compiler and compiler/version pairs directly using the notation 'compiler_id-optional_version_string'. This is the equivalent of CMake variables CMAKE_CXX_COMPILER_ID and CMAKE_CXX_COMPILER_VERSION, but with different compiler ids and with slightly different version string notations. Often in Boost Build the notation is used with conditional requirements to set a property based on the compiler or compiler/version being used in the compile. This is very useful for test when it is known that some compiler will fail a test unless some compiler option is set correctly.

I have brought up these three issues simply to explain why your CMakeLists.txt files for library tests might fail. You have done a great job with bcm and your work of creating CMake files for Boost using bcm, and should be commended. My major concern is that the more library developers ( like me ), who are not CMake experts like you, have to do manually to use CMake for their libraries instead of Boost Build, the less likely they are to want to do anything. Subsequently their tests using CMake might fail using particular toolsets even when  their tests using Boost Build will succeed.
Thanks for your efforts !

I do not know if you are generating the CMakeLIsts.txt files manually for each library or whether you have a script for doing so

Part of it is generated, and part of it is written out. Each test case has been manually written out.

Boost Build has the notion of a 'project' rule. The main use for the 'project' rule is to be able to specifying build requirements to each rule in the jamfile. For testing purposed the use of 'project' rule requirements is largely so that the same requirement for each individual test does not have to be repeated again and again.

Yes, and you can use bcm_test_link_libraries for that, which is just links a library but you can use an interface library to build a library that is just a collection of compile flags. For example, the date_time tests do:
add_library(data_time_tests_properties INTERFACE)
target_compile_definitions(data_time_tests_properties INTERFACE BOOST_DATE_TIME_POSIX_TIME_STD_CONFIG)
bcm_test_link_libraries(data_time_tests_properties)

So every test created with bcm_test will include the BOOST_DATE_TIME_POSIX_TIME_STD_CONFIG definition. Although, some cases the flags are added to the original library rather than the tests(because currently boost doesn't provide usage requirements for header-only libraries).

I noticed that you ignored conditional requirements completely in your converted CMakeLists.txt files for library tests.

Yes, those need work, as the conditions aren't always equivalent, so I need to figure out what the Boost.Build version does and  convert it to a cmake version.

Often in Boost Build the notation is used with conditional requirements to set a property based on the compiler or compiler/version being used in the compile.

Yes, but some of those things should not happen. For example, tests should not be adding -std=c++11 flags, as then its impossible to run the tests on newer c++ versions. What needs to happen is make sure a certain level of C++ support is available to run the tests. Boost.MP11 is a good example of how to do it, but it needs Boost.Config to check language support. This is something on my todo to finish.
Also, some of the other flags that the tests add are actually usage requirements and so they should be added to the library not the tests.

My major concern is that the more library developers ( like me ), who are not CMake experts like you, have to do manually to use CMake for their libraries instead of Boost Build, the less likely they are to want to do anything.

But I also am not a Boost.Build expert, so I dont understand all the subtle settings that are going on. I am trying to get as much done as possible, and hopefully the authors can fill in the details.

Yes, and you can use bcm_test_link_libraries for that, which is just links a library but you can use an interface library to build a library that is just a collection of compile flags.

This does not work for tests. The tests are not libraries, but bcm_tests. There is no library involved. My point is that in Boost Build the project requirements are default requirements for each test, but there is no equivalent to this except for CMake settings which are set for the entire CMakeLists.txt file as opposed to CMake target settings which are set for each test as a target. To put it another way the requirements at the 'project' level in Boost Build apply to all virtual targets in the  Boost Build jamfile itself.

Yes, but some of those things should not happen. For example, tests should not be adding -std=c++11 flags, as then its impossible to run the tests on newer c++ versions.

This is wrong. If I as the library developer know that a particular test needs -std=c++11 in order to have any chance to succeed, so I add it to that test, that cannot be incorrect. Forget about the particular requirement of -std=c++11 for example, and think in terms of any compiler flag, and you will see that the library developer has the perfect right to add some flag without which the test must fail. So please do not foolishly claim that "those things should not happen". You cannot possible know, in a point blank way, what compiler setting is necessary in order to even have a chance to run a test successfully for a particular Boost library.

This does not work for tests.

How so?

The tests are not libraries, but bcm_tests. There is no library involved.

A bcm_test is both a cmake test and a target(which can be either an executable or library). The target will link against any libraries that were specified in the bcm_test_link_libraries unless NO_TEST_LIBS is used.

My point is that in Boost Build the project requirements are default requirements for each test, but there is no equivalent to this except for CMake settings which are set for the entire CMakeLists.txt file as opposed to CMake target settings which are set for each test as a target.

No there isn't unless you are using bcm_test infrastructure which does what you describe.

If I as the library developer know that a particular test needs -std=c++11 in order to have any chance to succeed, so I add it to that test, that cannot be incorrect.

It is incorrect, because now there is no way to test your library with a C++14 or C++17 toolchain. Rather, you should just disable the tests when the compiler is not C++11 capable. This is the way mp11 tests work here, but relies on the feature-checking from Boost.Config, which has not been implemented yet.
Alternatively, there may be a way in a future to specify the C++ version as a usage requirement, and there can be some resolution when different version of C++ are specified. Cmake supports that with CXX_STANDARD but it has its limitations, and is not supported in 3.5.

Forget about the particular requirement of -std=c++11 for example, and think in terms of any compiler flag, and you will see that the library developer has the perfect right to add some flag without which the test must fail.

Yes, but if that flag is applied to all tests, then it should most likely be a usage requirement of the library, because the library is never tested to work without that flag. There are of course exceptions.

A bcm_test is both a cmake test and a target(which can be either an executable or library). The target will link against any libraries that were specified in the bcm_test_link_libraries unless NO_TEST_LIBS is used.

My entire point is that I do not want to have to repeat the exact same requirement for every bloody test. In Boost Build I do not have to do this. But you keep insisting that using bcm_test and doing this for every single test is a good way to use CMake. If it is the only way to use CMake I have no argument with that. But as I understand it I can set usage requirements in CMake for the entire CMakeLists.txt file rather than each target in the file. If I am wrong about this please point this out to me.

It is incorrect, because now there is no way to test your library with a C++14 or C++17 toolchain. Rather, you should just disable the tests when the compiler is not C++11 capable. This is the way mp11 tests work here, but relies on the feature-checking from Boost.Config, which has not been implemented yet.

You just do not know what you are talking about. First, creating some tests which need some level of c++ compliance and then having the tests fail because the end-user runs those particular tests without that level of compliance, is just going to confuse the end-user. What is the end-user supposed to do. Run test X with C++11 compliance, then run test Y with C++14, and then run test Z with C++03 compliance, and on and on with this sort of ludicrousness just to run tests successfully ? That is totally absurd. Testing should be made as easy as possible for end-users and test scenarios like the Boost regression tests, not as arcane and confusing as it can be.
It is also possible to have the same tests run more than once with different levels of c++ compliance for a library that can run successfully with difference compliance levels. So naturally I run the same test specifying different levels of compliance in order to test the functionality. Please don't natter on saying that this is incorrect or unacceptable to your way of thinking. This is a reality, and no matter what you feel about it you are no judge of how a library developer wants to test his library.

Yes, but if that flag is applied to all tests, then it should most likely be a usage requirement of the library, because the library is never tested to work without that flag. There are of course exceptions.

What library are you talking about ? Do you mean the test executables. That is fine but manually having to add the exact same flag to each test is a PITA. That is why having Boost Build 'project' requirements, even Boost Build 'project' conditional requirements, translated to CMake build requirements for the entire CMakeLists.txt file would be so much easier. If that sort of CMake functionality does not exist, for whatever arcane reason, I can accept that. But if it does exist, and you are arguing for repeating the same requirement for every single test through bcm_test I am afraid I can not understand the reason for such unnecessary repetition.

My entire point is that I do not want to have to repeat the exact same requirement for every bloody test.

Yes, thats why you use bcm_test_link_libraries so you don't have to repeat it on every test.

But you keep insisting that using bcm_test and doing this for every single test is a good way to use CMake.

I never said "doing this for every single test is a good way to use CMake".

But as I understand it I can set usage requirements in CMake for the entire CMakeLists.txt file rather than each target in the file.

No you can't. You can set some properties at directory or global scope, which can affect how targets are build, but its mainly used for defining toolchains because it doesn't affect usage requirements. Its better to just use bcm_test_link_libraries to set usage requirements for all tests in a directory as this only affects tests and it can be opt-out if necessary for certain test cases.

You just do not know what you are talking about.

I really don't appreciate the tone.

First, creating some tests which need some level of c++ compliance and then having the tests fail because the end-user runs those particular tests without that level of compliance, is just going to confuse the end-user.

I totally agree, which why the tests should be disabled using feature-checking.

Run test X with C++11 compliance, then run test Y with C++14, and then run test Z with C++03 compliance, and on and on with this sort of ludicrousness just to run tests successfully ? That is totally absurd. Testing should be made as easy as possible for end-users and test scenarios like the Boost regression tests, not as arcane and confusing as it can be.

I dont follow this at all. My point is that the tests should test against the user's toolchain not some other toolchain. That is, the user sets up a C++14 toolchain and having the tests run against a C++11 toolchain is simply wrong(which is what can happen when adding -std=c++11 to every test).

It is also possible to have the same tests run more than once with different levels of c++ compliance for a library that can run successfully with difference compliance levels.

But then this wouldn't be added to the project requirements.

What library are you talking about ?

The library you are testing with. For example, the tests for Boost.DLL adds -ldl for linux. This is added as project requirements for the tests Jamfile, but this is actually usage requirements for using Boost.DLL. So in the cmake here, its added as usage requirements so all downstream consumers of Boost.DLL will properly use -ldl, including the tests.
Put another way, if library A is only tested using -DFOO=1(which is what can happen by adding FOO=1 as a project requirement), then how can we know that the library works without FOO=1? We really don't, so the usage requirements for library A should have -DFOO=1 so all downstream users are using the tested configuration.

I dont follow this at all. My point is that the tests should test against the user's toolchain not some other toolchain. That is, the user sets up a C++14 toolchain and having the tests run against a C++11 toolchain is simply wrong(which is what can happen when adding -std=c++11 to every test).

I think you are describing two different scenarios here:

You describe what a possible user of the library might want: he's using boost with a particular compiler, with particular flags, and he is interested if the tests are working with that configuration
That's really also the way CMake/CTest work: you do things with one toolchain and one configuration
But CMake/CTest also has functionality for running several different test setups, in a CI-like scenario: that's what library developers want if I understand correctly here: to see the test results for several possible flags / different compilers and platforms. But that's usually a CI perspective, and CMake's tool for that is CDash, which is basically a test result aggregator.

I apologize getting so heated up over a general argument over whether the library developer should be able to set the C++ standard level of compliance for particular tests. The argument was not even relevant to the points I was making in my original post, which made the heated discussion of it on my part even worse.
I did not realize what you were referring to with bcm_test_link_libraries but now I do. I guess the name of 'bcm_test_link_libraries' confused me as I did not realize this referred to any library, whether it is header-only or linked ( built library ).

Looking at CMake it appears there are properties that can be set on source files using set_source_file_properties. Among these source file properties which can be set are COMPILE_DEFINITIONS and COMPILE_FLAGS. If these properties filter down to tests specified in that source file I believe they would be a better match for the requirements of a Boost Build 'project' rule specified in a bjam file for tests than attaching such values to the library itself using bcm_test_link_libraries.

I am not sure how that helps. For example, in date_time the definition of BOOST_DATE_TIME_POSIX_TIME_STD_CONFIG is added to every test using bcm_test_link_libraries like this:
add_library(data_time_tests_properties INTERFACE)
target_compile_definitions(data_time_tests_properties INTERFACE BOOST_DATE_TIME_POSIX_TIME_STD_CONFIG)
bcm_test_link_libraries(data_time_tests_properties)

bcm_test(NAME testint_adapter SOURCES testint_adapter.cpp)
bcm_test(NAME testtime_resolution_traits SOURCES testtime_resolution_traits.cpp)
bcm_test(NAME testwrapping_int SOURCES testwrapping_int.cpp)
bcm_test(NAME testconstrained_value SOURCES testconstrained_value.cpp)
bcm_test(NAME testgregorian_calendar SOURCES testgregorian_calendar.cpp)
bcm_test(NAME testgeneric_period SOURCES testgeneric_period.cpp)

If you use set_source_file_properties you would need to do:
bcm_test(NAME testint_adapter SOURCES testint_adapter.cpp)
set_source_files_properties(testint_adapter.cpp PROPERTIES BOOST_DATE_TIME_POSIX_TIME_STD_CONFIG)
bcm_test(NAME testtime_resolution_traits SOURCES testtime_resolution_traits.cpp)
set_source_files_properties(testtime_resolution_traits.cpp PROPERTIES BOOST_DATE_TIME_POSIX_TIME_STD_CONFIG)
bcm_test(NAME testwrapping_int SOURCES testwrapping_int.cpp)
set_source_files_properties(testwrapping_int.cpp PROPERTIES BOOST_DATE_TIME_POSIX_TIME_STD_CONFIG)
bcm_test(NAME testconstrained_value SOURCES testconstrained_value.cpp)
set_source_files_properties(testconstrained_value.cpp PROPERTIES BOOST_DATE_TIME_POSIX_TIME_STD_CONFIG)
bcm_test(NAME testgregorian_calendar SOURCES testgregorian_calendar.cpp)
set_source_files_properties(testgregorian_calendar.cpp PROPERTIES BOOST_DATE_TIME_POSIX_TIME_STD_CONFIG)
bcm_test(NAME testgeneric_period SOURCES testgeneric_period.cpp)
set_source_files_properties(testgeneric_period.cpp PROPERTIES BOOST_DATE_TIME_POSIX_TIME_STD_CONFIG)

Which would be the same as adding it to every test with target_compile_definitions:
bcm_test(NAME testint_adapter SOURCES testint_adapter.cpp)
target_compile_definitions(testint_adapter PUBLIC BOOST_DATE_TIME_POSIX_TIME_STD_CONFIG)
bcm_test(NAME testtime_resolution_traits SOURCES testtime_resolution_traits.cpp)
target_compile_definitions(testtime_resolution_traits PUBLIC BOOST_DATE_TIME_POSIX_TIME_STD_CONFIG)
bcm_test(NAME testwrapping_int SOURCES testwrapping_int.cpp)
target_compile_definitions(testwrapping_int PUBLIC BOOST_DATE_TIME_POSIX_TIME_STD_CONFIG)
bcm_test(NAME testconstrained_value SOURCES testconstrained_value.cpp)
target_compile_definitions(testconstrained_value PUBLIC BOOST_DATE_TIME_POSIX_TIME_STD_CONFIG)
bcm_test(NAME testgregorian_calendar SOURCES testgregorian_calendar.cpp)
target_compile_definitions(testgregorian_calendar PUBLIC BOOST_DATE_TIME_POSIX_TIME_STD_CONFIG)
bcm_test(NAME testgeneric_period SOURCES testgeneric_period.cpp)
target_compile_definitions(testgeneric_period PUBLIC BOOST_DATE_TIME_POSIX_TIME_STD_CONFIG)

Which is what you want to avoid.

That is my misunderstanding then. I thought you could use set_source_file_properties to add the properties to the CMakeLists.txt file itself so that all builds referenced in the CMakeLists.txt file had those properties. That is essentially the effect of the 'project' requirements in a Boost Build jamfile and I was looking for the CMake equivalent. What about setting the same properties for the directory itself using set_directory_properties ? I assume the directory is represented by the CMakeLists.txt file in that directory, so maybe that will be equivalent to the Boost Build 'project' requirements. Looking at the directory properties in the current CMake implementation I see COMPILE_DEFINITIONS and COMPILE_OPTIONS, so that should cover the majority of potential Boost Build 'project' requirements.

What about setting the same properties for the directory itself using set_directory_properties ?

But these properties dont set the properties on the target themselves, which can cause some problems(like with compatible interface properties). Plus, this just doesn't just affect the current directory but every subdirectory as well.
The directory scope properties are the same properties that are set when using the add_compile_options and add_definitions commands in cmake, but, in general, it is considered bad practice to use these in cmake, see here.

Are you saying that setting directory properties do not set the appropriate properties when creating targets from the files in that directory ( and sub-directories ) ? If that is the case what is the actual purpose of directory properties ?

Are you saying that setting directory properties do not set the appropriate properties when creating targets from the files in that directory ( and sub-directories ) ?

Nope, when cmake builds a target it uses the properties from the target and then the properties from the current(and parent) directory its building.

If that is the case what is the actual purpose of directory properties ?

Its useful for toolchain files, but I don't think that was its original intent. Originally, cmake was very much directory-oriented and had no way to set usage requirements. However, now usage requirements are set with with target properties, and to prevent unexpected surprises those directory properties should, in general, be avoided outside of toolchain files.

If I therefore set a directory property in a CMakeLists.txt file for tests, that property will filter down to all test targets which are built in that CMakeLists.txt file. This is the same effect that setting a 'project' requirement serves in a Boost Build jamfile. So despite your own feeling that directory properties should be avoided, it serves the purpose of duplicating Boost Build 'project' requirements closer than any other CMake facility.
I will readily admit that Boost Build does not have the notion that CMake can have of treating a header-file only library as an INTERFACE library target. So naturally Boost Build does not have the notion of setting properties on a header-file only library as a target. Whereas setting properties in CMake for an INTERFACE library gets propagated to any other executable or library which uses the INTERFACE library. So I do understand your feeling that setting the properties on the header-file only library itself is a better match for Boost Build 'project' requirements than setting those properties as directory properties.


go-vulnerability-scan started to fail

Affected all drone ci builds. Example: https://drone.owncloud.com/owncloud/ocis/34727/11/6
+ make govulncheck
(re)installing /go/bin/govulncheck-v1.0.1
go: downloading golang.org/x/vuln v1.0.1
go: downloading golang.org/x/tools v0.12.1-0.20230815132531-74c255bcf846
go: downloading golang.org/x/sync v0.3.0
go: downloading golang.org/x/sys v0.11.0
/go/bin/govulncheck-v1.0.1 ./...
Scanning your code and 1706 packages across 320 dependent modules for known vulnerabilities...

Vulnerability #1: GO-2024-2824
    Malformed DNS message can cause infinite loop in net
  More info: https://pkg.go.dev/vuln/GO-2024-2824
  Standard library
    Found in<EMAIL_ADDRESS>    Fixed in<EMAIL_ADDRESS>    Example traces found:
      #1: ocis/pkg/runtime/service/service.go:396:24: service.Start calls net.Dial
      #2: services/antivirus/pkg/scanners/clamav.go:23:31: scanners.ClamAV.Scan calls clamd.Clamd.ScanStream, which eventually calls net.DialTimeout
      #3: services/graph/pkg/identity/ldap/reconnect.go:241:24: ldap.ConnWithReconnect.ldapConnect calls ldap.DialURL, which eventually calls net.Dialer.Dial
      #4: services/antivirus/pkg/scanners/icap.go:59:28: scanners.ICAP.Scan calls icap.Client.Do, which eventually calls net.Dialer.DialContext
      #5: ocis/pkg/runtime/service/service.go:388:22: service.Start calls net.Listen
      #6: services/nats/pkg/server/nats/nats.go:42:2: nats.NATSServer.ListenAndServe calls server.Server.Start, which eventually calls net.ListenConfig.Listen
      #7: ocis-pkg/natsjsregistry/registry.go:67:21: natsjsregistry.storeregistry.Init calls nats.natsStore.Init, which eventually calls net.LookupHost
      #8: ocis-pkg/registry/register.go:20:29: registry.RegisterService calls registry.mdnsRegistry.Register, which eventually calls net.LookupIP
      #9: services/settings/pkg/service/v0/validator.go:116:28: service.validateListRoleAssignments calls ozzo.Validate, which eventually calls net.LookupMX
      #10: ocis-pkg/keycloak/client.go:90:39: keycloak.ConcreteClient.SendActionsMail calls gocloak.GoCloak.ExecuteActionsEmail, which eventually calls net.LookupSRV
      #11: services/graph/pkg/validate/validate.go:25:28: validate.StructCtx calls validator.Validate.StructCtx, which eventually calls net.ResolveIPAddr
      #12: services/graph/pkg/validate/validate.go:25:28: validate.StructCtx calls validator.Validate.StructCtx, which eventually calls net.ResolveTCPAddr
      #13: ocis-pkg/tracing/tracing.go:77:25: tracing.GetTraceProvider calls jaeger.New, which eventually calls net.ResolveUDPAddr
      #14: services/nats/pkg/server/nats/nats.go:42:2: nats.NATSServer.ListenAndServe calls server.Server.Start, which eventually calls net.Resolver.LookupHost

=== Informational ===

Found 1 vulnerability in packages that you import, but there are no call
stacks leading to the use of this vulnerability. You may not need to
take any action. See https://pkg.go.dev/golang.org/x/vuln/cmd/govulncheck
for details.

Share feedback at https://go.dev/s/govulncheck-feedback.
make: *** [Makefile:281: govulncheck] Error 3

CC @ScharfViktor @micbar @rhafer

Thanks! We need to bump the golang image.

https://github.com/owncloud-ci/golang/pull/141 merged

Fixed. see: https://github.com/owncloud/ocis/pull/9100


Implement tuple desugaring in match expressions

Closes #572
This PR implements tuple desugaring in match statments. It is now possible to write:
script;

fn gimme_a_pair() -> (u32, u64) {
    (1u32, 2u64)
}

fn main() -> u32 {
    let x = gimme_a_pair();
    match x {
        (a, 2u64) => { a },
        (a, b) => { 0u32 },
    }
}

Looks like clippy is warning on some redundant clones, but the stage isn't failing. @emilyaherbert could you fix those clones, and @eureka-cpu could you take a look at making the clippy pipeline stage deny warnings?


Add a FAQ Section to the Website

Hello , My name is "Sakshar Devgon"
https://github.com/itsmohit097/medi-hub/assets/121454018/b2c837fc-075e-4eed-ba36-f1f3a3b2518a
I would like to propose adding a Frequently Asked Questions (FAQ) section to the website. This section will help users find answers to common questions related to medical treatments. Below is the proposed HTML, CSS, and JavaScript for the FAQ section:, i have sended you the faq sample in the form of video ,, kindly assign me in this then i will do the styling of this faq section acc to you ui and then i will send the pull request ...
thank you
kindly accept its a great thing to add faq section ( i attached the sample in preview section) i will design it acc to your ui when you assign it to me

@Sakshar-Devgon assigned to someone else


ARROW-15253: [Python] Error in to_pandas for empty dataframe with index with extension type

This PR adds a check for the name of the column in _get_extension_dtypes() from pandas_compat.py to fix an error when using pd.iterval_range index with empty dataframe in Pandas roundtrip.

The failing lint build seems unrelated, I restarted it.


FF-335

Coverage decreased (-1.9%) to 51.27% when pulling 51f2f73e2c9b1c6d106070793f0828f082008bb7 on FF-335 into 5708570c47f9d1bc64b7df2734ee0038bb190a23 on master.


[Docs]: Add Turkish translation of ProjectsHut's docs

Related Issue (#433)

Description

This PR adds the Turkish translation of ProjectsHut's documentation, enabling Turkish users to access and understand the content.

format these files using pnpm format
[warn] translations/Turkish/CODE_OF_CONDUCT.md
[warn] translations/Turkish/contributing.md
[warn] translations/Turkish/readme.md

format these files using pnpm format
[warn] translations/Turkish/CODE_OF_CONDUCT.md [warn] translations/Turkish/contributing.md [warn] translations/Turkish/readme.md

It seems that when I ran the command pnpm format translations/Turkish/CODE_OF_CONDUCT.md translations/Turkish/contributing.md translations/Turkish/readme.md, it ended up going through all files in the project and showing 'M' (modified) status for all of them. However, when I added and committed only these three files and pushed them to the branch, it displayed "Everything is up to date." I'm not entirely sure why this is happening.
It's possible that the formatting changes made by pnpm format did not actually modify the content of the files. It's also worth considering if there were any other changes in the project that could have caused this behavior.


Allow to set additional parameters of the Raspberry Pi Camera

Describe the feature
The Raspberry Pi Camera has a lot of parameters that can be tuned and should be added to the server configuration.
List:
libcamera-vid --help

List of parameters to take into consideration:

--awb
--denoise cdn_off
--mode 1332:990:10
--level 4.2
--tuning-file /usr/share/libcamera/ipa/raspberrypi/imx477.json
--mode
--post-process-file

Agreed +1, currently we have a work around like in this repo -> https://github.com/kerberos-io/camera-to-rtsp

Agreed +1, currently we have a work around like in this repo -> https://github.com/kerberos-io/camera-to-rtsp

I have to say that this approach also works amazingly well, allowing the use of all possible libcamera-vid/still parameters!
Been using it with my HQ Camera/IMX477, I had to build both libcamera+libcamera-apps from source to use it's full capabilities (like 1332x990@90FPS, up to 120FPS is possible).
Having native support for it with rtsp-simple-server would've been amazing though.
I've been thinking of using the power of HEVC/H265 and possibly also disable the camera during night time, since the sensor doesn't see anything anyway, unless I mount some massive IR blasters and removing the IR filter.
Regarding the night time I was thinking of doing some cronjob that would run hourly:

is the camera running?
get time of local sunset
if local sunset is in 2 hours or less -> turn off the stream
if local sunrise is in 1 hour or less -> turn on the stream.

Above scheduling of camera + H265 support, on top of being able to use all of the parameters of the camera, as originally implemented, would make rtsp-simple-server so good there would be little point of using the camera outside of rtsp-simple-server, but those are just few of my ideas.
Above all of the things I mentioned, I wanted to say Thank You very much aler9 for Your support and amazing work, that everybody could use, I highly appreciate the work and effort put into this! <3

Agreed +1, currently we have a work around like in this repo -> https://github.com/kerberos-io/camera-to-rtsp

The problem of that approach is that is slow compared to the one that can be obtained by interacting directly with libcamera, and that's why i wanted to integrate it into the server.  Anyway, since rtsp-simple-server is now able to interact with libcamera, adding support for additional parameters is actually really simple, it's enough to take all the set() functions here:
https://github.com/raspberrypi/libcamera-apps/blob/e1beb4512178f5a229001b1ecc378a89bc9757c0/core/libcamera_app.cpp#L422
and paste them into the server, here:
https://github.com/aler9/rtsp-simple-server/blob/27fb9fdb7ea53f8d13a0fda2a6a59b361f87a4c3/internal/rpicamera/exe/camera.cpp#L191
I don't know whey i'll got the time to do it, but in the meanwhile, anyone is free to do the work and submit a patch.

H265 support

Raspberry Pis at the moment aren't equipped with a H265 hardware encoder:
https://forums.raspberrypi.com/viewtopic.php?t=243873
And i don't recommend doing H265 software encoding since it would consume most of the CPU.

Thank You, I've just watched a video about software encoding H265 performance and I see even with powerful Desktop CPU the performance is horrible, so there's no point going that path.
Regarding the camera parameters, there are some more parameters not listed in those set().
namely:
--denoise cdn_off
--mode 1332:990:10
--framerate 100
--width 1332
--height 990
--level 4.2
--tuning-file /usr/share/libcamera/ipa/raspberrypi/imx477.json
Which I believe are very useful, so I'm leaving them here for the future.

Agreed +1, currently we have a work around like in this repo -> https://github.com/kerberos-io/camera-to-rtsp

The problem of that approach is that is slow compared to the one that can be obtained by interacting directly with libcamera, and that's why i wanted to integrate it into the server. Anyway, since rtsp-simple-server is now able to interact with libcamera, adding support for additional parameters is actually really simple, it's enough to take all the set() functions here:
https://github.com/raspberrypi/libcamera-apps/blob/e1beb4512178f5a229001b1ecc378a89bc9757c0/core/libcamera_app.cpp#L422
and paste them into the server, here:
https://github.com/aler9/rtsp-simple-server/blob/27fb9fdb7ea53f8d13a0fda2a6a59b361f87a4c3/internal/rpicamera/exe/camera.cpp#L191
I don't know whey i'll got the time to do it, but in the meanwhile, anyone is free to do the work and submit a patch.

H265 support

Raspberry Pis at the moment aren't equipped with a H265 hardware encoder:
https://forums.raspberrypi.com/viewtopic.php?t=243873
And i don't recommend doing H265 software encoding since it would consume most of the CPU.

Agreed! What still would be great to have is the single container running with injecting the appropriate devices into the container.
As far I've understood the code to interface libcamera is not yet released imas a docker container image.

Thank You, I've just watched a video about software encoding H265 performance and I see even with powerful Desktop CPU the performance is horrible, so there's no point going that path.
Regarding the camera parameters, there are some more parameters not listed in those set(). namely: --denoise cdn_off --mode 1332:990:10 --framerate 100 --width 1332 --height 990 --level 4.2 --tuning-file /usr/share/libcamera/ipa/raspberrypi/imx477.json
Which I believe are very useful, so I'm leaving them here for the future.

+1
I need to be able to specify the mode for my use case

The following parameters have been added:

rpiCameraHFlip
rpiCameraVFlip
rpiCameraBrightness
rpiCameraContrast
rpiCameraSaturation
rpiCameraSharpness
rpiCameraExposure
rpiCameraAWB
rpiCameraDenoise
rpiCameraShutter
rpiCameraMetering
rpiCameraGain
rpiCameraEV
rpiCameraROI
rpiCameraTuningFile

The following parameters have been left out of the PR:

-- mode: it isn't used inside libcamera-vid (see here), mode is inferred automatically from width, height and fps
--post-process-file: it controls a complex, pure-software process written inside libcamera-vid, subjected to regular updates and with external dependencies (opencv). I can't copy and paste libcamera-vid files and i can't add opencv to the server dependencies.

@reyoda thanks for clarifying this, evidently i didn't understood the code enough, i'll give another try.

rpiCameraMode has been implemented

added in v0.20.1

Hello,
I tried implementing a NoIR camera v2 on a pi3a+ into a birdbox, and i'm quite pleased with mediamtx so far. I just would love getting a greyworld AWB on my stream, but i can't get it working.
https://github.com/aler9/mediamtx/issues/1181 refered to this problem already and it was closed like this thread => is there a possibility to get this greyworld parameter for rpiCameraAWB ? I've tried to stay in auto and add the auto_awb_is_greyworld=1 into my config.txt, but with no result...
My stream is a splendid pink frame in daylight, and a solid blue during night without this feature... So if there's anyone who could get it work, i'd be glad having some help ! :)
Thanks


loaddivisions should be idempotent

I think it's able to load in a safer way now, I think this is mostly safe to run multiple times regardless of state - cool to close, @jamesturk ?

@paultag, is this good to close?

I think the issue remaining here is that if the number of divisions stays the same but the divisions themselves change then they don't get reloaded. An edge case to be sure, but not out of the question.

This PR should solve the problem.


[BUG] Predict function fails when using the revision methods 'AHP' and 'PHA' while also setting transform=True

Describe the bug
The predict function of  a HTSRegressor throws the error ''bool' object has no attribute 'inverse_transform' when it is called with the revision method 'AHP' or 'PHA' and transform is set to True.
When the revision method is instantiated inside the _init_revision function, self.transform, which is a boolean value, is passed to the RevisionMethod class but it is expecting a transformer function to be passed. This causes the revision methods 'AHP' and 'PHA' to throw an error when the revise method from revision.py is called, as they try to use the inverse transform function.
To Reproduce
Create a HTSRegressor, setting the revision method to either 'AHP' or 'PHA' and set transform to True. Fit the model to data and then call the predict function.
Expected behavior
The predict function runs without error and outputs the correct predictions
Desktop (please complete the following information):
N/A
Additional context
This was run on the free version of colab

https://github.com/carlomazzaferro/scikit-hts/issues/38#issuecomment-853601578

Merged: https://github.com/carlomazzaferro/scikit-hts/pull/72. Bump to 0.5.8 for new goodies. Make sure to read the docs on how to specify the transform: https://scikit-hts.readthedocs.io/en/latest/hts.html#hts.HTSRegressor.init


Download process quirks

Python version:
3.6.2
Bandcamp-dl version:
0.0.8-07
Bancamp-dl options:
None
url:
https://scandroid.bandcamp.com/album/the-force-theme-single
Describe the issue:
With a not.finished file and a url provided at the same time the track will download but not display the progress bar.
With just a url provided the progress bar displays.
With just the not.finished file the progress bar also does not display.

Fixed


Validation not catching errors in sub-messages [Go]

This issue uses generated code in the Envoy go-control-plane
I'm writing a simple Go program to read in JSON Envoy configuration components, build the protobuf structs out of them and validate them. The configs come in DiscoveryResponse format. Upon reading them in as a DiscoveryResponse and running validate, it doesn't appear to correctly catch an issue in a nested message. I can only get validation to trigger if I explicitly drill down to that message and call validate. The generated code appears to call validate on sub-messages but I never get an error.
The exact validation I tested with was a DiscoveryResponse with empty domains in its RouteConfiguration when it should have at least one (validation rule).
Full example program and output:
package main

import (
	"fmt"
	"strings"

	"github.com/gogo/protobuf/jsonpb"
	"github.com/gogo/protobuf/types"
	v2 "github.com/envoyproxy/go-control-plane/envoy/api/v2"
)

const json = `
{
	"resources":
	[
		{
			"@type": "type.googleapis.com/envoy.api.v2.RouteConfiguration",
			"name": "routes",
			"virtual_hosts": [
				{
					"name": "api",
					"domains": [],
					"routes": [
						{
							"match": {
								"prefix": "/"
							},
							"route": {
								"cluster": "service"
							}
						}
					]
				}
			]
		}
	]
}`

func main() {
	discoveryResponse := v2.DiscoveryResponse{}
	strReader := strings.NewReader(json)
	err := jsonpb.Unmarshal(strReader, &discoveryResponse)
	if err != nil {
		panic(err)
	}

	fmt.Println(">> Evaluating top-level DiscoveryResponse")
	err = discoveryResponse.Validate()
	if err != nil {
		fmt.Println(err.Error())
	} else {
		fmt.Println("no errors")
	}

	routeConfig := &v2.RouteConfiguration{}
	types.UnmarshalAny(&discoveryResponse.GetResources()[0], routeConfig)
	fmt.Println(">> Evaluating RouteConfiguration")
	err = routeConfig.Validate()
	if err != nil {
		fmt.Println(err.Error())
	} else {
		fmt.Println("no errors")
	}

	fmt.Println(">> Evaluating VirtualHost")
	vhost := routeConfig.GetVirtualHosts()[0]
	err = vhost.Validate()
	if err != nil {
		fmt.Println(err.Error())
	} else {
		fmt.Println("no errors")
	}
}

Output:
>> Evaluating top-level DiscoveryResponse
no errors
>> Evaluating RouteConfiguration
no errors
>> Evaluating VirtualHost
invalid VirtualHost.Domains: value must contain at least 1 item(s)

If this is the expected behavior it may be worth documenting.

There are two issues here:

Embedded Any or Structs are not validated since that causes a potentially quadratic unmarshalling cost (for nested Structs).

There is an actual bug with using structs vs pointers in gogo, see https://play.golang.org/p/VJb7PuNEQDZ for the boiled-down example

Exactly as @kyessenov said, validation does not attempt to unmarshal Any or Struct into its target type. Beyond the complexity issue, there's also no guarantee that the code validating the message has the descriptors or the generated validation code to even perform the operation. Internally, Envoy performs these validations after resolving the configs to their actual message types.
@derekargueta, would you like to open a separate ticket regarding the value vs pointer issue? Seems like in that case we can try changing the receiver to the value instead.

@rodaine Since the Any/Struct part is expected behavior, I can trim this bug ticket down to the pointer/value part (RC not validating vhosts), and open a separate ticket to document the expected behavior w.r.t. Any/Struct. WDYT?

Sounds good!

You can assign it to me. Should be an easy fix.

Updated the ticket to just the RC->vhost issue. (not sure if sub-messages is the right lingo.

Seems like in that case we can try changing the receiver to the value instead.

Or, it might be more straightforward to just go with (&msg.field).Validate()?

Added the non-nil bit to differentiate, and also specified this only affects GoGo (offiical protoc-gen-go always emits pointers at this time).


Add NSUserActivity when ground selected on map

https://stackoverflow.com/questions/38902602/ios-10-nsuseractivity-location-suggestions-mkmapitem-does-not-appear-in-maps

Doesn't work, no documentation and unlikely to be needed by anyone including me!


'to' in linear-gradient()

It seems GitHub does the same but I don’t know if it’s correct.

.test {
  background-image: linear-gradient(to right, white, black);
}

This matches the CSS syntax, and it should be different from right. I could remove the special handling of this keyword, which would turn it into a simple operator, but I don't think it warrants a change right now.


[#2721] Update paver from python-package

Problem?
An older version of paver.sh is being updated in python-package for ARM64 and HP-UX support.
Solution?
Forward-patch the improvements from python-package to brink, so that we may update paver.sh in python-package from brink without losing latest changes.
How to check?
Please review changes.
Check the os_version_raw line in HP-UX.
Run tests.
reviewer: @adiroiban

needs-review

All good. thanks!
hope that soon we will have an hpux slave and we can test the code there.
approved-at 4efdf12

Just for fun, have looked-up free shell accounts for HP-UX and run into this: http://www.polarhome.com
Might be interesting to consider.

The version in setup.py should have been updated too. Hard-reseted HEAD and trying to re-open now…

needs-review

And a question: Shouldn't we use hpux1131 for naming the package? Currently I see you have only used hpux for the OS part in the package name, which is not in line with the other names: solaris10, rhel4, sles11, ubuntu1204 etc.

Change looks good.
for hpux we should have hpux1131
approved-at latest
Thanks!


Reduce deployment target by 3 versions

Motivation
Reduce deployment target by 3 versions to gain more adoption.
Modifications

Added new deployment targets
Refactor invokeSession method to support iOS 13+
TODO: Update swift-openapi-runtime version once changes are done there.

Result
Deployment target will be reduced by 3 versions.

@swift-server-bot add to allowlist

@swift-server-bot test this please

@swift-server-bot add to allowlist

@czechboy0 could you create a new release for the runtime, since the PR has been merged there?

@denil-ct https://github.com/apple/swift-openapi-runtime/releases/tag/0.1.3

@simonjbeaumont @czechboy0 please review and merge


New feature in OVertexTransformer: skip duplicate vertices

This was discussed as an issue in the orientdb repository: https://github.com/orientechnologies/orientdb/issues/3607

Hi @gfinger the PR is perfect, but sent to "master" instead of "develop". Please can you post it to "develop"? Thanks.

Merged, thanks!


(title) Sync updates from solvaholic/template

(body) Sync updates from solvaholic/template

🤦 I merged three of these before I realized I screwed up the indentation. If the linter was OK with it then I should be, but I'm just gonna close this pull request.


Spec says to use swagger.json

I was trying to integrate my Swashbuckle generated Swagger docs with an external tool.   However it would not work with the tool (the tool is called Outsystems).
The creators of the tool told me that the reason is that the json for the swagger data is supposed to be in a file called swagger.json.
I checked the spec and it does mention that:

File Structure

The Swagger representation of the API is made of a single file. However, parts of the definitions can be split into separate files, at the discretion of the user. This is applicable for $ref fields in the specification as follows from the JSON Schema definitions.

By convention, the Swagger specification file is named swagger.json.

But my json is in https://MyDomain/MyService/swagger/docs/v1
Is there a way to to configure swashbuckle to put the swagger json in a file called swagger.json?

You're correct, the recommended convention is to use a file named swagger.json. This will be the default in the next major version (6.0.0) of Swashbuckle (targeting Asp.Net Core).
In the meantime, you can customize the routes as described in the readme - https://github.com/domaindrivendev/Swashbuckle#custom-routes
One gotcha to look out for - you'll need to add the following setting to your web.config
<system.webServer>
    <modules runAllManagedModulesForAllRequests="true" />
    ...

This is because you're using a route that contains an extension in it and by default Asp.Net will serve these files with a static file handler, bypassing the MVC pipeline and hence the Swashbuckle code. The above setting ensures the MVC pipeline is triggered for all requests. Of course, this may affect performance particularly if you are actually serving a lot of static content through your WebApi application. There's lots of blogs out there about that setting so a quick google should give you plenty of resources to learn more


mark XamarinLicense task as deprecated

one small comment - changes look good!

Yes ENU strings are checked in


timeout setting promblem

Hi, i want confirm a question.

My client is long connection and client set timeout itself,
Twemproxy configuration:
twemproxy1:
listen: <IP_ADDRESS>:22135
hash: fnv1a_64
hash_tag: "{}"
distribution: ketama
auto_eject_hosts: true
server_connections: 100
server_failure_limit: 3
server_retry_timeout: 30000
redis: false
servers:

<IP_ADDRESS>:23401:1 server1
<IP_ADDRESS>:23401:1 server2
<IP_ADDRESS>:23401:1 server3

Now, if one mc always timeout, the other two mc are ok, will my all requests to twemproxy maybe are timeout?(all the requests cross by my one long connection)

I guess this is your question. Let say you send mget key1 key2 key3.
key1 goes to server1
key2 goes to server2
key3 goes to server3
if you don't hear back from server1 because connection timedout, the entire mget request times out. We send back SERVER_ERRROR Connection timedout\r\n to the client, even though we have a valid response for key2 and key3
However, if you send mget key2 key3 and assuming server2 and server3 don't time out, we would forward the response from server to client

Thank for this reply.
Look the follow code in the twemproxy
if (req_done(c_conn, TAILQ_FIRST(&c_conn->omsg_q))) {
status = event_add_out(ctx->evb, c_conn);
if (status != NC_OK) {
c_conn->err = errno;
}
}
if (pmsg == NULL || !req_done(conn, pmsg)) {
/* nothing is outstanding, initiate close? */
if (pmsg == NULL && conn->eof) {
conn->done = 1;
log_debug(LOG_INFO, "c %d is done", conn->sd);
}
status = event_del_out(ctx->evb, conn);
if (status != NC_OK) {
conn->err = errno;
}
return NULL;
}
If the first msg is not done in one client connection, the back msgs will never response to client.
If twemproxy did not setting timeout, and the first msg always not come back from mc, the other msgs in this client connection also can not response to client, right?
Then the situation i described above will be appear, i don't know what i say is right or not.

And at this time, the twemproxy's memory will increase quickly.

Yeah. Adding timeout is critical. Have you read the recommendation.md section about timeout?

Yeah, i had read the recommendation.md before, but i just know one mc timeout can effect other mc responses. Then, thank you for this quick reply and we will add timeout for all our twemproxy, thanks again! ;)


config-seed fails to run if some configuration.toml files aren't present

This is an issue that affects the snap, because we don't want to stage all of the go service's configuration.toml files into the snap yet. For example, we haven't tested the go implementation of support-notificiations yet, and so are still using the Java version, which means that the configuration.toml for support-notifications isn't in the config folder, so when we invoke the new config-seed binary as follows:
https://github.com/edgexfoundry/edgex-go/blob/335486c1d6d1d9e1ca23778dab0a15cd460a6520/snap/bin/start-config-seed.sh#L22-L27
and support-notifications is missing from the $SNAP/config folder, the following is output:
INFO: 2018/09/10 15:47:40 Service dependencies resolved...
INFO: 2018/09/10 15:47:40 dir: device-virtual file: application.properties
DEBUG: 2018/09/10 15:47:40 importing: /snap/edgexfoundry/x1/config/core-command
DEBUG: 2018/09/10 15:47:40 reading toml /snap/edgexfoundry/x1/config/core-command/res/configuration.toml
DEBUG: 2018/09/10 15:47:41 importing: /snap/edgexfoundry/x1/config/core-data
DEBUG: 2018/09/10 15:47:41 reading toml /snap/edgexfoundry/x1/config/core-data/res/configuration.toml
DEBUG: 2018/09/10 15:47:41 importing: /snap/edgexfoundry/x1/config/core-metadata
DEBUG: 2018/09/10 15:47:41 reading toml /snap/edgexfoundry/x1/config/core-metadata/res/configuration.toml
DEBUG: 2018/09/10 15:47:41 importing: /snap/edgexfoundry/x1/config/export-client
DEBUG: 2018/09/10 15:47:41 reading toml /snap/edgexfoundry/x1/config/export-client/res/configuration.toml
DEBUG: 2018/09/10 15:47:41 importing: /snap/edgexfoundry/x1/config/export-distro
DEBUG: 2018/09/10 15:47:41 reading toml /snap/edgexfoundry/x1/config/export-distro/res/configuration.toml
DEBUG: 2018/09/10 15:47:41 importing: /snap/edgexfoundry/x1/config/support-logging
DEBUG: 2018/09/10 15:47:41 reading toml /snap/edgexfoundry/x1/config/support-logging/res/configuration.toml
DEBUG: 2018/09/10 15:47:41 importing: /snap/edgexfoundry/x1/config/support-notifications
ERROR: 2018/09/10 15:47:41 lstat /snap/edgexfoundry/x1/config/support-notifications/res: no such file or directory
[[ config-seed dies ]]

This isn't a huge problem for the snap, as we will eventually have all of the services there, but if someone was going to run config-seed without having for example the export-client folder then they would see this happen:
INFO: 2018/09/10 15:55:50 Service dependencies resolved...
INFO: 2018/09/10 15:55:50 dir: device-virtual file: application.properties
DEBUG: 2018/09/10 15:55:50 importing: /snap/edgexfoundry/x1/config/core-command
DEBUG: 2018/09/10 15:55:50 reading toml /snap/edgexfoundry/x1/config/core-command/res/configuration.toml
DEBUG: 2018/09/10 15:55:51 importing: /snap/edgexfoundry/x1/config/core-data
DEBUG: 2018/09/10 15:55:51 reading toml /snap/edgexfoundry/x1/config/core-data/res/configuration.toml
DEBUG: 2018/09/10 15:55:51 importing: /snap/edgexfoundry/x1/config/core-metadata
DEBUG: 2018/09/10 15:55:51 reading toml /snap/edgexfoundry/x1/config/core-metadata/res/configuration.toml
DEBUG: 2018/09/10 15:55:51 importing: /snap/edgexfoundry/x1/config/export-client
ERROR: 2018/09/10 15:55:51 lstat /snap/edgexfoundry/x1/config/export-client/res: no such file or directory
[[ config-seed dies ]]

where config-seed doesn't attempt to load other services that may exist.
Ping @tsconn23 this is the issue I mentioned on RocketChat yesterday

Note the correct thing is that config-seed should log that it failed to load the service's configuration.toml and move on to the other services without dying.

@anonymouse64 Please try again with the latest commit into master from this morning. I am unable to replicate using the latest master commit.
I renamed the support-notifications folder to simulate a delete. See below. The service reports "no such file or directory" and continues.
DEBUG: 2018/09/11 10:30:58 importing: /Users/tconn/go/src/github.com/edgexfoundry/edgex-go/cmd/support-notifications
ERROR: 2018/09/11 10:30:58 lstat /Users/tconn/go/src/github.com/edgexfoundry/edgex-go/cmd/support-notifications/res: no such file or directory
DEBUG: 2018/09/11 10:30:58 executing dir /Users/tconn/go/src/github.com/edgexfoundry/edgex-go/cmd/config-seed
DEBUG: 2018/09/11 10:30:58 absolute path /Users/tconn/go/src/github.com/edgexfoundry/edgex-go/cmd
DEBUG: 2018/09/11 10:30:58 importing: /Users/tconn/go/src/github.com/edgexfoundry/edgex-go/cmd/core-command

Ah yes, now it works:
INFO: 2018/09/11 13:49:53 Service dependencies resolved...
INFO: 2018/09/11 13:49:53 dir: device-virtual file: application.properties
DEBUG: 2018/09/11 13:49:54 importing: /snap/edgexfoundry/x1/config/core-data
DEBUG: 2018/09/11 13:49:54 reading toml /snap/edgexfoundry/x1/config/core-data/res/configuration.toml
DEBUG: 2018/09/11 13:49:54 importing: /snap/edgexfoundry/x1/config/core-metadata
DEBUG: 2018/09/11 13:49:54 reading toml /snap/edgexfoundry/x1/config/core-metadata/res/configuration.toml
DEBUG: 2018/09/11 13:49:54 importing: /snap/edgexfoundry/x1/config/export-client
DEBUG: 2018/09/11 13:49:54 reading toml /snap/edgexfoundry/x1/config/export-client/res/configuration.toml
DEBUG: 2018/09/11 13:49:54 importing: /snap/edgexfoundry/x1/config/export-distro
DEBUG: 2018/09/11 13:49:54 reading toml /snap/edgexfoundry/x1/config/export-distro/res/configuration.toml
DEBUG: 2018/09/11 13:49:54 importing: /snap/edgexfoundry/x1/config/support-logging
DEBUG: 2018/09/11 13:49:54 reading toml /snap/edgexfoundry/x1/config/support-logging/res/configuration.toml
DEBUG: 2018/09/11 13:49:54 importing: /snap/edgexfoundry/x1/config/support-notifications
ERROR: 2018/09/11 13:49:54 lstat /snap/edgexfoundry/x1/config/support-notifications/res: no such file or directory
DEBUG: 2018/09/11 13:49:54 importing: /snap/edgexfoundry/x1/config/core-command
DEBUG: 2018/09/11 13:49:54 reading toml /snap/edgexfoundry/x1/config/core-command/res/configuration.toml
DEBUG: 2018/09/11 13:49:54 v2 consul wrote key Logging/EnableRemote with value false
DEBUG: 2018/09/11 13:49:54 v2 consul wrote key Logging/File with value /var/snap/edgexfoundry/common/core-command.log
DEBUG: 2018/09/11 13:49:54 v2 consul wrote key Clients/Logging/Protocol with value http
DEBUG: 2018/09/11 13:49:54 v2 consul wrote key Clients/Logging/Host with value localhost
DEBUG: 2018/09/11 13:49:54 v2 consul wrote key Clients/Logging/Port with value 48061
DEBUG: 2018/09/11 13:49:54 v2 consul wrote key Clients/Metadata/Protocol with value http
DEBUG: 2018/09/11 13:49:54 v2 consul wrote key Clients/Metadata/Host with value localhost
DEBUG: 2018/09/11 13:49:54 v2 consul wrote key Clients/Metadata/Port with value 48081
DEBUG: 2018/09/11 13:49:54 v2 consul wrote key Service/BootTimeout with value 30000
DEBUG: 2018/09/11 13:49:54 v2 consul wrote key Service/Protocol with value http
DEBUG: 2018/09/11 13:49:54 v2 consul wrote key Service/Port with value 48082
DEBUG: 2018/09/11 13:49:54 v2 consul wrote key Service/Timeout with value 5000
DEBUG: 2018/09/11 13:49:54 v2 consul wrote key Service/ClientMonitor with value 15000
DEBUG: 2018/09/11 13:49:54 v2 consul wrote key Service/CheckInterval with value 10s
DEBUG: 2018/09/11 13:49:54 v2 consul wrote key Service/Host with value localhost
DEBUG: 2018/09/11 13:49:54 v2 consul wrote key Service/StartupMsg with value This is the Core Command Micro Service
DEBUG: 2018/09/11 13:49:54 v2 consul wrote key Service/ReadMaxLimit with value 100
DEBUG: 2018/09/11 13:49:54 v2 consul wrote key Registry/Host with value localhost
DEBUG: 2018/09/11 13:49:54 v2 consul wrote key Registry/Port with value 8500
DEBUG: 2018/09/11 13:49:54 v2 consul wrote key Registry/Type with value consul

Thanks!


Test with new pydeck releases with jupyter lab

I tested with the new pydeck beta, 0.4.0b1, but I couldn't get any deck plots to show. The console complained:
Module @deck.gl/jupyter-widget, semver range 8.2.0-alpha.2 is not registered as a widget module

I've seen this before where there's a mismatch between the deck version pydeck expects and the JS version loaded. deck.version in the console prints 8.2.0-alpha.1.
I'm not sure if this is somehow an error on my end, or if pydeck is accidentally still bundling 8.2.0-alpha.1.
cc @ajduberstein

The JS bundled with pydeck is only for notebooks. JS installed in JupyterLab is downloaded via unpkg.
For these beta installations you need to manually upgrade your @deck.gl/jupyter-widget installations. jupyter labextension install<EMAIL_ADDRESS>should do the trick.

I was able to upgrade by running
jupyter labextension uninstall @deck.gl/jupyter-widget
jupyter labextension install<EMAIL_ADDRESS>
but I'm still getting some errors. I think it might be good to create an issue in visgl/deck.gl to debug tomorrow.

Should be fixed by https://github.com/visgl/deck.gl/pull/4652

Works for me with JupyterLab 2


Add newlines to end of change files

All files should have a newline before EOF, this changes the new-change
script to add them and backfills them into all existing change files.
cc @kyleknap @jamesls

:shipit:


Support recursive trees of directives

I had some ideas about implementing this during the meeting, so I might have a go at bikeshedding something over the next few weeks.
What it comes down to is basically conditionally inserting DOM into a compiled template, based on some state. Sort of an implicit ng-if that gets resolved at compile-time, or else prevents ng-if from recursively linking the same template.
Anyways, I'd like to sort out a way to do that because it's a pretty cool and useful structure, and other implementations (like http://caitp.github.io/ui-comments/#/) have depended on some ugly hacks which are better to avoid.
I'm sure this has been proposed already, but I can't find any of those issues right now.
Anyways, I'll throw something together and people can see what they think
use cases

Comments
Org-charts
Graphs
Product charts
etc...

this is too hard to accomplish in this codebase

Dupe of https://github.com/angular/angular.js/issues/8536

We are still happily using https://github.com/dotJEM/angular-tree allot (yes, i created that)... Optimizations, improvements etc. are more than welcome btw...


Feature/issue6

PR Checklist

[X] Addresses an existing open issue: fixes issue #6
[X] That issue was marked as status: accepting prs
[X] Steps in CONTRIBUTING.md were taken

Overview
Implemented the Service Cloud Voice Toolkit API within the knowledge recommendation component. Also implemented a server side apex controller for the LWC used to retrieve articles through a SOSL query.

@all-contributors please add @valon-loshaj for maintenance.

🤖 Beep boop! This comment was added automatically by all-contributors-auto-action.
Not all contributions can be detected from Git & GitHub alone. Please comment any missing contribution types this bot missed.
...and of course, thank you for contributing! 💙


Resizing editor window causes editor to render offset

Tested versions
v4.0.stable.official [92bee43ad] through v4.4.dev4.official [36e6207bb]
System information
Godot v4.4.dev4 - Windows 10.0.19045 - Multi-window, 1 monitor - Vulkan (Forward+) - dedicated NVIDIA GeForce GTX 980 Ti (NVIDIA; <IP_ADDRESS>03) - Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz (8 threads)
Issue description
When resizing the Godot editor window, the editor stops rendering in the correct location of the window:
https://github.com/user-attachments/assets/b93d2c34-2841-48d5-88b4-48110e728b00
This does not happen with the Project Manager, but happens with any project.
Since this happens as early as 4.0, I expect this has already been reported, but I can't find the existing issue...
Restarting the computer resolved the issue and I can no longer reproduce it, even though it was happening consistently until the restart.
Steps to reproduce

Open Godot editor
Resize the window

Minimal reproduction project (MRP)
N/A

I'm having trouble reproducing this on my other computer. I will continue to try and dig down to what the source of the problem might be. I tried clearing all of the files in %appdata%/Godot, but that did not change anything.
I was playing around with #99010 on the computer that started to exhibit this behaviour, in case that's relevant info...

It happened to me again:

I think the common element is that I'm using OBS Studio 29.1.3 (64 bit) when this problem happens...


Fixed install script syntax closure

Ah thanks for this, the curl check and python PR checks clashed against each other, should have resolved conflicts in something better than the GitHub UI.


Don't panic when stdout doesn't exist

Rendered

I’d find pretty nice if {print,write}{,ln}! returned an io::Result<()>, which doesn’t have to be used. This way println!("hey!") would still work just fine without warnings and people could handle the error if they desired so.

What does "stdout missing" mean on Unix?
Does it mean that there is no open file with fd 1?
The problem of this situation is that newly opened files will be assigned fd 1 automatically (at least on Linux with both open() and fopen()), and then accidentally get used as stdout if stdout missing is checked more than once, or if C libraries are called, or if the files are not CLOEXEC and processes are spawned.
So it might be worth thinking whether automatically opening /dev/null in fd 1 (and likewise fd 0 and 2) makes sense.
There are problems though with this, namely the fact that it would need to be done at process init to be effective, automatically altering the fd table, and requiring /dev to be present (if /dev is not mounted, one could instead use pipe() and spawn a thread to read from the other end, although this is pretty horrible).
This has potential security implications as well, since running a setuid program with no fd 0/1/2 could make it write data to random opened files (maybe something already mitigates this?).

An alternative would be to provide some functions in the standard library to put the standard streams into a "known good" configuration.  I don't think panicking on std* not being there is too problematic provided there's a reasonably simple way to stop it from happening.  Preferably one that works cross-platform and can dynamically detect the bad condition.
To bring up the situation with Python, I recall jumping through some rather questionable hoops to automatically detect missing stdout/stderr and redirect them to files.

On Linux stdout almost always exists

This does not hold true if our process is daemonized.
My two cents: Doing something automatically is un-rusty, because it will probably be the wrong thing in some situations. Thus leaving a possible (though unlikely) error to the user to handle (as in returning an IoResult) would be the most workable solution. We should also note that this could trigger an unused_result (or some such) warning depending on lint settings – perhaps we should suppress those by default.

I'm against having every single println! return an error stating that stdout doesn't exist, because that's something that is known at startup and should be handled at startup. Besides, how would you handle the error when panic! is unable to print to stderr?
Perhaps a method can be added that tells you the state of stdout stderr and stdin and another that lets you redirect them. This way if they point to nothingness you can choose to redirect the output to a file or something. Of course they'd still default to what this RFC proposes to prevent programs from panicking and then aborting when stdout and stderr aren't there.

Thumb up for this RFC. Even stderr and stdin would exists in some situation.

Hides an error from the user which we may want to expose and may lead to people missing panicks occuring in threads.

I don't think this is a problem. If the program is launched without stdout or stderr, than the user is intent to not seeing back traces from the console. If such back trace info is important, the program should restore them in a file manually.

because that's something that is known at startup

Wrong. A daemon has standard streams until it daemonizes. Also on POSIX, an attacker may try to disturb a process by closing it's stdio handles from the outside (those are available from /proc).

Besides, how would you handle the error when panic! is unable to print to stderr?

That's for the user to decide. Perhaps log a message to a file. Or do nothing. Or stop the world, because printing a result is the sole reason for this program to run. As I said, there is no right default solution.
Splitting the print call and the was_I_able_to_print() query in two could be an alternative; however that may be prone to race attacks (where an attacker closes the stream between the query and the action).

Probably. My point was that

closing standard streams is not startup related. It can by definition happen anywhere during the process.
you cannot be sure about the reason why a stream is closed / unavailable.

Case in point: I recently had a long-running process (written in Java if you must know) that I had started for the weekend. My colleague needed to change some settings, but it was running in my shell. So he hijacked my console (he has root access to the server) and sent some commands to the process. However doing so, he killed stdout by mistake. The process threw a ClosedChannelException. There went my weekend.

Perhaps a combination of these things?

println! and print! return Results which can be ignored and do not trigger unused_result.
A way to determine the current status of stdout stderr and stdin.
A way to redirect stdout stderr and stdin.
The current behavior of panicking if stdout or stderr do not exist is squelched since I cannot imagine it is ever desirable for your process to unconditionally panic and abort just because they're missing. If you really want to abort (you weirdo), there are multiple ways to do so such as println!(...).unwrap().

For panic!, I don't think the back trace is the important part of it. I think the 1st reason panic! exists  is abort the program because bad things happen. If the user could get the backtrace, it's cool. If not, that's OK because we have already saved the world.
I think it is always true that stdout is a easy to use but not reliable. Even "printf(3)" could return negative value to indicate errors(but not abort your program).

@retep998 Sounds good.

they should return std::io::Result, in line with reading/writing elsewhere.
could this also be implemented by reading 0 bytes or writing the empty string?
unconditionally or only when it isn't usable? Note: The latter case may be hard to implement but very useful.
I don't think it's as weird as you imagine, e.g. if the sole reason for my (possibly long-running) process' existence is to print! something, I may want it to abort once it finds that it cannot do so.

We also need to answer the question if there are any programs in the wild that depend on print! & friends' panicky behavior – in that case this would be a [insert drumroll here] breaking change...

unconditionally or only when it isn't usable? Note: The latter case may be hard to implement but very useful.

Well there's three options for that.

Unconditionally redirect output. So if you realize you have no stdout, just redirect everything there from then on, even if stdout reappears, just consistently redirect.
Have a fallback that is only used when stdout doesn't exist, and when it does exist just use `stdout.
Have a FnOnce that is invoked to get a fallback the moment a write to stdout fails due to no stdout and that fallback is used from there on out so long as stdout doesn't exist. Useful so that you can open a file for redirection only if redirection is needed.

unconditional redirection is useful in any event. So this should be implemented anyway.
2/3. How would we supply that fallback to the print! macro?

It seems there is already a way to redirect stdio via std::io::stdio::set_print, although it is both unstable and hidden from the docs. It's also thread-local which may or may not be desirable.
I'm not sure how conditional redirects would work, since the only way to tell if redirecting is needed if an attempt is made to get stdout and it fails. Either you'd have to attempt to get stdout every single time you write (which can't be good for performance), or you'd just have to permanently fallback from then on out (unless the user's code attempts to redirect it back to the actual stdout).

The docs on set_print state that it may well be replaced by a "more general mechanism". A good thing is that we only depend on Stdout and Stderr to impl Write. This offers us a lot of flexibility to wrap, exchange or otherwise mangle the streams (however, we should be careful about what happens e.g. with popen'd processes).
And I think having the fallback install permanently on failure would be acceptable. This could also be implemented by a Write handler that attempts to Write to the default stdout, and on failure set up the fallback channel and repeat the Write (note we also may want to extend this behavior to processes started from, but not necessarily written in rust).

To extend the behavior to processes merely started from a Rust process would involve piping their output to our Rust process (so the Rust process would have to live longer than the child), plus it would no longer be a genuine console handle, which on Windows is a significant difference that would impair the child process's ability to use fancy console features.

Yes, a piped handle is distinctly non-interactive (also under Linux). Isn't that a well-known tradeoff? I suppose one could write a terminal emulation in rust, but it should not reside in std::io.

Note: this PR is in its Final Comment Period as of Yesterday

I'd really rather avoid by default modifying the behavior of stdio we pass to child processes for the sake of protecting them. Child processes can protect themselves and they should be responsible for cases where they inherit a missing stdout, otherwise we're just getting into the realm of overly obtrusive hand-holding.
As for modifying the return value of println!, as far as I can tell there is no way to allow unused_result for a specific function/macro. Never mind that it would be a breaking change to one of the most used methods in Rust.
I think I'm pretty happy with this RFC just stopping your program from panicking (and then aborting) because someone decided to run your process without a console on Windows or as a daemon. If someone wants to handle the errors then they already have the option of using std::io::Stdout which has methods that return Result. Plus this RFC mandates that the future raw stdio methods will return a Result so you'll know before you even attempt to write whether or not the handles exist so you can take immediate action. Any sort of complex error handling or fallback behavior can be implemented on top of those primitives with some sort of wrapper.

:+1: from me then.

:+1: from me.
Even if the process has stdio set up, there's a small window of time during process shutdown when retrieval of the global handle will fail: https://github.com/rust-lang/rust/blob/master/src/libstd/io/stdio.rs#L241. It seems like it'd make sense to return a sink there as well instead of panicking.

This RFC looks like it has fairly broad consensus at this point, and it fits into the model of picking a reasonable set of defaults for behavior in the standard library. The standard I/O streams are already locked and buffered, so there's a good deal of machinery happening behind the scenes to start out with, and this is not necessarily adding an undue amount of extra burden. Furthermore, raw access to the stdio streams is still planned which will bypass all of these points, allowing for finer-grained control of the output of a program.
Thanks again for the RFC @retep998!


Potential Issues in  section 7.7.4 Data

Hi I recently discovered your book. It's very helpful and I am thinking of using it with my students.
I wonder if you have issues in section 7 starting at 7.7.4.
https://ismayc.github.io/moderndiver-book/7-hypo.html#data-1
movie_example.pdf

Hi Kota, thanks for filing this issue. Could you elaborate further on what you mean by "issues"? The book does not compile at that section? thanks

Hi, I attached a PDF file above. I couldn't attach R-file directly.
When you regress  "rating" on "genre" (page 6),  p-value of the coefficient is 0.013.  When generating a histogram with bootstrapping, it should show about 1.3% of rejection region (page 9).  The bootstrap version of p-val was calculated to be 0.0156 (page 9).
That's slightly different from regression p-val, which assumes normal distribution of error.
On the website, you have figure 7.10 and 7.11.  It's not showing the correct rejection region, I believe.  This is in contrast to what you did for Figure 7.4.

I really like sections 3-5. I never knew how to use dplyr functions.  This book can become a very good cookbook for a modern introduction to R and data exploration.
I am an economist, so I am looking at Microeconometrics by Cameron and Trivedi.
For example, on p359 it has;
"For asymptotic refinement to occur, the statistic being bootstrapped must be an asymptotically
pivotal statistic, meaning a statistic whose limit distribution does not depend
on unknown parameters."
"Estimators are usually not asymptotically pivotal. However, conventional asymptotically
standard normal or chi-squared distributed test statistics, including Wald,
Lagrange multiplier, and likelihood ratio tests, and related confidence intervals, are
asymptotically pivotal."
p364;
"An asymptotic refinement is based on the t-statistic, which is asymptotically pivotal."
So, one can obtain bootstrap replications of t-statistics (i.e. (theta_bt - theta_obs)/theta_bt for each case of bootstrap replication bt)  and use its distribution to derive a confidence interval (equation 11.6 on page 364).
I could be wrong, so you might want to consult a statistician.

Hi Kota.  You found a typo where I used movies_trimmed where I should have used movies_genre_sample instead.  Using this aggregated data set that was created using group_by does mean that the ungroup() function is necessary to do shuffleing later for the permutation test.  I have updated the book to account for this in this commit.
I think that adding a parametric bootstrap down the road to the book does make sense so I have added the enhancement tag here.

Hi @kotamine, sorry for the extreme delay in replying, but we finally got around to revamping our approach to statistical inference, in particular using the new infer package for tidyverse-friendly statistical inference, so unfortunately your original questions and comments are now moot. If you'd like to preview our still "under construction" approach, take a look at the development version of Modern, in particular:

Chapter 8: Sampling
Chapter 9: Confidence intervals, both CLT and resampling based
Chapter 10: Hypothesis testing, both CLT and resampling based

If you have any questions or comments, please don't hesitate to file another issue!


G46 validate views

It would be better if users don't have to specify element group properties and their classes. They should only need to specify any transient properties required, the other properties should be looked up in the schema.

We need to consider changing the view so you only have to specify transient properties. Standard properties should be read from the schema.


Support construct BooleanArray from &[u8]

Which issue does this PR close?

Closes #.
Rationale for this change
Users can easily build BooleanArray from &[u8]

What changes are included in this PR?

add impl From<&[u8]> for BooleanArray
add impl From<&[u8]> for BooleanBuffer

Are there any user-facing changes?

I'm not sure about this, as it doesn't provide a mechanism to indicate a length that isn't a multiple of 8 or aligned.
Perhaps you could expand on what the use-case for this is, and why you would be using this as opposed to say BooleanBufferBuilder or similar?

I'm not sure about this, as it doesn't provide a mechanism to indicate a length that isn't a multiple of 8 or aligned.
Perhaps you could expand on what the use-case for this is, and why you would be using this as opposed to say BooleanBufferBuilder or similar?

Here, we only convert each bit in &[u8] to boolean and use it to build BooleanArray. It does not involve directly setting certain internal components, so there is no need to consider alignment and whether the length is a multiple of 8.
For example, in some scenarios, we need to use a bitstream (represented as &[u8] in Rust) to construct objects of type BooleanArray, where each bit in the bitstream is 1 for true and 0 for false.
If we didn't have this PR, we would always need to:

first build Buffer from &[u8],
then build BooleanBuffer from Buffer, and
finally build BooleanArray from BooleanBuffer.

Alternatively, we need to convert the bitstream into an iterator object that returns a boolean, but these come at a performance loss.

Of course, using this method involves two self-evident facts:

There is no null in the constructed BooleanArray
The length of the constructed BooleanArray is always a multiple of 8;

If these prerequisites are not met, then this method should not be used.
But these will not cause confusion or difficulty for users to understand, as the mapping from bit stream to boolean array is intuitive.

I wonder if this related to the 8 bit boolean extension type discussion on the dev list: https://lists.apache.org/thread/nz44qllq53h6kjl3rhy0531n2n2tpfr0 ?

I wonder if this related to the 8 bit boolean extension type discussion on the dev list: https://lists.apache.org/thread/nz44qllq53h6kjl3rhy0531n2n2tpfr0 ?

No, we are not building a new type here.
We are just providing a more convenient way to build BooleanArray from bitstream, which will have better performance and be more convenient under the premise of meeting usage requirements.

I thought about this more last night.
I think my main concern is if the semantics of BooleanArray::from(&[u8]) will be "surprising" to people
Thus I would like to propose making this a function like BooleanArray::from_u8 like
let arr = BooleanArray::from_u8(..)

We can put the documentation on that method. I think that would avoid any concern about confusion (as users would could the method explicitly).
What do you think?

I think your suggestion is more appropriate, and I will modify the code later.
The use of &[u8] to represent a bitstream is not so obvious and consistent (&[u8] can only represent a partial bitstream).
The From trait is not only used to represent conversions between types, but also declares a semantically equivalent relationship.I get it.
I am a beginner in Rust, thanks for your code review: )

Might I suggest something along the lines of
fn from_packed(buffer: impl Into<Buffer>, offset: usize, len:usize)

This would be explicit and consistent with other methods

Might I suggest something along the lines of
fn new_from_packed(buffer: impl Into<Buffer>, offset: usize, len:usize)

This would be explicit and consistent with other methods.
Edit: although I wonder if this is then really all that different from
let a: BooleanArray = BooleanBuffer(b.into(), 0, len).into();

I wonder if we really need a new method...

This is what I mentioned in my previous reply "providing a more convenient way to build BooleanArray from bitstream".
As a developer who is very familiar with arrow-rs, this method is unnecessary, but for users, I think the provided interface should try to hide the internal structure as much as possible and maintain simplicity.

My feeling is this convenience comes at the expense of being rather confusing to users, especially those less familiar with the internal layout of arrow arrays. My 2 cents is if people want a convenient and easy interface they can use the builders or iterators, if they want lower level integration they use lower level interfaces, providing a method that is convenient but correct usage requires knowledge of the lower level structure seems undesirable.
If Andrew is happy to move forward with this I have no objection to this, but I'm not sold

I agree that it takes a lot of knowledge until this is obvious:
let a: BooleanArray = BooleanBuffer(b.into(), 0, len).into();

It seems to me adding an example of how to do this in the documentation is valuable in any case.
I also think it is valuable to add APIs that make arrow-rs easier to use for less expert users, even if that means they aren't the most concise, and thus I think an API such as proposd in the PR is a good addition

Thank you for the review and comments @tustvold

Thanks again @chloro-pn  and @tustvold


Updated the docs to split it in smaller chapters and use Flex

This replaces #268 and finishes the upgrade of docs.

@stof @javiereguiluz what's the status of this PR?
it would be nice to merge it asap, because i'd like to add documentation about using timestampable with traits to fix this issue: https://github.com/stof/StofDoctrineExtensionsBundle/issues/367


Fixed the dds package name mistake in packages/README.md

There are duplicated drivers name - https://github.com/xuqingkuang/FluidFramework/blob/main/packages/README.md

Thank you.


Feature/persist communication requests

Bug fixes in communication requests site persistence.
This PR is a prerequisite for https://github.com/uwcirg/ePROMs-site-config/pull/61 and https://github.com/uwcirg/TrueNTH-USA-site-config/pull/55

Hello @pbugni! Thanks for submitting the PR.

In the file portal/migrations/versions/d0b40bc8d7e6_.py, following are the PEP8 issues :

Line 26:1: E302 expected 2 blank lines, found 1