width/height attributes removed after transforming to JSX

Suppose we have an SVG such as
 <svg width="61" height="52" viewBox="0 0 61 52" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
                                    <defs>
                                        <path d="M32 43.992c17.673 0 28.05 17.673 28.05 0S49.674 0 32 0C14.327 0 0 14.327 0 32c0 17.673 14.327 11.992 32 11.992z" id="bubble-1-a"/>
                                    </defs>
                                    <g fill="none" fill-rule="evenodd">
                                        <mask id="bubble-1-b" fill="#fff">
                                            <use xlink:href="#bubble-1-a"/>
                                        </mask>
                                        <use fill="#FF6D8B" xlink:href="#bubble-1-a"/>
                                        <path d="M2 43.992c17.673 0 28.05 17.673 28.05 0S19.674 0 2 0c-17.673 0-32 14.327-32 32 0 17.673 14.327 11.992 32 11.992z" fill="#FF4F73" mask="url(#bubble-1-b)"/>
                                        <path d="M74 30.992c17.673 0 28.05 17.673 28.05 0S91.674-13 74-13C56.327-13 42 1.327 42 19c0 17.673 14.327 11.992 32 11.992z" fill-opacity=".8" fill="#FFA3B5" mask="url(#bubble-1-b)"/>
                                    </g>
                                </svg>

width="61" height="52" will not be included in the JSX SVG. Is this is intentional? Previously it wasn't removing these attributes.

Hello @sakalauskas,
Thanks for reporting this issue, was fixed here - #43 🐛


Greenkeeper/@types/mocha 7.0.1

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


License

Hello, I would like to leverage this code and adapt based on my own needs. I would submit pull requests for any discrete features that I think might be useful for the greater set of users.
Is this codebase distributed under an open source license? If so, which one?
Thanks!

Thanks for showing interest in the project! The source is under MIT licensing. I'll be streaming new features in as time permits. Happy tweaking.
Sean

Thanks for showing interest in the project! The source is under MIT licensing. I'll be streaming new features in as time permits. Happy tweaking.
Sean

Great, thanks Sean!


Added data validation support while pub/sub

The objective of this PR is to integrate client-initiated data validation within the message publishing or subscribing workflow. It's important to note that I have conducted testing exclusively with JSON Schema at this stage. Raising this PR as an initial draft, I seek early feedback and welcome any constructive suggestions for enhancement.

Closing this. This feature has been discussed extensively among the architects and client developers. We decided not to integrate this behavior directly since it's trivial to do for a developer before sending a message and after receiving a message.
Also, for future PR's everything has to be 100% backward compatible, meaning existing public signatures cannot change.

Hello @scottf, thank you for prompt feedback on this. Could you kindly provide insights into any existing plans regarding this matter?

I've tried my best to ensure the code's full backward compatible, and the client API structure remains unchanged.
Could you kindly help me understand on the specific change you are referring to? This will aid in avoiding similar mistake in future.  TIA

I looked again at I think I mistook the constructor as public, when it was not, so your code was fine.

This project has examples of "encoding" https://github.com/nats-io/java-nats-examples/tree/main/encoding

I intend to integrate Schema Registry for NATS using apicurio. For same I had made changes in client code where user can instantiate APICurio's NATS Specific Implementation and pass it to NATSClient via Serializer/Deserializer Interface. This was the first draft of the change in NATS Client and based on the feedback on this PR I plan to proceed.  Apologies for missing out this detail in description.

I intend to enhance APICurio Schema Registry to support Nats data validation, for same I had made changes in Nats client code. It was the first draft where user can instantiate APICurio's NATS Supported Classes and feed them into NATS Client using Serialiser/Deserialiser Interface, based on feedback I planned to proceed further. Apologies for missing out this detail in description.

There have definitely been discussions about schemas, but I think the prevailing thought is that this needs to be a server feature, not a client feature.


Update zero-code.md

Change the sentence: "This means that requests and responses, database calls, message queue calls, and so forth are what are instrumented" to "This means that requests and responses, database calls, message queue calls, and so forth are instrumented" (ie remove the "what are")

@TomClqncy Thanks! Could you sign the CLA please?

@TomClqncy did you have a chance to look into the CLA?

Closing old PR


Cannot resolve type description for java.sql.ShardingKey

2018-10-23 17:28:24.492 [main] WARN co.elastic.apm.bci.bytebuddy.ErrorLoggingListener - ERROR on transformation com.microsoft.sqlserver.jdbc.SQLServerConnection43
java.lang.IllegalStateException: Cannot resolve type description for java.sql.ShardingKey
	at co.elastic.apm.shaded.bytebuddy.pool.TypePool$Resolution$Illegal.resolve(TypePool.java:136)
	at co.elastic.apm.shaded.bytebuddy.pool.TypePool$Default$WithLazyResolution$LazyTypeDescription.delegate(TypePool.java:1254)
	at co.elastic.apm.shaded.bytebuddy.description.type.TypeDescription$AbstractBase$OfSimpleType$WithDelegation.getModifiers(TypeDescription.java:7195)
	at co.elastic.apm.shaded.bytebuddy.description.ModifierReviewable$AbstractBase.matchesMask(ModifierReviewable.java:539)
	at co.elastic.apm.shaded.bytebuddy.description.ModifierReviewable$AbstractBase.isPublic(ModifierReviewable.java:313)
	at co.elastic.apm.shaded.bytebuddy.description.type.TypeDescription$AbstractBase.isVisibleTo(TypeDescription.java:6794)
	at co.elastic.apm.shaded.bytebuddy.matcher.VisibilityMatcher.matches(VisibilityMatcher.java:31)
	at co.elastic.apm.shaded.bytebuddy.matcher.VisibilityMatcher.matches(VisibilityMatcher.java:12)
	at co.elastic.apm.shaded.bytebuddy.matcher.NegatingMatcher.matches(NegatingMatcher.java:29)
	at co.elastic.apm.shaded.bytebuddy.matcher.ErasureMatcher.matches(ErasureMatcher.java:33)
	at co.elastic.apm.shaded.bytebuddy.matcher.ErasureMatcher.matches(ErasureMatcher.java:14)

$ java -version
openjdk version "1.8.0_181"
OpenJDK Runtime Environment (build 1.8.0_181-8u181-b13-0ubuntu<IP_ADDRESS>-b13)
OpenJDK 64-Bit Server VM (build 25.181-b13, mixed mode)

SqlServer lib:
<dependency>
    <groupId>com.microsoft.sqlserver</groupId>
    <artifactId>mssql-jdbc</artifactId>
    <version>6.5.1.jre8-preview</version>
</dependency>

This is a warning which can show for example, when there are optional types missing. Do you actually encounter any errors because of this?

The problem is that ShardingKey was introduced in Java 9 and you are running on Java 8. That's why this warning is shown when the DEBUG log level is enabled. Should be nothing to worry about.

Thanks for your reply, we all use java 8, is there a way to hide the warning or log it a  DEBUG level?

I think logging as DEBUG makes sense here. If you want you can provide a PR, otherwise I'm also happy to take this over.
You'd just need to change logger.warn to logger.debug in co.elastic.apm.bci.bytebuddy.ErrorLoggingListener.

Thank you very much.


Eric dev

Eric,
What are you trying to do?
I don't want to merge any of your stuff until we clean out all of the data
you have on your branch...
On May 25, 2015 4:36 PM, "ebridge2"<EMAIL_ADDRESS>wrote:

You can view, comment on, or merge this pull request online at:
https://github.com/openconnectome/m2g/pull/89
Commit Summary

this is a test
updating with the previous files I had in here...
two deletions because these scripts are elsewhere...
made some heavy changes overall, and imported a few new pipe files
a few changes to existing modules, and the completion of the voxel
tse
test
moved over some files I had locally been working on for correlation
matrix generation
removed unnecessary file
CPAC cli implemented and working...
cleaned up branch
changed a variable name
midifying to improve the multi subject functionality...
added a new branch for functional analysis and practicing
added sum of sine waves to verify fft being computed properly
reverted to original cpac pipe and added the new one separately
removed the cli
Merge branch 'eric-dev' of https://github.com/openconnectome/m2g
into eric-dev
updated the cli stuff
finalized the CPAC_cli and added all of the KKI data to it
updated fourier analysis to a higher signal length for a better
approximation
added correlation practice... modified workflow subject IDs
autosaved files removes
modified the subject sourcing
shortened the number of subjects to 7
updated the working path
added a cleaner for the CPAC generated reports
moved over all of the roi files for 2 runs
adding some correlation analysis files...

Hm. Never intended to do this...probably clicked a button accidentally while trying to undo a commit last night at like 4 am. Windows Git is not the same as command line git

how do I delete this request?


L515, Receiver light saturation error

Required Info

Camera Model
L515

Firmware Version
<IP_ADDRESS>

Operating System & Version
Ubuntu 20

Kernel Version (Linux Only)
5.14.0-1052-oem

Platform
PC

SDK Version
2.51.1

Language
ROS

Issue Description
prasad@prasad:~$ roslaunch realsense2_camera demo_pointcloud.launch
... logging to /home/prasad/.ros/log/9384b62c-485a-11ed-8f25-db5a6b863d8e/roslaunch-prasad-3272.log
Checking log directory for disk usage. This may take a while.
Press Ctrl-C to interrupt
Done checking log file disk usage. Usage is <1GB.
started roslaunch server http://prasad:46369/
SUMMARY
PARAMETERS

/camera/realsense2_camera/accel_fps: 0
/camera/realsense2_camera/accel_frame_id: camera_accel_frame
/camera/realsense2_camera/accel_optical_frame_id: camera_accel_opti...
/camera/realsense2_camera/align_depth: False
/camera/realsense2_camera/aligned_depth_to_color_frame_id: camera_aligned_de...
/camera/realsense2_camera/aligned_depth_to_fisheye1_frame_id: camera_aligned_de...
/camera/realsense2_camera/aligned_depth_to_fisheye2_frame_id: camera_aligned_de...
/camera/realsense2_camera/aligned_depth_to_fisheye_frame_id: camera_aligned_de...
/camera/realsense2_camera/aligned_depth_to_infra1_frame_id: camera_aligned_de...
/camera/realsense2_camera/aligned_depth_to_infra2_frame_id: camera_aligned_de...
/camera/realsense2_camera/allow_no_texture_points: False
/camera/realsense2_camera/base_frame_id: camera_link
/camera/realsense2_camera/calib_odom_file:
/camera/realsense2_camera/clip_distance: -1.0
/camera/realsense2_camera/color_fps: 30
/camera/realsense2_camera/color_frame_id: camera_color_frame
/camera/realsense2_camera/color_height: 480
/camera/realsense2_camera/color_optical_frame_id: camera_color_opti...
/camera/realsense2_camera/color_width: 640
/camera/realsense2_camera/confidence_fps: 30
/camera/realsense2_camera/confidence_height: 480
/camera/realsense2_camera/confidence_width: 640
/camera/realsense2_camera/depth_fps: 30
/camera/realsense2_camera/depth_frame_id: camera_depth_frame
/camera/realsense2_camera/depth_height: 480
/camera/realsense2_camera/depth_optical_frame_id: camera_depth_opti...
/camera/realsense2_camera/depth_width: 640
/camera/realsense2_camera/device_type:
/camera/realsense2_camera/enable_accel: False
/camera/realsense2_camera/enable_color: True
/camera/realsense2_camera/enable_confidence: True
/camera/realsense2_camera/enable_depth: True
/camera/realsense2_camera/enable_fisheye1: False
/camera/realsense2_camera/enable_fisheye2: False
/camera/realsense2_camera/enable_fisheye: False
/camera/realsense2_camera/enable_gyro: False
/camera/realsense2_camera/enable_infra1: False
/camera/realsense2_camera/enable_infra2: False
/camera/realsense2_camera/enable_infra: False
/camera/realsense2_camera/enable_pointcloud: True
/camera/realsense2_camera/enable_pose: False
/camera/realsense2_camera/enable_sync: True
/camera/realsense2_camera/filters:
/camera/realsense2_camera/fisheye1_frame_id: camera_fisheye1_f...
/camera/realsense2_camera/fisheye1_optical_frame_id: camera_fisheye1_o...
/camera/realsense2_camera/fisheye2_frame_id: camera_fisheye2_f...
/camera/realsense2_camera/fisheye2_optical_frame_id: camera_fisheye2_o...
/camera/realsense2_camera/fisheye_fps: 30
/camera/realsense2_camera/fisheye_frame_id: camera_fisheye_frame
/camera/realsense2_camera/fisheye_height: 0
/camera/realsense2_camera/fisheye_optical_frame_id: camera_fisheye_op...
/camera/realsense2_camera/fisheye_width: 0
/camera/realsense2_camera/gyro_fps: 0
/camera/realsense2_camera/gyro_frame_id: camera_gyro_frame
/camera/realsense2_camera/gyro_optical_frame_id: camera_gyro_optic...
/camera/realsense2_camera/imu_optical_frame_id: camera_imu_optica...
/camera/realsense2_camera/infra1_frame_id: camera_infra1_frame
/camera/realsense2_camera/infra1_optical_frame_id: camera_infra1_opt...
/camera/realsense2_camera/infra2_frame_id: camera_infra2_frame
/camera/realsense2_camera/infra2_optical_frame_id: camera_infra2_opt...
/camera/realsense2_camera/infra_fps: 30
/camera/realsense2_camera/infra_height: 480
/camera/realsense2_camera/infra_rgb: False
/camera/realsense2_camera/infra_width: 640
/camera/realsense2_camera/initial_reset: False
/camera/realsense2_camera/json_file_path:
/camera/realsense2_camera/linear_accel_cov: 0.01
/camera/realsense2_camera/odom_frame_id: camera_odom_frame
/camera/realsense2_camera/ordered_pc: False
/camera/realsense2_camera/pointcloud_texture_index: 0
/camera/realsense2_camera/pointcloud_texture_stream: RS2_STREAM_COLOR
/camera/realsense2_camera/pose_frame_id: camera_pose_frame
/camera/realsense2_camera/pose_optical_frame_id: camera_pose_optic...
/camera/realsense2_camera/publish_odom_tf: True
/camera/realsense2_camera/publish_tf: True
/camera/realsense2_camera/reconnect_timeout: 6.0
/camera/realsense2_camera/rosbag_filename:
/camera/realsense2_camera/serial_no:
/camera/realsense2_camera/stereo_module/exposure/1: 7500
/camera/realsense2_camera/stereo_module/exposure/2: 1
/camera/realsense2_camera/stereo_module/gain/1: 16
/camera/realsense2_camera/stereo_module/gain/2: 16
/camera/realsense2_camera/tf_publish_rate: 0.0
/camera/realsense2_camera/topic_odom_in: camera/odom_in
/camera/realsense2_camera/unite_imu_method: none
/camera/realsense2_camera/usb_port_id:
/camera/realsense2_camera/wait_for_device_timeout: -1.0
/rosdistro: noetic
/rosversion: 1.15.14

NODES
/camera/
realsense2_camera (nodelet/nodelet)
realsense2_camera_manager (nodelet/nodelet)
rviz (rviz/rviz)
auto-starting new master
process[master]: started with pid [3282]
ROS_MASTER_URI=http://localhost:11311
setting /run_id to 9384b62c-485a-11ed-8f25-db5a6b863d8e
process[rosout-1]: started with pid [3292]
started core service [/rosout]
process[camera/realsense2_camera_manager-2]: started with pid [3299]
process[camera/realsense2_camera-3]: started with pid [3300]
process[camera/rviz-4]: started with pid [3301]
[ INFO] [1665378938.552781403]: Initializing nodelet with 8 worker threads.
[ INFO] [1665378952.621563787]: RealSense ROS v2.3.2
[ INFO] [1665378952.621637488]: Built with LibRealSense v2.50.0
[ INFO] [1665378952.621669436]: Running with LibRealSense v2.50.0
[ INFO] [1665378952.662407861]:
10/10 10:45:52,977 WARNING [140193571010304] (messenger-libusb.cpp:42) control_transfer returned error, index: 300, error: Success, number: 0
10/10 10:45:53,140 WARNING [140193571010304] (messenger-libusb.cpp:42) control_transfer returned error, index: 300, error: Success, number: 0
10/10 10:45:53,196 WARNING [140193571010304] (messenger-libusb.cpp:42) control_transfer returned error, index: 300, error: Success, number: 0
[ INFO] [1665378953.294950512]: Device with serial number f0246007 was found.
[ INFO] [1665378953.295017781]: Device with physical ID 3-1-2 was found.
[ INFO] [1665378953.295043675]: Device with name Intel RealSense L515 was found.
[ INFO] [1665378953.295674030]: Device with port number 3-1 was found.
[ INFO] [1665378953.295713336]: Device USB type: 2.1
[ WARN] [1665378953.295745479]: Device f0246007 is connected using a 2.1 port. Reduced performance is expected.
[ INFO] [1665378953.300040243]: getParameters...
[ INFO] [1665378953.344546193]: setupDevice...
[ INFO] [1665378953.344572817]: JSON file is not provided
[ INFO] [1665378953.344582601]: ROS Node Namespace: camera
[ INFO] [1665378953.344594214]: Device Name: Intel RealSense L515
[ INFO] [1665378953.344606848]: Device Serial No: f0246007
[ INFO] [1665378953.344617202]: Device physical port: 3-1-2
[ INFO] [1665378953.344626958]: Device FW version: <IP_ADDRESS>
[ INFO] [1665378953.344638063]: Device Product ID: 0x0B64
[ INFO] [1665378953.344647258]: Enable PointCloud: On
[ INFO] [1665378953.344655563]: Align Depth: Off
[ INFO] [1665378953.344666389]: Sync Mode: On
[ INFO] [1665378953.344730508]: Device Sensors:
[ INFO] [1665378953.441244369]: L500 Depth Sensor was found.
[ INFO] [1665378953.461009292]: RGB Camera was found.
[ INFO] [1665378953.461485857]: Motion Module was found.
[ INFO] [1665378953.461626426]: Add Filter: pointcloud
[ INFO] [1665378953.462718183]: num_filters: 1
[ INFO] [1665378953.462772286]: Setting Dynamic reconfig parameters.
[ INFO] [1665378954.824638530]: Done Setting Dynamic reconfig parameters.
[ WARN] [1665378954.824839051]: Given stream configuration is not supported by the device!  Stream: Depth, Stream Index: 0, Width: 640, Height: 480, FPS: 30, Format: Z16
[ WARN] [1665378954.824860994]: Using default profile instead.
[ INFO] [1665378954.827225521]: depth stream is enabled - width: 320, height: 240, fps: 30, Format: Z16
[ INFO] [1665378954.827632064]: color stream is enabled - width: 640, height: 480, fps: 30, Format: RGB8
[ WARN] [1665378954.827654572]: Given stream configuration is not supported by the device!  Stream: Confidence, Stream Index: 0, Width: 640, Height: 480, FPS: 30, Format: None
[ WARN] [1665378958.828362891]: Hardware Notification:Receiver light saturation, stream stopped for 1 sec,1.66538e+12,Error,Hardware Error
A warning displayed as Receiver light saturation error, which is causing flicking of 3D image in RVIZ pointcloud. Any solutions would be appreciated.
@RealSenseSupport , @MartyG-RealSense

The camera is already out of warranty & has no scope of return.

As this error is related to a problem in the L515 camera's hardware, it is unfortunately not correctable with software.

Hi @TheNemo05  Bearing in mind the above comment, do you require further assistance with this case, please?  Thanks!

Case closed due to no further comments received.


License Exception

Steps to Reproduce
Add hive as package to pubsec and call showLicensePage()
The license of hive package throw a exception in showLicensePage
Version

Platform: iOS, Android, Mac, Windows, Linux, Web
Flutter version: 1.7.8+hotfix 4
Hive version: 0.4.1+1

I just tested it with the counter example and the showLicensePage() method works fine for me. What error are you seeing?

cf; https://github.com/flutter/flutter/issues/39723#issue-488438860

I just tested it with the counter example and the showLicensePage() method works fine for me. What error are you seeing?

Yes yes the page works but an exception is created in the console let me show you.
I send you a video that you can download here

I changed the license to the short version. I think it works now.


Exception on Non-Ascii locations

The latest version throws an UnicodeEncodeError on non-ascii location strings, e.g. "Köpenicker Str., Berlin, Germany" with umlauts.
what fixes it for me: pokecli.py line 28
import sys
reload(sys)
sys.setdefaultencoding('utf-8')

and deleting the import sys a litte below.

This should be fixed now on the dev branch.


[New chain]: Kroma Sepolia 1.4.1

Summary

https://github.com/safe-global/safe-deployments/pull/551
https://github.com/ethereum-lists/chains/blob/master/_data/chains/eip155-2358.json

Chain ID
2358
Chain detail URL
https://chainlist.org/chain/2358
RPC URL
https://api.sepolia.kroma.network
Blockscout Client URL
No response
Etherscan Client URL
No response
Etherscan Client API URL
No response
Version
1.4.1
Address (Master copy)
0x41675C099F32341bf84BFc5382aF534df5C7461a
Deployment Tx hash (Master copy)
0xda9099e8201dc7304fedb4c391c9a65cc2c107aa064034b1c5d215bff6263975
Block explorer URL (Master copy)
No response
Address (Master copy L2)
0x29fcB43b46531BcA003ddC8FCB67FFE91900C762
Deployment Tx hash (Master copy L2)
0xd94b9ac2bb721fa5b82cc9763e5e6a5d2ee385a12a4300e418001de3b0075fd7
Block explorer URL (Master copy L2)
No response
Address (Proxy factory)
0x4e1DCf7AD4e460CfD30791CCC4F9c8a4f820ec67
Deployment Tx hash (Proxy factory)
0x92b9a14aa377018d65590d9774e1ad279c15756923f4d87b608e9b95cac7c817
Block explorer URL (Proxy factory)
No response

/execute


Problems importing less without extensions when compiling assets (npm run dev)

See: https://github.com/less/less.js/issues/3115

Also see: https://github.com/JeffreyWay/laravel-mix/issues/1256

Ugly hack added to webpack.mix.js:
https://github.com/acacha/adminlte-laravel/blob/5.0.4/webpack.mix.js

Solved not depending more in Adminlte less files. Use 6.0 version


Call to ExecuteReader

What relevance does the call to command.ExecuteReader have in this example (detecting changes in SqlDependency).  Is it necessary to query the data after setting up a notification handler - if so, why?
Also, in the OnDependencyChange, it would be good to see an example of handling the change.  For example, how to use SqlNotificationEventArgs.

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

ID: 8bb20bc6-ec90-c5d1-8f40-5725f214122c
Version Independent ID: 1160cca8-659f-c6d8-fb60-f65187a5a472
Content: Detecting Changes with SqlDependency
Content Source: docs/framework/data/adonet/sql/detecting-changes-with-sqldependency.md
Product: dotnet-framework
GitHub Login: @douglaslMS
Microsoft Alias: douglasl

@stevestein please check this feedback regarding ADO.NET content

@AndyWDev - thanks for the feedback.
Yes, not a very good example here. The command in the example should've changed data to trigger the notification.
We've created an internal work item (1756238) to look into updating this example.
Thanks.


adding downloads badge from https://pepy.tech/project/hummingbird-ml

Codecov Report

Merging #313 into master will decrease coverage by 0.07%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #313      +/-   ##
==========================================
- Coverage   91.69%   91.62%   -0.08%
==========================================
  Files          53       53
  Lines        2963     2960       -3
  Branches      566      566
==========================================
- Hits         2717     2712       -5
- Misses        128      129       +1
- Partials      118      119       +1

Flag
Coverage Δ

#unittests
91.62% <ø> (-0.08%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

...rd/ml/operator_converters/sklearn/decomposition.py
81.81% <0.00%> (-6.07%)
:arrow_down:

hummingbird/ml/_container.py
90.54% <0.00%> (-0.09%)
:arrow_down:

...rd/ml/operator_converters/_tree_implementations.py
98.15% <0.00%> (-0.01%)
:arrow_down:

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 4a1ffa8...9511af7. Read the comment docs.


Rotation from portrait to landscape causes image issues

When I open the photo browser in portrait, and then rotate it to landscape, the image is lower than it should be. Maybe there is an offset that accounts for status bar or nav bar in the transition unnecessarily? If you move the image up a little, but not enough to dismiss the image, it fixes itself into the right spot until dismissed. Tap to zoom and pinch to zoom do not fix it.
When you open the photo browser from the landscape position, the image shows as it's supposed to.
Any suggestions? Thank you.

Also, I noticed that on smaller devices, when rotated to landscape, the caption jumps up to mid screen. Is there a way to change the caption position? I played around with the rect for the caption view but it didn't seem to work.


Deprecated Features & Fields for W1 version

As many parts of the world are using W1 version, can you add the references for deprecated features & fields for the W1 version of Business Central.

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

ID: 099e4c9c-6893-2d35-6ece-6c056a2c752f
Version Independent ID: 8a51d9d5-605d-d442-337b-ef992d25395d
Content: Fields that are Moved, Removed, or Replaced - Business Central
Content Source: dev-itpro/upgrade/deprecated-fields.md
Service: dynamics365-business-central
Product: dynamics-nav-2018
GitHub Login: @edupont04
Microsoft Alias: edupont

Hello, we are currently working on an article that will about deprecated features for W1. Hopefully this will be published soon. On an object level (tables, fields and methods), you can refer to Breaking Changes. This article is published on the ALAppExtensions repo in GitHub. Eventually this content will probably be moved into the documentation but for now, because it is frequently updated as we discover missing info, it will remain here. I hope this helps. Thanks for the feedback!


enh: modified _differentialevolution.py to enable parallel evaluation of the objective function for the whole population

Hi,
https://gist.github.com/pavelponomarev/20ea37324b219c7ed461/revisions
This file is modified to enable utilization of multiprocessing.Pool.map(func, iterable[, chunksize]) for parallel evaluation of the objective function.
Please review the code.  This is my first submission to github projects.
Is introduction of a new optional parameter "parall" appropriate? Maybe some other better strategy can be used to enable vectorization of the objective function calculation?
BR, Pavel

I can't speak for better, but the package emcee addresses this by taking a parameter "map"; it defaults to the standard python map function, but you can supply the one from multiprocessing or they provide a version of map that works with MPI. It keeps the implementation of the objective function separate from the parallelization issues. If you're going to keep the boolean argument, it would be preferable to call it "parallel" - less confusing, barely longer.

Thank you. I will change that flag to "parallel" and prepare a pull request. I am not sure if this flag is OK. But the possibility for parallelisation is really must have here.

Using the emcee API (just add a pool parameters) sounds useful to me, in particular in the sense that it is not tied to multiprocessing. There are also some other routines in Scipy that could in principle be parallelized to some degree in a similar way.

pv, is this API enables parallelization inside that package? How about to give to user the freedom of selection of parallelization method. E.g. joblib.Parallel instead of multiprocessing.Pool. I think the keyword "pool" might be confusing. The description of the keyword could look like

parallel : bool, optional
Changes the objective function f([x], *args) to accept vectorized
arguments, where [x] is the list of parameters of the whole population.
This means in practice that current generation can be evaluated
externally using parallel computing packages and functions like
multiprocessing.Pool.map or joblib.Parallel, e.g.:
Parallel(n_jobs=8)(delayed(func)(i) for i in [x])

Doing it like that requires modifications in the objective function, and slightly more hassle with setting up the parallelization as potentially persistent pools have to be passed also to the objective function.

Yes, and user takes care of the dispatch of separate jobs for the evaluation by the objective function. This helps if your objective function is very heavy and calculates during like several minutes, which naturally requires multiprocessing environment or even cluster. That's why there should be a freedom of selection how jobs are dispatched - within just one PC with multiprocessing.Pool functionality, or among several PCs using MPI. If your objective function is fast, just do not use this parallel option, but with very heavy fitness functions this slight hassle makes sense.

Yes, but note that selection of the parallelization method is also possible via the pool API, cf. how it is done in emcee.

Potentially interesting - I've been wondering how to parallelise differential evolution for a while.  Unfortunately, I don't think that this parallelisation method is going to be better than the existing serial version.  There are different parallelisation approaches that would be more worthwhile. I'll expand on that in a later comment, when I have more time.
However, the proof is in the benchmarking, I think we would need to use #4191 (which provides multiple global optimisation functions) to see if an improvement is possible with this parallelisation approach.  One would want to know a) if a lower energy is obtained and b) if a lower number of nfev is required to obtain that energy.

Regarding API for parallelization, note that in cKDTree we just shipped a n_jobs keyword. Maybe should have gotten a bit more discussion. Would be really good to pick one way to do it. n_jobs is nice, because it's used in scikit-learn and statsmodels already.

I do not like implementation of parallelization inside the module. This adds a dependancy and somewhat limits the user in selection of parallelization technique. E.g. if threading is utilizied, this practically limits the parallelization to number of cores within one PC. I want to have possibility for my own implementation of parallelization using MPI, which enables parallelization on cluster with thousands cores.
n_jobs is a good keyword but the number of possible parallel jobs in the DE is determined by the population length which naturally is determined from other keywords of DE.
The proposed fix to _differentialevolution.py changes only the way how the objective function is evaluated for the population from calculation for each separate member population to the whole population simultaneously. That does not add any dependencies, and leaves the freedom for implementation of parallelization on the user. Nothing complicated is added and this already works. I have got linear speed-up of computations. My objective function is very heavy, single run performs a FEM computation during 4 minutes. The proposed fix already works for me. I do not need any complication with implementation of parallelization within _differentialevolution.py. I want to keep things simple and leave implementation of the algorithm to scipy.optimize and implementation of parallelization to joblib or my own MPI.

Here is the simplest code snippet which shows the advantage
from scipy.optimize import rosen, differential_evolution
from joblib import Parallel, delayed, cpu_count
import time

bounds = [(0,2), (0, 2), (0, 2), (0, 2), (0, 2)]

def objfunc(params):
    for it in xrange(1000000):
        it**2
    return rosen(params)

def pareval(listcoords):
    listresults = Parallel(n_jobs=cpu_count())(delayed(objfunc)(i) for i in listcoords)
    return listresults

def parallel_run():
    result = differential_evolution(pareval, bounds, parallel=True, maxiter=10, polish=False)
    print result.x, result.fun

def serial_run():
    result = differential_evolution(objfunc, bounds, maxiter=10, polish=False)
    print result.x, result.fun

start_time = time.time()
serial_run()
print("Serial run took %s seconds using 1 core " % (time.time() - start_time))

start_time = time.time()
parallel_run()
print "Parallel run took %s seconds using %s cores" % ((time.time() - start_time), cpu_count())

and result is:
[ 0.54651845  0.35382038  0.1226159   0.03008397  0.03142196] 2.75419151958
Serial run took 42.4755949974 seconds using 1 core
[ 0.87704828  0.87434803  0.83732696  0.68769892  0.49790808] 1.87122034154
Parallel run took 12.6878271103 seconds using 4 cores

Should I continue to prepare the pull request?

Additionally, I think, the usage of polish in the _differentialevaluation.py must be deprecated. The polish functionality simply repeats the functionality of other scipy.optimize module. The library functions must be universal and not specialised. The polish can be applied to the result externally using optimize.minimize with the same cost, but _differentialevolution.py will have one less dependency and cleaner code.

Consider an optimisation where there are M population members and there will be up to N generations (N < maxiter) evolving the population. Each population member represents a solution vector.
Before the optimisation takes place the initial energy of each member of the population is calculated.  Currently these energies are calculated by serial iteration through each member of the population. Once all the energies are calculated the lowest energy solution is placed in position 0 of the population.  population[0] always represents the best solution so far.  There is scope for this initialisation calculation to be done in a parallel manner because there is no evolution of the population at this stage. However, bear in mind that this initialisation is only typically <1% of total calculation.
The population is then evolved.  In the traditional implementation of Differential Evolution (which we have in scipy.optimize) each population member is visited in a serial manner.  A trial vector is created which randomly takes values from the population member under examination, or from a 'blended' vector (this choice is controlled by the recombination constant, there is at least one entry from the blended vector in the trial vector).  The 'blended' vector is synthesized from the population[0] plus a scaled difference of two randomly chosen population vectors (the scaling is controlled by the mutation constant).  The energy of the trial vector is calculated by the objective function.  If the energy of the trial vector is better than the energy of the existing population member the trial vector replaces the population member.  If the energy is also less than the best solution so far the trial vector replaces population[0] as well.
It is this last sentence that is the vital consideration here. In a given generation it is possible for each of the M trial vectors to change the best solution, population[0]``.  In addition, it is possible for each of the Mpopulation members to be improved. Thus, within a given generation the best solution will probably change several times; there will also be several population members that will lower their energies as well. Remember that the blended vector outlined above is synthesized using values from the best solution and other randomly chosen population members.  Thus, even within a single generation one is able to take advantage of improvements in both the best solution and other population improvements that have only occurred within that generation. In other words trial vectors show continuous improvement within a generation (e.g.trial[90]could be synthesised frompopulation[0]andpopulation[30]andpopulation[57]`, all of which could have changed for the better).
Any changes to the algorithm that reduces the update frequency of the best solution vector, or does not allow other trial vectors to benefit from improvements to other population members (within a given generation), will drastically reduce the ability and efficiency of the entire DE process in finding a global minimum.
Unfortunately the current parallelisation proposal does just that.  For a given generation there are M trial vectors created. The energies of these trial vectors are calculated simultaneously.  Once these have been calculated the trial members can replace the corresponding original population members if the trial energy is lower. population[0] is then replaced by the population member with the lowest energy.
This reduces the strength of the algorithm in two ways.  Firstly, the best solution vector can only change once per generation.  Secondly, all the trial vectors are created and calculated independently.  Both of these remove continuous improvement of trial vectors within a generation.  For a given problem I would hypothesize this proposal would converge around N times more slowly.
A different way of using parallelisation has been proposed in the past.  Rather than evaluate a single population in parallel, why not generate several populations, P?  One would iterate serially through each of those P populations, like is done at the moment.  At the end of a generation (a synchronisation point) you compare population[0] for each of the P populations. The overall best solution is then copied to the other populations.

With regards to polishing the final result, this is frequently done by users of this code; so frequently, that it's worth taking on the work of polishing it within differential_evolution.  Doing it internally reduces the chances of a user making a mistake.  Because DE mandates the use of limits L-BFGS-B is the only algorithm that can be used here.
I would argue that the polishing step in differential_evolution is simple, is universal, and does not make it over featured. I would rather external codebases didn't have to worry about the extra polishing step themselves, the probability of them making a bug is larger.
Besides deprecating / removing a keyword should happen only in rare circumstances.

I think we can find a more suitable test than rosen, something which has a lot more features  e.g. Griewank or BiggsExp04 (#4191).  The best test approach would be to go through the global benchmark suite 100 times for each approach and examine the total number of function evaluations, and the success rate.
Please note that the rosen function has a global minimum of 0.0, and a best solution of [1, 1, 1...].  In the test you ran above neither the serial or parallel versions reached a satisfactory minimum.  More iterations are required for this.  All that happened is that the parallel version finished in a smaller amount of time than the serial version, which is to be expected.  The key question is which approach converges in a smaller amount of function iterations, and also reaches a global minimum?

@andyfaff the kind of parallelization you're talking about exists in the form of pygmo: http://esa.github.io/pygmo/ It runs multiple optimizers in separate "islands" and has a "migration operator" to exchange promising solutions between islands. Makes it very flexible and parallelizable, but also maybe a little heavyweight for scipy.

@andyfaff with regards to "polish" keyword I still disagree. The function is called differential_evolution and not a differential_evolution_with_polishing. I would not expect from this function to do something else from DE. OK, if there is statistics that this polishing really goes in majority of real world cases, then let leave it. But, at least the default behavior should be changed to polish = False.  Additionally, this polisher, I hypothesize, works OK only with differentiable functions. But there are a lot of real engineering problems (my among them), where objective functions are not only nonlinear, but also are discontinuous and non-differentiable and somewhat noizy. I still prefer modularity, and I belive, that all library functions should be modular and perform good just one task.
So, this additional feature could be removed with mentioning in documentation, or in the examples, that L-BFGS-B polishing is usually best suited and gives good results for differentiable smooth objective functions. Or, at least, the default behaviour should be changed to polish = False.

Regarding the 'polish' interface, differential_evolution appears to use polishing in a somewhat sophisticated way, so
differential_evolution(func, ...)`

is not the same as
def func2(x):
    return minimize(func, x, ...).fun
differential_evolution(func2, polish=False, ...)

see https://github.com/scipy/scipy/blob/maintenance/0.16.x/scipy/optimize/_differentialevolution.py#L542

Now that I've read the polishing code more closely I see that it is applied only to the best population member at the very end of the optimization.  It's not a local optimization step taken at each function evaluation, and it's not applied at the end of each generation.  I kind of agree with @pavelponomarev that  including it in differential_evolution is unnecessarily monolithic especially when it is True by default.

With regards to parallelization... The realized DE strategy in optimize._differentialevolution is called "aggressive" (at least in lecture slides of prof. Alotto http://www.dii.unipd.it/~alotto/didattica/corsi/Elettrotecnica computazionale/DE.pdf). This is one of the advanced strategies and definitely superior to pure DE. The pure DE does not mix generations during the mutation process. Hence, the parallel evaluation of the objective function (or computation of energies) can be applied to the whole generation simultaneously.
I like mentioned here approach by @andyfaff about braking the population to several smaller populations which allows to achieve quasi-aggressive performance. Here, the proposed by @rgommers keyword n_jobs can be nicely used.
I propose to have default behavior of DE to be aggressive serial and without polishing. But the non-aggressive pure DE also should be implemented with possibility for parallel evaluation of the objective function for the whole population. And leave thoughts about best implementation of quasi-aggressive strategy for parallel DE for future commits.

Can we split this discussion/issue into two parts?  The first part
regarding the polishing.  The second part regarding the 'aggressive'
(parallel) strategy.  They are separate/orthogonal to each other.
@pavelponomarev https://github.com/pavelponomarev can you start a
separate thread for the polishing?
On 16 May 2015 at 01:35, Pavel Ponomarev<EMAIL_ADDRESS>wrote:

With regards to parallelization... The realized DE strategy in
optimize._differentialevolution is called "aggressive" (at least in
lecture slides of prof. Alotto
http://www.dii.unipd.it/~alotto/didattica/corsi/Elettrotecnica computazionale/DE.pdf
http://www.dii.unipd.it/~alotto/didattica/corsi/Elettrotecnica computazionale/DE.pdf).
This is one of the advanced strategies and definitely superior to pure DE.
The pure DE does not mix generations during the mutation process. Hence,
the parallel evaluation of the objective function (or computation of
energies) can be applied to the whole generation simultaneously.
I like mentioned here approach by @andyfaff https://github.com/andyfaff
about braking the population to several smaller populations which allows to
achieve quasi-aggressive performance. Here, the proposed by @rgommers
https://github.com/rgommers keyword n_jobs can be nicely used.
I propose to have default behavior of DE to be aggressive serial and
without polishing. But the non-aggressive pure DE also should be
implemented with possibility for parallel evaluation of the objective
function for the whole population. And leave thoughts about best
implementation of quasi-aggressive strategy for parallel DE for future
commits.
—
Reply to this email directly or view it on GitHub
https://github.com/scipy/scipy/issues/4864#issuecomment-102434153.

--

Dr. Andrew Nelson

Agree). Here it is #4880 .

I read the lecture slide link that was mentioned.  The tl;dr message is
that the 'aggressive' approach visits each member of the population
serially, if the trial vector is successful it is updated immediately.
Subsequent trial vectors are able to benefit from earlier improvements made
to the population within the same generation (best solution is updated
several times per generation).
In contrast the 'non-aggressive' approach generates trial vectors for the
entire population in parallel (all trial vectors are independent of each
other). Once all energies have been calculated the population is updated
(best solution is updated once per generation).
Currently differential_evolution uses the aggressive approach.
@pavelponomarev is proposing to add the non-aggressive approach.  A more
appropriate keyword to use if this is to be added would be
aggressive=True.
In the non-aggressive approach the trial vectors are all independent of
each other.  This makes it possible to calculate the objective function for
them all in a parallel manner. Parallelisability is coincidental here, use
of a parallel keyword obscures the fact that the minimisation algorithm
has changed.  The non-aggressive approach could also use a non-parallel
calculation of the objective function.
Lets suppose an aggressive keyword is added. If  aggressive is False
then use the non-aggressive approach.  The default (True) would be to
follow the existing approach.  The use of terms such as
aggressive/non-aggressive should not be overly interpreted as good/bad,
they're just different.
The key thing is to discuss what should happen in situations where
parallelisation of objective functions could occur (@dlax). The behaviour
for all existing scipy.optimize objective functions is receive an x
parameter array (x.shape = (Y, )), returning a single energy value.   We
could specify that if aggressive is False then the objective function
should expect to receive an (M, Y) shaped array and should return (M, )
energies.  However, this wouldn't be consistent with the aggressive is True case, nor would it be consistent with the rest of scipy.optimize.
Besides someone might want to use the non-aggressive approach with a normal
objective function.
There are several places in scipy.optimize where parallelisation is
possible; the non-aggressive approach in this proposal and optimize.brute
immediately spring to mind. In optimize.brute the calculation is
vectorized, but not parallelized, using np.vectorize. The non-aggressive
proposal is not too dissimilar, perhaps this approach can be used to start
with.
However, I think scipy.optimize needs a common approach to enabling
parallelisation of objective functions, or indeed other code blocks,we
don't want to have case-by-case approaches. Could we create a
scipy.optimize.parallelized decorator that would indicate that
paralleisation of an objective function was possible?  If it is decorated
supply the objective function with (M, Y), otherwise supply with (Y, ).

If there is going to be a general option to allow parallelization of optimization algorithms (which could include some of the local ones - gradient evaluation can be parallelized, for example) we should think about how to do that efficiently. Creating a new objective function may not be the best way to do it.
First: do we need more generality? This is sort of a SIMD model: the optimizer comes up with a list of values, sends them off to be evaluated, and waits for them all to finish. For some of the genetic algorithms, or the brute-force optimization, you could perhaps resume the computation before all the values had returned.
Second, if the generality is appropriate, is this the best way to get parallelization? As I pointed out earlier, emcee solves the same problem - allowing multiple simultaneous objective evaluations - by allowing the user to provide a suitable implementation of map, perhaps the one from multiprocessing or perhaps the MPI-based one they provide. This particular implementation doesn't allow one to take advantage of numpy-style vectorization, if that's a concern, but it doesn't require modifying the objective function to change the parallelism. On the other hand, if vectorized functions are the way to go, a version of np.vectorize that used parallelization under the hood would make it easy to parallelize with this implementation. But there might be other ways of letting the user flexibly add parallelism to algorithms that permit it.

I like that emcee way. There should be a choice for the user to take care of the parallelization by themselves, or use default built-in parallelization (e.g. threading). I think it is not necessary to make a decorator for objective functions.

emcee doesn't just use a pool, its sampler signature is ..., thread=1, pool=None, ... - so two keywords. With the default being user-friendly and very similar to scikit-learn, not requiring creation of a custom pool. So my conclusion is that n_jobs=1 is a sane and well-tested choice, and adding an option for a custom pool may be useful to power users but is of secondary importance.
Maybe there's a way to avoid a second keyword, either by overloading n_jobs (ugly) or using some kind of decorator that adds the option to set a property to choose a pool or threading backend.

Also good to realize that both emcee and joblib provide custom Pool implementations because the multiprocessing one is not good enough for production-quality code:
https://github.com/dfm/emcee/blob/master/emcee/interruptible_pool.py
https://github.com/joblib/joblib/blob/master/joblib/parallel.py

By the way, are we discussing an API for parallelization for optimization functions or for all of Scipy? The latter would be preferable I think. At some point we should move this to the mailing list - within the next week would be good, so we can still rename the cKDTree argument that was added for 0.16.0 if needed.

I think it should be parallelization for all of scipy.
To recap: the desired change for this issue should really be considered in
two parts.

the addition of an aggressive keyword (or something more suitable).
aggressive is True runs the code as is (default), whilst aggressive is False modifies the algorithm of how the population is updated. aggressive is False normally shows lower performance.
However, it happens that aggressive=False allows one to calculate the
objective function in parallel.  So even if performance (in terms of a
larger number of nfev) suffers, you can recoup that loss by calculating in
parallel.

The question is how to enable that parallelisation, and what extra keywords
are required for that. It would be better it there was a default scipy way
of doing this, which would account for different parallelisation topologies
(multicore single processor, cluster, etc).  Hopefully all this can be
achieved without changing the call signature for the objective function.

Additionally, a keyword of n_jobs can be used to trigger quasi-aggressive strategy for parallel computations. In case when n_jobs is smaller than the population length, the population is divided in len(pop)/n_jobs subpopulations and each subpopulation is executed in parallel. After the subpopulation is executed, the best member is updated in DE and next subpopulation is executed then. However, this is just a secondary objective of this discussion and can be improved in future. The main objectives are well enumerated by @andyfaff in previous post.

Please check out this https://github.com/pavelponomarev/scipy/pull/1.
I am successfully using this piece of code for computationally expensive objective functions.
Please check out this numbered list of changes and tell your thoughts
Changes:

Added flag vectorize (default False) to enable parallelization externally. Name vectorize was changed from parallel in #4864 to highlight that parallelization is not performed inside the module itself but rather within the user-created function similar to numpy.vectorize.
Added flag aggressive (default True) to enable aggressive mutation strategy as discussed in #4853
Added optional variable njobs which defines the size of subpopulations for quasi-aggressive (#4864) mutation in parallel case.
callback is modified to expose the whole population, not just the best individual. This is required to set up custom stopping criteria which can be useful in real-life engineering problems with computationally-expensive objective functions. This way the search process can be stopped with an arbitrary criterion and computation time would not be wasted. See e.g.  https://scholar.google.com/scholar?cluster=15734086883203880529
5.Option maxfun and warning check for 'maxfev' are removed as not necessary. The author of original code was also skeptical about usefulness of this at lines 286, 287. Additionally it can not be used in parallel.
Documentation strings in DifferentialEvolutionSolver class were removed as those are identical to the module documentation. I do not see a reason why the same documentation should be maintained in two different places.
The documentation and examples are updated according to the introduced changes.

Additionally I would like to rename popsize to popmul as the current name is somewhat misleading.
And maybe disp to verbose for the same reasons. But these are just minors.
I think that you should not be very reluctant of accepting big changes in this module as it is quite young (only one year old) and the number of real users of this module I anticipate as not a big number. Additionally the proposed changes would significantly increase the practical applicability of this module for future users.

As there is a quite big amount of changes proposed, maybe it is reasonable to create a new function within scipy.optimize with a name something like 'vectDE' as an alternative option?

I finally visited the emcee code mentioned by @aarchiba and @pv and I like the way it is done there. Usage of the keyword 'pool' is much more convenient and concise and they provide also a pool compatible with MPI. I should have done it in May.
The emcee is licensed under MIT. Is it compatible with the scipy? Can we directly borrow pieces of code from there?

The emcee is licensed under MIT. Is it compatible with the scipy? Can we directly borrow pieces of code from there?

Yes scipy is MIT-licensed, and source files from legitimately MIT-licensed projects can be included into scipy. It looks like emcee used to be GPL but they switched at some point.

Hello,
Here is the working files for emcee-style parallelization https://github.com/scipy/scipy/compare/master...pavelponomarev:DE_with_parallel_pools?expand=1
Please check and comment.
There two pools are added -- MPI and joblib. Both are working good. The MPIpool was copied from emcee and augmented with a function MPIpool.poolsize() to automatically enable quasi-aggressive mutation in DE.
The changes in DE are as follows:

Added optional variable pool (default False) to enable parallelization using provided pools. This enables parallelization without altering the objective function.
Added flag aggressive (default True) to enable aggressive mutation strategy as discussed in #4853
Added optional variable njobs which defines the size of subpopulations for quasi-aggressive (#4864) mutation in parallel case.
callback is modified to expose the whole population, not just the best individual. This is required to set up custom stopping criteria which can be useful in real-life engineering problems with computationally-expensive objective functions. This way the search process can be stopped with an arbitrary criterion and computation time would not be wasted. See e.g.  https://scholar.google.com/scholar?cluster=15734086883203880529 . Additionally it is used to monitor the convergence of parameters.
Option maxfun and warning check for maxfev are removed as not necessary. The author of original code was also skeptical about usefulness of this at lines 286, 287. Additionally it can not be used in parallel.
Documentation strings in DifferentialEvolutionSolver class were removed as those are identical to the module documentation. I do not see a reason why the same documentation should be maintained in two different places.
The documentation and examples are updated according to the introduced changes.

The spelling in joblib (and cKDTree) is n_jobs with an ubderscore.

Do we want a dependency on MPI and joblib? Presumably we can do without any of those here.

@sturlamolden njobs was deliberately ditinguished from the number of workers as this determines the sub-population size for aggressive mutation. This njobs can be bigger than the number of parallel workers. Perhaps, a name like subpopsize could be better.

I'd really like to look over this code in detail but I'm on holiday until
mid July. A few things are worth mentioning:

Backwards compatibility is very important. I don't think we can change
the callback function at this point. Please also see point 3.
People use docstrings to work out how to use code. I really think the
solver object should retain its docstring.
The interfaces to the scipy.optimize minimizer functions were all made
very similar, using the same input keywords and same output keywords. I'd
be hesitant about removing maxfun and maxiter. The same argument applies to
changing the signature of the callback function.
Is there a need to include joblib or mpilib? Could we just say that the
pool keyword should be a pool object that has a map method? This way you
can use whatever pool you like. A default internal pool could be from
multiprocessing. This way there are no added dependencies that need to be
updated.

@andyfaff I am going to vacation as well until the end of July, so perhaps no harry here)

I would disagree - for all population based algorithms (unlike single valued optimizations) the information on population members is really essential. It shows the convergence. The callback function is the best way to provide this information. Alternatively we should design another way of how to expose the information on all individuals outside the DE module.
The interface as I see it is differential_evolution function, and not DifferentialEvolutionSolver. People would look for the first option in docstring (I actually never used docstring, so maybe I am wrong here). It is REALLY wrong to keep the same info in two different places. I would like to keep the docs for the module, and for those who uses docstrings leave a link in the Solver class.
The maxfun is really useless when parallelization is implemented. Moreover, I do not see any application for maxfun. If there is any need for this, then it is fairly easy to count the executions of the objective function within the objective function itself.
Regarding the callback, I think that DE in scipy is the first population-based method. There were no other population based methods before. In situations when something fundamentally new comes up it is natural to change the standard interfaces. I understand that there previously were no usage at all of population based algorithms in scipy, so maybe we should design a standart interface for population based algorithms here. And in this new design a possibility for inclusion of new parameters (which might be needed in future) should be implemented.
In emcee that pool is provided for convenience. I want the same convenience here as well. The dependencies are actually optional. Providing own pools helps to deal with default parameters of the pools in a good way. I agree, that an own multiprocessing pool could be a good option. But, considering easiness and end-user usability, I want to use joblib as it provides great debugging possibilities and responds well for CTRL-C. With multiprocessing provided pool is a total headache during debugging. And a custom MPI pool is also necessary for HPC applications.

@pavelponomarev I was just commenting on the spelling (n_jobs vs. njobs).
Whether we should use joblib in SciPy is a bigger discussion, but now would be a good time to take it.
MPI is a totally another matter, there are many implementations of the MPI runtime and there are several Python bindings – including a modified Python interpreters. I think it is better avoided for now. MPI is great, but we need to make some choises on how to support MPI in SciPy.

My biggest complaint against joblib in its current form is the memory mapping of temporary files for sharing  NumPy arrays between processes. This means it uses shared memory on Linux (due to tmpfs), but physical files on Mac and Windows.
But standardizing on joblib is in my opinion better than having a number of ad hoc solutions for parallelization. I am slightly in favor of using joblib in SciPy, but only if it is chosen as the standard way of parallel computing in SciPy.

@pavelponomarev, it'd probably help if you could split your changes into several atomic commits. A "636 additions, 189 deletions" diffstat does not ease review.

@dlax , here it is:
https://github.com/scipy/scipy/compare/master...pavelponomarev:parallel_DE?expand=1
Here only the core parallel functionality is update in comparison with existent serial function.

The current code of only a pool= kw isn't very good imho. Several people who prefer it refer to emcee, but as I pointed out in https://github.com/scipy/scipy/issues/4864#issuecomment-103332346 it does not use pool in isolation.
Whether or not we add pool for power users (I don't care too much about that), we need something that takes an integer. Could be called n_jobs or threads or workers, that doesn't really matter I think.

@rgommers , I agree.
The pools are required for power users to use MPI pool or Joblib pool. Additional integer keyword should be added for normal parallel use with standart multiprocessing module. Let us try to push first this functionality for power users (e.g. as it is done in #5141). And then, in a separate PR this parameter could be introduced.

@pavelponomarev we shouldn't merge anything until it's clear what we want to do. Some options:

Add a workers=1 keyword that takes integers as well as any kind of object with a map method. Addresses both use-cases.
Add n_jobs=1 (joblib-style/based) and pool=None. If pool is supplied by user, n_jobs is ignored.
Add only n_jobs=1. This covers most of the use-cases and is consistent with scikit-learn, statsmodels, etc.

I think I prefer (1), followed by (2) and then (3). Two keywords really is one too many for an API that could be used throughout Scipy.

I also like (1)!
Then I, or someone else, should add a commit with replacement of pool keyword to #5141 after all required tests are fixed there. I will return to this after a few days, when we gather more comments.

We used (3) in cKDTree in SciPy 0.16. But I don't really care what it's called :-)

https://github.com/pavelponomarev/scipy/commit/a6ce5be8a390337bd0b03d40e8a98d8cf38afe9e

Just Wondering if this paralell version will be included in the next version of scipy ?
Thanks

This  PR is currently stalled and won't be in SciPy 0.18.

So I don't see it listed for 0.19 either. Is this likely to be ready for the next release? I'm sure ya'll are swamped; this would just be really very useful for my research.

I couldn't agree more with @rocapp. A parallel version of DE would be truly welcomed!

Just joining the chorus of @rocapp and @ktamiola in support of a parallel version of DE.

@rgommers : would it make sense to also provide the same parallelization option for 'scipy.optimize.brute' as well. Since scipy.optimize.brute is guaranteed to work for any kind of optimization problem (agreed that it is inefficient), it would be really helpful to have the same switch for this method as well.


why Video picture can't change?

hello! I have install WebFlight successfully .Point your browser to http://localhost:3000/ , and I Can control my AR.Drone 2.0. But the picture is static, doesn't change with the situation.

Do you see any error message in the browser javascript console ? Or in the terminal ?

thanks for your reply in time.
1.this console in the chrome browser and in the terminal

2. this is my config file content.

3.this is my video image, it's static, even if i switch my camera of AR-Drone.

Can you tell me the reason?


The precision of multi-tab website fingerprinting attacks increases.

I'm trying to reproduce the DF results for multi-tab website fingerprinting from the ARES paper, but I'm not getting the same performance as reported. Interestingly, I'm seeing an upward trend in precision.
Here are my results:
In the 2-tab setting: {'Precision': 0.7876, 'Recall': 0.5594, 'F1-score': 0.6487}
In the 5-tab setting: {'Precision': 0.8124, 'Recall': 0.1561, 'F1-score': 0.2507}
the experimental parameters I used:
python -u exp/train.py
--dataset ${dataset}
--model DF
--loss BCEWithLogitsLoss
--num_tabs 2 (or 5)
--device cuda:2
--feature DIR
--seq_len 5000
--train_epochs 300
--batch_size 128
--learning_rate 2e-3
--optimizer Adamax
--eval_metrics Precision Recall F1-score
--save_metric F1-score
--save_name max_f1
my setup details:
Python 3.8.19 , torch 2.4.1
Is there anything that needs to be adjusted? Thank you very much.

Thank you for your question. Recall and precision exhibit a trade-off relationship, where a decrease in recall often leads to an increase in precision. This occurs because recalling fewer samples reduces the denominator in the precision calculation. We recommend using more common multi-label metrics, such as P@k and AP@k.
The primary differences from the ARES paper can be attributed to three factors:
Improved Dataset Quality: We recently developed an image classification model that effectively filters out failed webpage loads by identifying page screenshots, significantly enhancing dataset quality.
Different Metric Calculations: The ARES paper evaluates precision using a single-label metric, retaining only one label.
ARES Paper Did Not Use WFlib: WFlib was developed after the ARES paper’s publication. There are minor differences between WFlib and the original DF implementation, such as using PyTorch and the save_metric parameter. In our study, DF performance with WFlib is similar to that in the original paper, though not identical.


Refactors tablet mgmt iterator to share decision code w/ TGW

The TabletGroupWatcher uses the TabletManagementIterator to filter tablets that need attention.  The TabletMgmtIter had its own custom code to make decision about tablets.  This commit modifies the TabletMgmtIterator to use the same code as the TGW when making decisions about tablets.  This makes it easier to reason about and change the behavior of the TGW.
In making the TGW and TabletMgmtIter share code a change was also made to how they get information to make decisions.  A new class called TabletManagementParameters was introduced that contains an immutable snapshot of the information that both classes need to make decisions. With this change the iterator and TGW are using the same information for a pass over the metadata table, in the past the information was obtained at different times and could have been different due to race conditions. These race conditions were probably not harmful, but removing them makes the code easier to reason about.
Also move some code outside of TGW away from using the TableMgmtIterator. Need to move all code outside of TGW away from using this iterator in order to make the code easier to maintain.  Left TODOs in the code about this and will open follow on issues.

Please also check that ManagerAssignmentIT is still passing.

@dlmarion that was a good call on running that test. Ran and it blew up.  Turned out the best way to fix was to move a lot of code from using the tablet mgmt scanner to using ample.  Made that change in e1da6f0.  After that change the only thing left using the tabletmgmt iterator is TGW which is good.


Revert "Revert "Revert "added new pr"""

Reverts omkarkhatavkar/github-action-test-repo#60

trigger: test-robottelo


Generator: Update SDK /services/sqlserverflex

Generated from GitHub run<PHONE_NUMBER>5

a newer pr will be available. This one has unwanted breaking changes


vimPlugins.neorg: add test

Description of changes

luaPackages.neorg: remove forgotten debug
vimPlugins.neorg: add test

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

nixpkgs-review result
Generated using nixpkgs-review.
Command: nixpkgs-review pr 345188

x86_64-linux

:fast_forward: 1 package marked as broken and skipped:

lua54Packages.neorg

:white_check_mark: 6 packages built:

lua51Packages.neorg
lua52Packages.neorg
lua53Packages.neorg
luajitPackages.neorg
vimPlugins.neorg
vimPluginsUpdater

aarch64-linux

:fast_forward: 1 package marked as broken and skipped:

lua54Packages.neorg

:white_check_mark: 6 packages built:

lua51Packages.neorg
lua52Packages.neorg
lua53Packages.neorg
luajitPackages.neorg
vimPlugins.neorg
vimPluginsUpdater


Access current style from tsx file

tl;dr: Is there a way of accessing the current style selected from a component/*.tsx file?

I have been trying to implement the possibility of leaving comments (cf. https://github.com/jackyzha0/quartz/issues/1130 ) and was rather successful, but I am having a small problem: I can add an event listener to change the theme of comment box, and it works just fine … but I have to pick a "default style". In my tsx file, I have to pick a style:
https://github.com/csci-1301/csci-1301.github.io/blob/4fb4f96ef4ef31425329c380d799de61db9e3480/quartz/components/Comments.tsx#L13
The problem is that if the page is loaded with the dark style (because it was previously picked), then the comment box will still be loaded with the light style: only toggling the style will make the box's style being consistent with quartz's style.
I can't  access document, so tricks like
const theme = document.documentElement.getAttribute('saved-theme') === 'dark' ? 'github-dark' : 'github-light'

won't work.
(adding a link to https://github.com/utterance/utterances/issues/549#issuecomment-907606127 because that was useful to get started :-))

Ok, I found a way using essentially the following in darkmode.inline.ts:
window.addEventListener('load', () => {
  const theme = document.documentElement.getAttribute('saved-theme') === 'dark' ? 'github-dark' : 'github-light'
  // Code here
})


Include "Not in Squad" appearances

Requested in Kaggle.

And also, I understand why they are not there but wondered if the appearances sheet (or somewhere alternative) could show when a player has not been included in a squad? This data appears to be available too.
Link attached for a player that has FA Cup matches and examples of not being included in a squad.

As far as I can tell, "Not in Squad" appearances can be inferred from appearances and games (i.e, there was a game an the player did not have an appearance for it).


Fixed XML proto parsing for removed debug data

Sometimes external tools remove all the debug data. In this case, attribute names, namespaces, and values are blank leading to XML parsing errors.

@bagipro thanks :+1:


mvn package issue

When I put "mvn package" in home directory of project, I face following error, Can you please help me
"[INFO] Scanning for projects...
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Build Order:
[INFO]
[INFO] keycloak-phone-provider                                            [pom]
[INFO] keycloak-phone-provider                                            [jar]
[INFO] keycloak-phone-provider.resources                                  [jar]
[INFO] keycloak-sms-provider-twilio                                       [jar]
[INFO]
[INFO] ------------< cc.coopersoft:keycloak-phone-provider-parent >------------
[INFO] Building keycloak-phone-provider 2.3.4-snapshot                    [1/4]
[INFO] --------------------------------[ pom ]---------------------------------
[WARNING] The POM for org.apache.maven.plugins:maven-resources-plugin:jar:2.10.0 is missing, no dependency information available
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary for keycloak-phone-provider 2.3.4-snapshot:
[INFO]
[INFO] keycloak-phone-provider ............................ FAILURE [  0.013 s]
[INFO] keycloak-phone-provider ............................ SKIPPED
[INFO] keycloak-phone-provider.resources .................. SKIPPED
[INFO] keycloak-sms-provider-twilio ....................... SKIPPED
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  0.097 s
[INFO] Finished at: 2023-06-27T16:05:54+05:30
[INFO] ------------------------------------------------------------------------
[ERROR] Plugin org.apache.maven.plugins:maven-resources-plugin:2.10.0 or one of its dependencies could not be resolved: Failure to find org.apache.maven.plugins:maven-resources-plugin:jar:2.10.0 in https://repo.maven.apache.org/maven2 was cached in the local repository, resolution will not be reattempted until the update interval of central has elapsed or updates are forced -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/PluginResolutionException
"

check your maven version .  In my is Apache Maven 3.8.6

What is your java version.My java version is 11.0.19. and maven version is 3.6.3

It's work for me after putting following changes mentioned below in attached images

keycloak 21.X.X  need java 17 +

keycloak 21.X.X need java 17 +

Yes, understood. But I've faced another Issue in DefaultPhoneVerificationCodeProvider file. So, I comment below code. Please find it in attachment.

keycloak 21.X.X need java 17 +

Yes, understood. But I've faced another Issue in DefaultPhoneVerificationCodeProvider file. So, I comment below code. Please find it in attachment.


fix Vector{Float64} vs Sundials.Nvector in initialize_dae

this was broken before, but more obviously broken after https://github.com/SciML/Sundials.jl/pull/401

closing in favor of https://github.com/SciML/Sundials.jl/pull/404


feat: update poem to v3 & poem-openapi to v5

Description:
Current implementation doesn't work with new poem v3 & poem-openapi v5 so I've bumped the versions and made the minor fixes for that migration.
Checklist:

[X] Tests for the changes have been added (for bug fixes / features);

no tests needed to be updated, all passing locally

[X] Docs have been added / updated (for bug fixes / features).

I just noticed the failing tests, not sure why it's working for me but ill fix it.


How can upgrade theme version ?

Hi, I've last 4.7.1 version, which files I must edit for it ?

Hi, I have not tried upgrading theme version. Did you do on your own?


GuessExecutor should read more than one buffer

GuessExecutor.GuessParserPlugin.run reads sample data and using it
repeatedly. When it reads data from a decoder plugin, it needs to more
than one buffer because decoder plugin splits a buffer passed by
SamplingParserPlugin into multiple buffers.
Fixes #339.

:+1:


Document kerberos infrastructure options

Active Directory
Locally administered KDC
FreeIPA

Information on FreeIPA is available on quattor.org

@ned21 @jrha can this be closed? I found the docs around FreeIPA but not other...

Superseded by #28


comments uses // instead of #

Hi,
Thanks for the cython syntax support !
Just a quick feedback : It should be useful to get a python-like comments when toogle code comments (block & line) instead of a C/C++ like (//, /**)

Hi, I can not reproduce your problem, the plugin works as expected(comment with '#').
Can you provide more details(eg: OS version, vscode version and plugin version, and/or screenshot)?

Hi,
I'm using the last stable versions of VSCode (1.33.1) and Language-Cython (0.0.5).
The issue is when using the Edit>Toggle Line Comment or Toggle Block Comment (or shortcuts) with the Cython syntax activated it comment using // instead of #.
However the color syntax is correct, it detects # as comments and // as regular characters...

I use the same version with you, but still can't reproduce. What's your OS version? Do you install other plugins about cython?

Sorry, I'm under Windows 10 Pro, I don't have any other cython plugins :(

On Linux (Ubuntu 19.10), I fixed this problem by reloading the window:
Ctrl+Shift+P:Reload Window

@stowejt this worked for me.
Using Ubuntu 20.04, VS code 1.53 and Language-Cython 0.0.6, and having the same problem as @T4mmi

Same issue as @kasliwalr in Windows 10 and V.S. code 1.72.1

same issue with macOS

Same issue, Windows 10 and VS Code 1.73.1