minimal libc + posix: add strerror and perror functions

Add basic strerror() and perror() implementations to the minimal C library.
Also add myself as collaborator in that area.
With a simple change to samples/hello_world, we observe the following size differences on cortex-m3:
Before change:
Memory region         Used Size  Region Size  %age Used
           FLASH:        8576 B       256 KB      3.27%

After change (CONFIG_MINIMAL_LIBC_STRING_ERROR_TABLE=n):
Memory region         Used Size  Region Size  %age Used
           FLASH:        8576 B       256 KB      3.27%

After change (CONFIG_MINIMAL_LIBC_STRING_ERROR_TABLE=y):
Memory region         Used Size  Region Size  %age Used
           FLASH:       10852 B       256 KB      4.14%

Fixes #46099
Fixes #46100

Coding guideline issues are a false positive

An additional 2kB just for strings seems excessive. I might look into gperf for the table.

Need to update https://github.com/zephyrproject-rtos/zephyr/blob/main/doc/services/portability/posix.rst as well.

Good catch - will do.

Also as per #45776 and the previous discussion on the scope of the minimal libc, I am not convinced this should be a part of the minimal libc because:

The original intent of the minimal libc was to provide only the minimal amount of functions required to make Zephyr run for testing and validation as per @nashif's comments in the linked discussion.

Yes, definitely.
Another aspect about the minimal libc, was to minimize the amount of maintenance necessary as well. This implementation of strerror() requires only a negligible amount of maintenance. Quite literally just maintaining errno.h, which is something we do already.
I can definitely see the frustration about manually maintaining a separate table of error strings that would rely on a human to remember to update. At least this way it's minimal in that sense.

These functions are not required by any of the Zephyr internal components.

Note: perror() is a PR to lib/posix and not to the libc. It's a common function used on posix systems and references strerror() in most implementations. If perror() exists, then most likely strerror() would exist as well. I would suggest using a Kconfig regardless of the libc though to explicitly include the error string table.

We will be moving on to using the picolibc as the default C library instead of the minimal libc in the near future, in which case the latter will be reserved only for internal testing and validation purposes and will not be used by end users/products.

That works for me too - I would make this PR to picolibc as well, if it does not already have strerror().
I wouldn't necessarily say with absolute certainty that users/products will not use the minimal libc though. If it's in-tree (rather than a module) that might be enough for some organizations to stick with it, as the cost of adding / updating another repo is large in comparison.

Nevertheless, I am not necessarily opposed to merging this because we have added other "non-essential" features to the minimal libc before, and this feature can be configured such that it does cause any meaningful footprint increase.

Thanks. Yeah, I thought that would be a concern for sure, and so wanted to make the default "no code size increase".

Note: also played around with a "small medium large" configuration, including Kconfig template
https://pastebin.com/HYdihnVh

I would make this PR to picolibc as well, if it does not already have strerror().

picolibc is a full-fledged C library that is based on the newlib, but as small as the minimal libc.

added tests
Coding guidelines issues are false positives

rebase
remove civetweb-related changes
resolve picolibc-related conflicts

I question the utility of making the underlying strings optional; applications using these functions probably expect them to do something useful.

Probably. That's why I changed the default to 'y'. So if the user explicitly n-selects this option, they should know what the side-effects will be (by reading the Kconfig help section).
It's definitely useful to save 2KiB on some systems, but also enables the lazy dev by not requiring them to change application code.

I'd prefer if the tests were extended to support newlib and picolibc, but I don't see that as a blocker to merging this as-is.

Done! Actually found & filed a bug in newlib (or rather our build of newlib) in the process (#46846).

Compliance checks are false positives

Invert logic for CONFIG_MINIMAL_LIBC_STRING_ERROR_TABLE => CONFIG_MINIMAL_LIBC_DISABLE_STRING_ERROR_TABLE.

This reduces complexity of conditionals significantly

skip tests for CONFIG_ARCMWDT_LIBC

That seems to have a similar failure mode currently to CONFIG_NEWLIB_LIBC and should be addressed in #46846

Codecov Report

Merging #46101 (872f7a9) into main (88ca3ac) will increase coverage by 0.00%.
The diff coverage is 69.76%.

:exclamation: Current head 872f7a9 differs from pull request most recent head fe1d463. Consider uploading reports for the commit fe1d463 to get more accurate results

@@           Coverage Diff            @@
##             main   #46101    +/-   ##
========================================
  Coverage   49.95%   49.96%
========================================
  Files         649      652     +3
  Lines       81822    81986   +164
  Branches    19283    19340    +57
========================================
+ Hits        40874    40963    +89
- Misses      34150    34192    +42
- Partials     6798     6831    +33

Impacted Files
Coverage Δ

include/zephyr/kernel.h
100.00% <ø> (+1.05%)
:arrow_up:

include/zephyr/sys/cbprintf.h
100.00% <ø> (ø)

include/zephyr/rtio/rtio.h
69.76% <69.76%> (ø)

subsys/testsuite/ztest/src/ztest.c
54.58% <0.00%> (-4.84%)
:arrow_down:

subsys/net/lib/config/init.c
44.27% <0.00%> (-1.53%)
:arrow_down:

subsys/net/lib/sockets/sockets.c
45.26% <0.00%> (-0.20%)
:arrow_down:

...ubsys/bluetooth/controller/ll_sw/ull_llcp_common.c
77.40% <0.00%> (-0.20%)
:arrow_down:

subsys/bluetooth/controller/ll_sw/ull_conn.c
38.18% <0.00%> (-0.06%)
:arrow_down:

...sys/bluetooth/controller/ll_sw/ull_llcp_internal.h
100.00% <0.00%> (ø)

subsys/rtio/rtio_executor_concurrent.c
60.21% <0.00%> (ø)

... and 6 more

Continue to review full report at Codecov.

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

Looks like some CI issue atm - will see if I can re-run

Yea, GitHub is having (yet another) bad day.
https://discord.com/channels/720317445772017664/733037738068148335/991718319310766090

@keith-packard - could use your review here as well

Let's have the strings present by default so that naive apps 'just work'.

@keith-packard - I've flipped and I've flopped already. Am going to go with the maintainer's request here.
https://github.com/zephyrproject-rtos/zephyr/pull/46101#discussion_r906165749

rebase / resolve conflicts in tests/lib/c_lib/testcase.yaml after #46969

@stephanosio, @keith-packard - please re-ack :-)

@keith-packard can you please re-approve?


Start making unit testing more general

As part of https://github.com/pydata/xarray/issues/525, I would like to start running the same tests already implemented for pint on other unit libraries - the one I'm specifically interested in is astropy.
This PR is a proof of concept to start making the tests in test_units.py more general, so it's easy to implement tests against other unit libraries. Important bits of this PR:

The UnitInfo base class, which defines an interface against which additional unit libraries can be implemented.
Concrete implementations of this for pint and astropy (the astropy one is commented out for now)
Modifications that make test_apply_ufunc_dataarray run for both astropy and pint.
A few new tests for helper functions, that I needed to fix issues with astropy testing

Would be greatful for feedback - is this worthwhile? If so, I can roll this approach out to more tests in test_units.py (there's certainly a lot of them!), either in this PR or a subsequent one.

Hi @dstansby, thanks for taking initiative on this! Supporting other units-aware packages would be awesome.
Are you aware of our efforts around https://github.com/pydata/xarray/issues/6894? The idea there was to create a general framework for downstream testing of duck-array libraries, including any implementations of units.
I think the ideas you are proposing here are useful and important, but we should probably discuss what we want the end state of duck-array test suites to look like.
cc @keewis

I was not aware of https://github.com/pydata/xarray/issues/6894, which is definitely my bad for not searching properley before setting off 😄
It looks like the changes I'm proposing here are probably orthogonal to work in https://github.com/pydata/xarray/issues/6894 though? The new tests added in #6894 still use pint as the single unit library and add some new tests with the new hypothesis strategies, but the goal of this PR is to generalise the existing unit testing to make it a bit easier to run tests with different unit libraries. Also definitely agree that keeping the end goal for duck arrays in mind is important, but I think that testing for unit libraries is a bit less general than the duck array testing stuff, because there's a host of extra information you need to be a unit library compared to a general duck array.
Anyway, definitely agree that it would be good to have the end goal in mind here. Not sure if I'll be able to find time for a synchronous discussion, but happy for others to do that and report back, or happy to chat async somewhere that isn't a github issue if that would be helpful.

I was not aware of https://github.com/pydata/xarray/issues/6894, which is definitely my bad for not searching properley before setting off smile

No worries! :grin:

It looks like the changes I'm proposing here are probably orthogonal to work in https://github.com/pydata/xarray/issues/6894 though?

I think generally yes they are, I agree.

the goal of this PR is to generalise the existing unit testing to make it a bit easier to run tests with different unit libraries

Any work that helps generalise xarray's support of units beyond specifically just pint is going to be useful!
My main point to draw your attention to is the idea that eventually, one-day, it would be nice to move all array-library specific testing out of the xarray core repo in favour of an approach similar to that proposed in #6894.

I think that testing for unit libraries is a bit less general than the duck array testing stuff, because there's a host of extra information you need to be a unit library compared to a general duck array.

This is also true. Maybe that means for example the base class you are writing here has a long-term future as an optional part of xarray's testing framework in #6894, specifically for use when testing units libraries? Just thinking out loud

I think this is good for review now? There's plenty of tests lower down the file that can be generalised using the new framework I've introduced, but I think worth leaving that to another PR to make this one easier to review.

Closing since I don't have time to work on this any more


correct linux mapping error

Description
Fixes inconsistent Linux mapping found by mapping verification script
Issues Resolved
Fixes inconsistent Linux mapping found by mapping verification script
Check List

[ ] New functionality includes testing.

[ X] All tests pass

[ ] New functionality has been documented.

[ ] New functionality has javadoc added

[ ] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Codecov Report

Merging #263 (cebda1b) into main (887be34) will decrease coverage by 0.07%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##               main     #263      +/-   ##
============================================
- Coverage     38.02%   37.95%   -0.08%
+ Complexity      887      883       -4
============================================
  Files           176      176
  Lines          6795     6795
  Branches        834      834
============================================
- Hits           2584     2579       -5
- Misses         3974     3977       +3
- Partials        237      239       +2

Impacted Files
Coverage Δ

...g/opensearch/securityanalytics/model/Detector.java
68.85% <0.00%> (-1.74%)
:arrow_down:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


CODEX-MARKETPLACE: New Raw RFC

A raw RFC for Codex marketplace design. Open discussion to create a Codex node RFC which should be referenced in this RFC and future Codex RFCs.
Discussion Reference: https://github.com/vacp2p/rfc-index/pull/36
Implementation Reference: nim-codex

Superseded by https://github.com/codex-storage/codex-spec/pull/2


🐛 "Camera View" is not Fabric compatible yet

What were you trying to do?
I am using vision camera in rn 0.71.4. There I am, getting this error message. Is that possible to run the vision camera with fabric enabled?

Reproduceable Code
I used the code from the demo application in this repo.

What happened instead?
Camera not opening because of this.
Relevant log output
No response
Device
Pixel 5(Android 11), Nokia 5.3(Android 12)
VisionCamera Version
2.15.4
Additional information

[ ] I am using Expo
[X] I have read the Troubleshooting Guide
[X] I agree to follow this project's Code of Conduct
[X] I searched for similar issues in this repository and found none.

same issue... need help

Same

Anyone find a solution to this?  App requires new RN architecture..  Anyone know how to disable fabric but keep new architecture?

I am facing this same issue. Any workaround?

@mrousavy please help suggest if the camera feature is not available yet for android? Getting same error "Camera View" is not fabric compatible yet. Also if there is any workaround we can try to still run camera with fabric on both android and iOS. Thanks

The same problem in the IOS is no problem

 The same problem in the IOS is no problem

newArchEnabled=false
I set this configuration to false first, because it is not compatible, when will it be compatible?

Just like all 5 of you discovered, VisionCamera is not yet fabric compatible.
I didn't work on making it Fabric compatible yet. If you want me to make it run on Fabric, either wait until I have the free time to do so, or pay me to do it: sponsor me on GitHub :)

Hey,
I have prepared an initial support for fabric: https://github.com/mrousavy/react-native-vision-camera/pull/1684

I overcame the issue with the help of this discussion article.
https://github.com/reactwg/react-native-new-architecture/discussions/135
It may not be an absolute fix but it doesn't hurt to try.
I created react-native.config.js file and updated it like here; if you want to know why I use this config file find the discussion article above.
module.exports = {
  project: {
    android: {
      unstable_reactLegacyComponentNames: ['CameraView'],
    },
    ios: {
      unstable_reactLegacyComponentNames: ['CameraView'],
    },
  },
};

module.exports = {
project: {
android: {
unstable_reactLegacyComponentNames: ['CameraView'],
},
ios: {
unstable_reactLegacyComponentNames: ['CameraView'],
},
},
};

@mrousavy  Somehow I am able to build the library with this inter-op layer change with Fabric on React Native 0.72.6, but still I see few issues with Events, please

module.exports = {
project: {
android: {
unstable_reactLegacyComponentNames: ['CameraView'],
},
ios: {
unstable_reactLegacyComponentNames: ['CameraView'],
},
},
};

@mrousavy Somehow I am able to build the library with this inter-op layer change with Fabric on React Native 0.72.6, but still I see few issues with Events, please check the screenshot

same for me

Any one manage to fix this issue?

Same issue. Any updates?

https://github.com/mrousavy/react-native-vision-camera/issues/1554#issuecomment-1628498006

I'm using vision camera 3.8.2 and still recieving this error message, isn't this new version supposed to have fabric support?

also waiting for a fix

+1

@ravindraguptacapgemini @turkergercik
https://github.com/mrousavy/react-native-vision-camera/pull/2569


Fixup for props reference

I just noticed this when I was checking out the travis build for my other PR :)

Thanks!


Switch to bootstrap5

add bootstrap5 content
switch to grid layout (sidebar left, toctree right, etc)

this PR additionally does a full cleanup of old and unused content

Mmmh, looks a bit shitty; especially the api-ref stuff and I did not start to talk about the functionality of several buttons etc. We should discuss this is a meeting with more people than us.
But the current result does not change my opinion that I am satisfied with the switch to BS5 or we have to spent additional weeks of tuning and drop the work done in the past couple of weeks.

oh yeah, api-ref I missed completely

I am not completely against turning to BS5, but it is sad that we waste lot of time in tuning the old crap. That's a bit sad.

that is not an argument to stick to ancient toolset and continue fighting with those overrides. Atm there is no need to have "!important" overrides at all (maybe just one). From my pov it is worth of doing switch - this will make like easier in future. Will work on fixing api-ref later today

actually all of the changes for api-ref need to be done in otc-api-ref now. I will take care setting up jobs that test this 2 projects together

I know, I am still working on it (explicitly this is being deleted), but not pushed due to work on api-ref part


Activity Context

Add IActivityContext
it should support serialization into string
Every Receptor have to return IActivityContext (Add NullActivityContext)
activityContext could be set to Receptor (Automatically check that it's set at the beginning of each method that receives activityContext as parameter)
Multiplexor have to return a combined activityContext and spread its content to its Receptors

There is no need to pass ActivityContext in each method since there is a AsyncLocal mechanism in .NET. This mechanism allows to create activities in the signal receptors and just ignore the whole topic in the client's code.
The async/await pattern can be worked around with the AsyncLocal mechanism. So the receptor can have a common library with a common variable of type AsyncLocal and just save the current "Activity" into it.
Reference: https://learn.microsoft.com/en-us/dotnet/api/system.threading.asynclocal-1?view=net-8.0
OpenTelemetry is already doing this by default.

No need to implement this whole topic


[build] Android API 26, get Windows builds on Jenkins

Download-Xamarin-Android needs to "copy" from temp, since the bots have temp in D:\ and you can't do a "move" operation across drives
Added a Jenkins cake target to replace AppVeyor
Switch to Android API Level 26 and TargetFrameworkVersion v8.0 by default. Jenkins PR bots did not have an option to provision API 24.
Updated to Android Support Libs 26.x

Changes for latest Android Studio + Windows

Updated .gitignore
Removed files we don't need to check into source control
Changed option for max heap size that was erroring on Windows
Use --stacktrace option when running gradle, so we get error messages
Updated Android test project to API 26

TODO in future PRs:

Drop everything that says "AppVeyor"

Build and tests passed.

Build and tests passed.


feat: warn user about high costs

FEEDBACK WANTED.
Currently I have played around with putting the warning in two spots. A popover when clicking the swap BTN and in the swap modal itself.  I liked the idea of not adding clicks to the process, but the entire message bloated the swap modal up.
Possibilities:

Show only Popover on swap button
Show warning in modal
Show  full warnings in both places (kind of like in the pictures but with all info in modal)
Show the warning popover when clicking the Start cross chain swap BTN in modal

Good job 👍
I like the warning BEFORE you enter the Swap Modal (the popover) best. No need to even get there if the route doesn't make sense.
I also think the extra click needed ist not a big deal since this should only show up if the Route result is really bad (we might have to define what that means). For "good" routes this shouldn't show up so in the normal flow the user won't be bothered by it.


DerivativeIntegrator for 1D embedded geometry

I think this minor change allows to address https://github.com/mfem/mfem/issues/2402.
A simple SS shows a diffusion problem (- d^2 u/ ds^2 = 1) solved along 3/4 arc, where s
is a length along the path. The solution is u(s) = - s^2/2 + 2.776
u (right top panel) and -du_x*y + du_y *x (right bottom) seems correct to my eyes ;D

PR
Author
Editor
Reviewers
Assignment
Approval
Merge

#2403
@sshiraiwa
@tzanio
@mlstowell + @psocratis
07/13/21
⌛due 07/27/21
⌛due 08/03/21

This PR is now under review (see the table in the PR description). To help with the review process, please do not force push to the branch.

Merged in next for testing...


Do you have the plan to support Java like xgboost4j?

Do you have the plan to support Java like xgboost4j?

I need it too for one of the highly important Microsoft customer...
predict4j - does not work with current version (fails because default_values missing in 2.0.7 model).
pmml conversion - does not work either, fails by double -> int cast somewhere in model

the spark version will release on mmlspark (https://github.com/Azure/mmlspark ) soon.

ping @rmhasan
the pmml seems is broken for the newer version. could you help to bring it back ?

Exporting LightGBM to PMML, and then scoring using a Java PMML engine should count as a viable option in the meantime.
I've updated my JPMML-LightGBM exporter library to be fully compatible with the latest LightGBM v2.0.7 (including the handling of categorical/binary features and missing values). Better yet, it provides some custom functionality such as limiting the number of trees (similar to the num_iteration parameter of LightGBM's Scikit-Learn API), and compacting individual trees.
Tree compaction involves 1) expanding LightGBM-style binary splits into PMML-style multi-way splits, 2) eliminating half terminal nodes (aka leafs) and 3) eliminating redundant tree splitting predicates. It leads to >50% reduction in PMML file size.

cf: https://github.com/Azure/mmlspark/issues/173

@vladimir-vilinski @liulhdarks @vruusmann  I've checked in the code to generate SWIG Java wrappers to LightGBM repo
To build, you just need to run:
mkdir build ; cd build
cmake -DUSE_SWIG=ON ..
make -j4
The jar file is also available in maven central:
https://repo.maven.apache.org/maven2/com/microsoft/ml/lightgbm/lightgbmlib/
You can import it with sbt via:
"com.microsoft.ml.lightgbm" % "lightgbmlib" % "2.0.120"
I also have a PR open to add LightGBM to MMLSpark, a package for apache spark distributed data processing framework:
https://github.com/Azure/mmlspark/pull/235
If you have any suggestions for how to improve the SWIG wrappers or have any general questions please let me know.

@guolinke , let's remaining this open for further discussion.

@chivee @guolinke - @drdarshan suggested that the Java bindings could be improved by using SWIG typemaps.  This would be more customized code but it would remove the need for developers to deal with SWIG pointer types.  I think this is an improvement that we could add in the future for developers who use the Java bindings directly (and not our spark-based learners).

Does this[1] solve the problem?
[1]: https://mvnrepository.com/artifact/com.microsoft.ml.lightgbm/lightgbmlib

@spkaplan yes, that is the package that I am maintaining.  However, the java interface still needs to be improved more, as I mentioned above.  I am open to suggestions from the community.  Right now the autogenerated wrappers are mainly only used in mmlspark in scala code, but anyone can use them.

@imatiach-msft Thank you for the quick reply! I had accidentally overlooked your previous comment regarding the jar. Thank you for pointing that out!

Closed in favor of being in #2302. We decided to keep all feature requests in one place.
Welcome to contribute this feature! Please re-open this issue (or post a comment if you are not a topic starter) if you are actively working on implementing this feature.


Exclude multiple directories with command line

Is there a way to exclude multiple directories from command line only? (example: exclude node_modules and build directory).

Thank you for reporting.
You can use jscpd RC with the following options
npx<EMAIL_ADDRESS>--ignore "**node_modules**,**build**" /path/to/code

Also, you can skill all lines from gitignore with following options:
npx<EMAIL_ADDRESS>--gitignore /path/to/code

Thank you!


codegpt login with oauth not possible due to redirects

I have been struggling to login to codegpt.  I continue to get an error after installing the extension and trying to sign up.  The error involves redirect URL problems.  When I attempt to sign in or sign up, I get redirected to this page: https://app.codegpt.co/agreements I receive the message "This page isn’t working".

I'm facing the same problem

Same issue.

Same issue. I tried in many browsers but I cannot log in.
Edit; I think I understand the cause of the problem. If you do not have a membership on the codegpt website, it does not direct you to the registration page. I created a membership by logging into the website from my mobile phone, and then when I logged in from my computer, the problem was solved.

Yes, I confirm that. Log in using mobile phone then worked reloading on computer worked.

Hello @BurakKaraalp  we are reviewing the login procedure by mobile. We will write to you as soon as possible.

@austinfarmer11 we have experienced some problems lately, but the web version of Studio is working now, please check again, clean the cookies and try!, Thanks in advance


How can I copy a nvgPaint from one context to another?

Hi, I'm trying to use one context to render an image using OpenGL, then use nvgImagePattern() to obtain a NVGPaint for it, and finally use that NVGPaint for a nvgFillPaint() operation in a different context. Is there a "proper" way to do this?
What about if one context uses GL2 and the other one uses GL3 (or GLES3)?
x/y problem statement: I'm writing a module for VCV Rack, which uses nanovg with GL2. The module is loaded dynamically into Rack. My module uses projectM to render visuals with OpenGL. On OSX, the shaders that projectM use require me to request an OpenGL3 context because they use GLSL 300 (according to this comment at least). So my solution (maybe very naive - I know next to nothing about OpenGL) is to create a separate NVGcontext for projectM rendering, possibly running the code for that in a separate thread, have it render to a texture, and use that texture as a NVGpaint to fill a shape in the "main" NVGcontext that Rack provides me (the GL2 one).
Thoughts? thanks!

I don't think there's any proper way to do that.
I've reread your question maybe 10 times, and still not quite sure what you want to do. I sounds like half half way implemented wrong idea :)
So, if I understood correctly, you want to render something cool with projectM, and display that with NanoVG?
In that case all you need to do is to share the texture you rendered to between the two OpenGL  contexts, and use nvglCreateImageFromHandleGL2() to obtain NanoVG image handle which you can pass to nvgImagePattern(). You should call nvglCreateImageFromHandleGL2() when the render target is created, not every frame.
I don't know how to share textures between OpenGL contexts.

Sorry for the unclear question - it's kind of a mess. Here's a short writeup in case someone else finds this issue in the future:
What I wanted to do was render some library's stuff (projectM) which requires an OpenGL 3.3 core context, but I'm embedded in a program (VCV Rack) that gives me a context of less than that.
As it turns out, I didn't need to do anything at the NVG level. All I had to do was:

Split the rendering of projectM into its own thread
Before rendering projectM, create a new context with glfw that sets GLFW_VISIBLE to false and the relevant version hints to 3.3 core.
Tell projectM to render to a texture, and share that texture ID with the main thread
To allow the texture to be shared, I had to change the glfwCreateWindow() call so that its parent window argument is set, and points to the application's window. Fortunately the application's window is a global and I can access it.
Add the relevant mutex synchronization to signal to the main thread when my rendering is done.

Nice you found the solution!


Opensearch slawosz

Description

Checklist:

[ ] Have you documented your changes in the pull request description?
[ ] Does the change present any security considerations?
[ ] Is any gem functionality overloaded? Eg: Devise controller methods being overloaded.
[ ] Has acceptance criteria been tested by a peer?
[ ] Has the CHANGELOG been updated? (If change is worth telling users about.)

General testing (author)

[ ] Test without JavaScript
[ ] Test on small screen

Accessibility testing (author)

[ ] Works keyboard only
[ ] Tested with one screen reader
[ ] Zoom page to 400% - content still visible
[ ] Disable CSS - does content make sense and appear in a logical order?

Codecov Report

Merging #1715 (bda7912) into master (8545dd2) will decrease coverage by 78.65%.
The diff coverage is 75.00%.

@@             Coverage Diff             @@
##           master    #1715       +/-   ##
===========================================
- Coverage   89.70%   11.05%   -78.66%
===========================================
  Files         399      399
  Lines        8578    12187     +3609
  Branches     1241      374      -867
===========================================
- Hits         7695     1347     -6348
- Misses        703    10778    +10075
+ Partials      180       62      -118

Impacted Files
Coverage Δ

app/controllers/health_controller.rb
0.00% <0.00%> (-76.93%)
:arrow_down:

app/helpers/search_helper.rb
63.63% <0.00%> (-27.28%)
:arrow_down:

app/helpers/investigation_search_helper.rb
41.86% <100.00%> (-51.17%)
:arrow_down:

app/models/business.rb
80.00% <100.00%> (-14.29%)
:arrow_down:

app/models/concerns/investigation_opensearch.rb
100.00% <100.00%> (ø)

app/models/investigation.rb
84.15% <100.00%> (-11.89%)
:arrow_down:

app/models/investigation/allegation.rb
100.00% <100.00%> (ø)

app/models/investigation/enquiry.rb
100.00% <100.00%> (ø)

app/models/investigation/project.rb
100.00% <100.00%> (ø)

app/models/product.rb
79.48% <100.00%> (-20.52%)
:arrow_down:

... and 333 more

Continue to review full report at Codecov.

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


feat(Measure/Dirac): extensionality of measures by singletons

Two simple lemmas useful for discrete probability.

bors merge


collectd addon logs unhandled python exception every 20 s

[cs-admin@d-lin-auw2-control01 ~]$ sudo systemctl status -l collectd
● collectd.service - Collectd statistics daemon
Loaded: loaded (/usr/lib/systemd/system/collectd.service; enabled; vendor preset: disabled)
Active: active (running) since Wed 2016-07-20 18:13:02 UTC; 4min 53s ago
Docs: man:collectd(1)
man:collectd.conf(5)
Main PID: 24337 (collectd)
Memory: 9.0M
CGroup: /system.slice/collectd.service
└─24337 /usr/sbin/collectd -C /etc/collectd.conf -f
Jul 20 18:13:02 d-lin-auw2-control01 systemd[1]: Starting Collectd statistics daemon...
Jul 20 18:13:02 d-lin-auw2-control01 collectd[24337]: python plugin: Error importing module "mesos-slave".
Jul 20 18:13:02 d-lin-auw2-control01 collectd[24337]: Unhandled python exception in importing module: ImportError: No module named mesos-slave
Jul 20 18:13:02 d-lin-auw2-control01 collectd[24337]: python plugin: Found a configuration for the "mesos-slave" plugin, but the plugin isn't loaded or didn't register a configuration callback.
Jul 20 18:13:02 d-lin-auw2-control01 collectd[24337]: mesos-master plugin [verbose]: mesos-master plugin configured with host = d-lin-auw2-control01.node.consul, port = 15050, verbose logging = False, version = 0.22.1, instance =
Jul 20 18:13:02 d-lin-auw2-control01 collectd[24337]: zookeeper plugin: Configured with hosts=['d-lin-auw2-control01.node.consul']
Jul 20 18:13:07 d-lin-auw2-control01 collectd[24337]: Unhandled python exception in read callback: TypeError: float() argument must be a string or a number
Jul 20 18:13:23 d-lin-auw2-control01 collectd[24337]: Unhandled python exception in read callback: TypeError: float() argument must be a string or a number
Jul 20 18:14:03 d-lin-auw2-control01 collectd[24337]: Unhandled python exception in read callback: TypeError: float() argument must be a string or a number

Ansible version (ansible --version): 1.9.1
Python version (python --version): 2.7.12
Git commit hash or branch: june 2016 with personal commits
Cloud Environment: aws
Terraform version (terraform version): v0.6.14

@kbroughton Thanks for letting us know! Just so you know, this is going to be a pretty low priority issue for us as it is an addon, and we're working a lot on our k8s integration these days.

I believe with the most recent package of the collected provided by yum (5.6.0) this error is now treated as an exception on startup and collectd fails to start.
[root@worker-02 ~]# sudo service collectd restart
Redirecting to /bin/systemctl restart  collectd.service
Job for collectd.service failed because the control process exited with error code. See "systemctl status collectd.service" and "journalctl -xe" for details.

from /var/adm/messages
Nov  8 16:31:29 worker-02 collectd: python plugin: Error importing module "mesos-slave".
Nov  8 16:31:29 worker-02 collectd: Unhandled python exception in importing module: ImportError: No module named mesos-slave
Nov  8 16:31:29 worker-02 collectd: python plugin: Found a configuration for the "mesos-slave" plugin, but the plugin isn't loaded or didn't register a configuration callback.
...
Nov  8 16:31:29 worker-02 collectd: Error: Reading the config file failed!

It looks like the plugin is named "mesos-agent" but referenced as "mesos-slave".


[Documentation] The explanation about the options and CLI should be swapped.

The description for the devServer.pfx is wrong. The explanation about the options and CLI should be swapped.
describe your changes...

[ ] Read and sign the CLA. PRs that haven't signed it won't be accepted.
[ ] Make sure your PR complies with the writer's guide.
[ ] Review the diff carefully as sometimes this can reveal issues.
[ ] Do not abandon your Pull Request: Stale Pull Requests.
Remove these instructions from your PR as they are for your eyes only.

Invalid.


refactor(app-shell): Download buildroot update files in the background

overview
This PR adds simple buildroot file downloading to the app on update check along with download progress reporting. Closes #3557.
changelog

Download buildroot update files in the background

review requests
# new dependencies added
make install-js

# run with the BR FF on
make -C app dev OT_APP_DEV_INTERNAL__ENABLE_BUILD_ROOT=1

Note: current releases.json manifest on S3 does not have any releaseNotes entry, so no release notes will be downloaded
purposefully not implemented

releases.json is not currently saved to the filesystem

This would be really nice to have for release, but not strictly necessary

Old version downloads won't be cleaned up

Not necessary until BR release no. 2

Periodic background checks haven't been implemented

first launch expected behavior

Main process receives shell:CHECK_UPDATE action
Main retrieves releases.json from S3
Checks buildroot download folder for files:  path.join(userDataPath, '__ot_buildroot__', version)
Finds no directory / no files, so starts download
As download progresses, main dispatches buildroot:DOWNLOAD_PROGRESS actions to UI
Eventually, download finishes and main dispatches buildroot:UPDATE_INFO
Files in __ot_buildroot__/${version}

subsequent launch expected behavior

Main process receives shell:CHECK_UPDATE action
Main retrieves releases.json from S3
Checks buildroot download folder __ot_buildroot/${version} for files and finds them
Main dispatches buildroot:UPDATE_INFO

expected error behavior
Shut your Wi-Fi off and the manifest retrieval will fail. Kinda hard to induce errors during the download because even if you shut your wi-fi off the request would take minutes to timeout. You could trying finding the temporary directory and deleting the files mid-download? That seems annoying. Anyway:

Main process receives shell:CHECK_UPDATE action
Something goes wrong
Main dispatches buildroot:DOWNLOAD_ERROR with message
No files in __ot_buildroot__/${version}

Tested and working on my Windows 10 VM. Still waiting on Travis builds. If anyone wants to merge this while I'm out (and everyone is satisfied), please go for it


fix(promql): synch generated code

Closes #13955
The change was not detected by simply running make.
I had to make clean and then make. Is this the expected behavior?
Describe your proposed changes here.

[ ] CHANGELOG.md updated with a link to the PR (not the Issue)
[ ] Well-formatted commit messages
[ ] Rebased/mergeable
[ ] Tests pass
[ ] http/swagger.yml updated (if modified Go structs or API)
[ ] Documentation updated or issue created (provide link to issue/pr)
[ ] Signed CLA (if not already signed)

The make clean followed by make is expected behavior.


Added method to send to specific client

looks good. we'll add a unit test to this later and then merge it!

The "missing" NetworkServer method isn't an oversight. If you have the connection, you have conn.Send.  Adding this method would be a redundancy.

The "missing" NetworkServer method isn't an oversight. If you have the connection, you have conn.Send. Adding this method would be a redundancy.

What if we add a thin wrapper in NetworkServer like: "get connection[connid].Send(message)"?
This has been requested a few times already I think.

The "missing" NetworkServer method isn't an oversight. If you have the connection, you have conn.Send. Adding this method would be a redundancy.

What if we add a thin wrapper in NetworkServer like: "get connection[connid].Send(message)"? This has been requested a few times already I think.

I am also requesting this feature

I am also requesting this feature

Why do you want this instead of using conn.Send?

What if we add a thin wrapper in NetworkServer like: "get connection[connid].Send(message)"?
This has been requested a few times already I think.

Requested only by those that don't realize NetworkConnection has Send methods that should be used, likely.
None of NetworkServer's Send methods take a conn or conn id param, by design, because it'd be redundant. If we add one that does, we'll have to do it for all of them.

If you think it's not necessary then should we close the pull request?

If you think it's not necessary then should we close the pull request?

I'd say close as redundant unless @miwarnec disagrees.