klogg needs update to latest version

Bug Report
Package Name: klogg
Current Behaviour
klogg package is currently at outdated version <IP_ADDRESS>3
Expected Behaviour
klogg package should be updated to latest version, currently <IP_ADDRESS>8
Additional context/output
It looks like the release file name format has been changed, for example: klogg-<IP_ADDRESS>8-Win-x64-Qt5-portable.zip
System details
Windows version: 10
OS architecture: 64bit
PowerShell version: 7.2.4

Hi! Can you make a PR for it?


feat: add more detailed information to the rollback output

https://github.com/widefix/actual_db_schema/issues/45
This PR adds more information to the rollback message output displayed to the user.
Previously we were only showing the list of migrations that were not successfully rolled back but this PR includes the list of successfully rolled back migrations if any and also informs the user of the reason for the attempted rollback of migrations by the gem.

Thank you for your contribution! I truly appreciate your effort and the work you’ve put into this. However, I’m closing this PR in favor of https://github.com/widefix/actual_db_schema/pull/104


how to make it online processing for outputting Non-ground points

Hi~
I want to use it on my SLAM, but after I change the topic in run_patchwork.launch, it warns
[ INFO] [1683712130.658571863]: Inititalizing PatchWork...
Global thr. is not in use
[ INFO] [1683712130.661795518]: Sensor Height: 1.723000
[ INFO] [1683712130.661803499]: Num of Iteration: 3
[ INFO] [1683712130.661807762]: Num of LPR: 20
[ INFO] [1683712130.661811605]: Num of min. points: 10
[ INFO] [1683712130.661816381]: Seeds Threshold: 0.500000
[ INFO] [1683712130.661820503]: Distance Threshold: 0.125000
[ INFO] [1683712130.661824912]: Max. range:: 80.000000
[ INFO] [1683712130.661830104]: Min. range:: 2.700000
[ INFO] [1683712130.661834419]: Num. rings: 16
[ INFO] [1683712130.661838921]: Num. sectors: 54
[ INFO] [1683712130.661842516]: adaptive_seed_selection_margin: -1.100000
[ INFO] [1683712130.662416103]: Uprightness threshold: 0.707000
[ INFO] [1683712130.662421158]: Elevation thresholds: 0.523000 0.746000 0.879000 1.125000
[ INFO] [1683712130.662425354]: Flatness thresholds: 0.000500 0.000725 0.001000 0.001000
[ INFO] [1683712130.662428703]: Num. zones: 4
INITIALIZATION COMPLETE
80859th node come
Failed to find match for field 'label'.
Failed to find match for field 'id'.
Operating patchwork...
[ros_kitti_lin_15646_1444545934531213044-2] process has died [pid 15663, exit code -11, cmd /home/oem/Projects/water_surface_detect_ws/devel/lib/patchwork/ros_kitti /patchwork/cloud:=/lslidar_point_cloud __name:=ros_kitti_lin_15646_1444545934531213044 __log:=/home/oem/.ros/log/2eda3d38-ef16-11ed-bcab-3108b3958f44/ros_kitti_lin_15646_1444545934531213044-2.log].
log file: /home/oem/.ros/log/2eda3d38-ef16-11ed-bcab-3108b3958f44/ros_kitti_lin_15646_1444545934531213044-2*.log

how could I just using your work to filter my point cloud?
Most Sincere Respect for You~~~

Could you check the input of the sensor height estimation module? What platforms do you use? In cases of automobiles, sometimes fine-tuning is required.

did you mean that parameter 'Sensor Height' in params.yaml? Dost it need a precise value? because in my work which is on boat, the height from water face to laser sensor will change a little.

My platforms : Ubuntu 20.04, ROS Noetic

I use gdb check the error. It tells error is about Eigen.

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff3322700 (LWP 617513)]
[New Thread 0x7ffff2b21700 (LWP 617514)]
[New Thread 0x7ffff2320700 (LWP 617515)]
[New Thread 0x7ffff1b1f700 (LWP 617516)]
[ INFO] [1683770191.875773722]: Inititalizing PatchWork...
Global thr. is not in use
[ INFO] [1683770191.878789986]: Sensor Height: 2.500000
[ INFO] [1683770191.878796261]: Num of Iteration: 3
[ INFO] [1683770191.878801150]: Num of LPR: 20
[ INFO] [1683770191.878805695]: Num of min. points: 10
[ INFO] [1683770191.878810529]: Seeds Threshold: 0.500000
[ INFO] [1683770191.878815144]: Distance Threshold: 0.125000
[ INFO] [1683770191.878820305]: Max. range:: 80.000000
[ INFO] [1683770191.878824690]: Min. range:: 2.700000
[ INFO] [1683770191.878829233]: Num. rings: 16
[ INFO] [1683770191.878833548]: Num. sectors: 54
[ INFO] [1683770191.878838588]: adaptive_seed_selection_margin: -1.100000
[ INFO] [1683770191.879345830]: Uprightness threshold: 0.707000
[ INFO] [1683770191.879351874]: Elevation thresholds: 0.523000 0.746000 0.879000 1.125000
[ INFO] [1683770191.879357327]: Flatness thresholds: 0.000500 0.000725 0.001000 0.001000
[ INFO] [1683770191.879364911]: Num. zones: 4
INITIALIZATION COMPLETE
80859th node come
Failed to find match for field 'label'.
Failed to find match for field 'id'.
Operating patchwork...
--Type <RET> for more, q to quit, c to continue without paging--c

Thread 1 "ros_kitti" received signal SIGSEGV, Segmentation fault.
0x000055555573fb54 in Eigen::internal::coeff_visitor<Eigen::Matrix<double, 1, -1, 1, 1, -1> >::init (this=0x7fffffffbd30, value=<error reading variable>, i=0, j=0) at /usr/include/eigen3/Eigen/src/Core/Visitor.h:133
133         res = value;

for more detals:
#0  0x000055555573fb54 in Eigen::internal::coeff_visitor<Eigen::Matrix<double, 1, -1, 1, 1, -1> >::init (this=0x7fffffffbd30, value=<error reading variable>, i=0,
    j=0) at /usr/include/eigen3/Eigen/src/Core/Visitor.h:133
#1  0x0000555555739146 in Eigen::internal::visitor_impl<Eigen::internal::min_coeff_visitor<Eigen::Matrix<double, 1, -1, 1, 1, -1> >, Eigen::internal::visitor_evaluator<Eigen::Matrix<double, 1, -1, 1, 1, -1> >, -1>::run (mat=...,
    visitor=...) at /usr/include/eigen3/Eigen/src/Core/Visitor.h:49
#2  0x0000555555731703 in Eigen::DenseBase<Eigen::Matrix<double, 1, -1, 1, 1, -1> >::visit<Eigen::internal::min_coeff_visitor<Eigen::Matrix<double, 1, -1, 1, 1, -1> > > (this=0x7fffffffbe10, visitor=...)
    at /usr/include/eigen3/Eigen/src/Core/Visitor.h:116
#3  0x0000555555729e04 in Eigen::DenseBase<Eigen::Matrix<double, 1, -1, 1, 1, -1> >::minCoeff<unsigned long> (this=0x7fffffffbe10, index=0x7fffffffbe40)
    at /usr/include/eigen3/Eigen/src/Core/Visitor.h:229
#4  0x0000555555721436 in PatchWork<PointXYZILID>::consensus_set_based_height_estimation (this=0x55555587e030, X=..., ranges=..., weights=...)
    at /home/oem/Projects/water_surface_detect_ws/src/patchwork/include/patchwork/patchwork.hpp:416
#5  0x00005555557162c7 in PatchWork<PointXYZILID>::estimate_sensor_height (
    this=0x55555587e030, cloud_in=...)
    at /home/oem/Projects/water_surface_detect_ws/src/patchwork/include/patchwork/patchwork.hpp:478
--Type <RET> for more, q to quit, c to continue without paging--c
#6  0x000055555570b4c5 in PatchWork<PointXYZILID>::estimate_ground (this=0x55555587e030, cloud_in=..., cloud_out=..., cloud_nonground=..., time_taken=@0x5555558245e0: 0) at /home/oem/Projects/water_surface_detect_ws/src/patchwork/include/patchwork/patchwork.hpp:500
#7  0x00005555556ff793 in callbackNode (msg=...) at /home/oem/Projects/water_surface_detect_ws/src/patchwork/nodes/ros_kitti.cpp:90
#8  0x0000555555735c6e in boost::detail::function::void_function_invoker1<void (*)(boost::shared_ptr<sensor_msgs::PointCloud2_<std::allocator<void> > const> const&), void, boost::shared_ptr<sensor_msgs::PointCloud2_<std::allocator<void> > const> const&>::invoke (function_ptr=..., a0=...) at /usr/include/boost/function/function_template.hpp:117
#9  0x000055555574cade in boost::function1<void, boost::shared_ptr<sensor_msgs::PointCloud2_<std::allocator<void> > const> const&>::operator() (this=0x5555558f6490, a0=...) at /usr/include/boost/function/function_template.hpp:763
#10 0x0000555555744a00 in boost::detail::function::void_function_obj_invoker1<boost::function<void (boost::shared_ptr<sensor_msgs::PointCloud2_<std::allocator<void> > const> const&)>, void, boost::shared_ptr<sensor_msgs::PointCloud2_<std::allocator<void> > const> >::invoke(boost::detail::function::function_buffer&, boost::shared_ptr<sensor_msgs::PointCloud2_<std::allocator<void> > const>) (function_obj_ptr=..., a0=...) at /usr/include/boost/function/function_template.hpp:158
#11 0x00005555557af773 in boost::function1<void, boost::shared_ptr<sensor_msgs::PointCloud2_<std::allocator<void> > const> >::operator() (this=0x55555590b938, a0=...) at /usr/include/boost/function/function_template.hpp:763
#12 0x00005555557aef8d in ros::SubscriptionCallbackHelperT<boost::shared_ptr<sensor_msgs::PointCloud2_<std::allocator<void> > const> const&, void>::call (this=0x55555590b930, params=...) at /opt/ros/noetic/include/ros/subscription_callback_helper.h:144
#13 0x00007ffff7bc9139 in ros::SubscriptionQueue::call() () from /opt/ros/noetic/lib/libroscpp.so
#14 0x00007ffff7b77172 in ros::CallbackQueue::callOneCB(ros::CallbackQueue::TLS*) () from /opt/ros/noetic/lib/libroscpp.so
#15 0x00007ffff7b78883 in ros::CallbackQueue::callAvailable(ros::WallDuration) () from /opt/ros/noetic/lib/libroscpp.so
#16 0x00007ffff7bcbfcf in ros::SingleThreadedSpinner::spin(ros::CallbackQueue*) () from /opt/ros/noetic/lib/libroscpp.so
#17 0x00007ffff7bb421f in ros::spin() () from /opt/ros/noetic/lib/libroscpp.so
#18 0x0000555555700eff in main (argc=1, argv=0x7fffffffd528) at /home/oem/Projects/water_surface_detect_ws/src/patchwork/nodes/ros_kitti.cpp:171

as for params.yaml, I just change the sensor height, the others did not change.
# 22.05.02 Update
#          `sensor_height` denotes the elevation of the origin of the point cloud "with respect to the ground"
#          So, it mostly have a positive value
#          Note that if `patchwork/ATAT/ATAT_ON` is set to be true, the sensor_height is auto-calibrated
sensor_height: 2.5

# Extrinsics (Raw lidar coordinate -> Coordinate that is parallel to the X-Y plane of ground)
# But, not in use
extrinsic_trans: [0.0, 0.0, 0.0]
extrinsic_rot: [1, 0, 0,
               0, 1, 0,
               0, 0, 1]
patchwork:
    mode: "czm"
    verbose: true # To check effect of uprightness/elevation/flatness
    visualize: true # Ground Likelihood Estimation is visualized
    # Ground Plane Fitting parameters
    num_iter: 3
    num_lpr: 20
    num_min_pts: 10
    th_seeds: 0.5
    th_dist: 0.125
    max_r: 80.0
    min_r: 2.7 # to consider vicinity of mobile plot form.
    uprightness_thr: 0.707 # For uprightness. 45: 0.707 / 60: 0.866. The larger, the more conservative

    # The points below the adaptive_seed_selection_margin * sensor_height are filtered
    # For reject points caused by reflection or multipath problems.
    # it should be lower than -1.0
    adaptive_seed_selection_margin: -1.1

    # It is not in the paper
    # It is also not matched our philosophy, but it is employed to reject some FPs easily & intuitively.
    # For patchwork, the global elevation threshold is only applied on Z3 and Z4
    using_global_elevation: false
    # W.r.t sensor frame (That is, if it is 0.0, then the candidates whose z is higher than z height of 3D LiDAR sensor are rejected
    global_elevation_threshold: -0.5

    # 22.05.02 Update
    # ATAT is the abbrev. for All-Terrain Automatic heighT estimator
    # It automatically corrects the wrong sensor height input
    ATAT:
        ATAT_ON: true
        # 22.05.02 Update
        # IMPORTANT - `max_r_for_ATAT` affects the quality of the estimation of sensor height
        # If it is too large, then the z-elevation values of the bins become more ambiguous
        # If it is too small, there is a potential risk that does not include the cloud points in the vicinity of the vehicles/mobile robots
        # Therefore, it should be set appropriately!
        max_r_for_ATAT: 5.0
        num_sectors_for_ATAT: 20
        noise_bound: 0.2

    uniform: # deprecated
        num_rings: 16
        num_sectors: 54
    czm:
        # Note that `num_zones` == size of `num_sectors_each_zone` == size of `num_rings_each_zone` == size of `min_ranges` - 1
        # To divide zones, max_r, min_r, and min_ranges are utilized
        num_zones: 4
        num_sectors_each_zone: [16, 32 ,54, 32]
        num_rings_each_zone: [2, 4, 4, 4]
        # Note that `min_r` == `min_ranges_each_zone`[0]!
        min_ranges_each_zone: [2.7, 12.3625, 22.025, 41.35]
        # 22.05.02 Update
        # For usability, the MEANING OF THE ELEVATION THRESHOLDS IS CHANGED!!!!
        # Original - the elevation w.r.t. to the sensor frame
        # Modified - the elevation w.r.t. to the ground
        # Thus, -sensor_height + elevation_threshold is the criteria.
        # E.g. for the first ring, -1.723 (sensor height in the KITTI) + 0.523 = -1.2 becomes the criteria of the elevation filter
        # That is, if the z-elevation of the bin is higher than -1.2, then the cloud points from the bin are rejected
        elevation_thresholds:  [0.523, 0.746, 0.879, 1.125] # For elevation. The size should be equal to flatness_thresholds vector
        flatness_thresholds:  [0.0005, 0.000725, 0.001, 0.001]  # For flatness. The size should be equal to elevation_thresholds vector

I get your great work via LineFit. LineFit can not remove all water face point on my situation.
this is linefit extract water face points:

this is the useful points:

so, I want to use your work to check the performance on this situation

Sorry for late reply, but as a postdoc, I have lots of things to do for other researches, Haha, is it solved? If you want to keep continue, re-open this issue please!


store app before unserialize and restore app after unserialize

I try to migrate from 2.3 to 2.4 of Codeception and I got some strange errors.
For example - if 4 test runs both the last test generate a error. I trace this. And I can see strange behavior: the unserialize of cache table schema will set \Yii::$app to null.
Directly past same data to unserizlize don't make any effect... But this is happens. May be this is not a unique case...
This PR will propose restore global $app.

Q
A

Is bugfix?
yes

New feature?
no

Breaks BC?
no

Tests pass?
yes

Fixed issues
comma-separated list of tickets # fixed by the PR, if any

@SamMousa please check it.

I can't repeat it now


Support Nested IQbservable

Services that are themselves clients of upstream Qactive services (or any other IQbservable<T> implementation) may wish to expose their IQbservable<T> to downstream clients. Ensure that this is possible.

This may be difficult since C# doesn't respect nested providers. The expression following a nested IQbservable seems to always be part of the outer query expression, while the IQbservable reference itself is just a single ConstantExpression within the outer expression tree.

One of my labs targeting the latest version of C# actually seemed to have the expected behavior, although I'm not exactly sure yet. Leaving this item open as a reminder to have a deeper look again.


identify2 untracked fast path

if we're in CHAT GUI mode, and we're identifying someone we don't track, there's
really not much to do.  Allow a "fast path" which does minimal work on the user.
in reality, a lot of tests should be revamped with this change, but don't incur
such a huge change, just test this behavior selectively.

Cc: @mmaxim  and @malgorithms, this might give us a good speed improvement for interacting with unfollowed users


Babel5 Builds break in the latest change.

There is still a lot of us that haven't switched from Babel5 to 6.
The latest commit  broke all my builds and I get this error:
ERROR in ./~/react-image-crop/index.js
Module parse failed: /usr/src/app/node_modules/react-image-crop/index.js Line 2: Unexpected token
You may need an appropriate loader to handle this file type.
| //http://stackoverflow.com/a/33683495/414062
| import ReactCrop from './dist/ReactCrop';
| export default ReactCrop;
|

Please consider doing something like this:
var ReactCrop = require('./dist/ReactCrop');
module.exports = ReactCrop;

I've tested it and can confirm that this works in Babel 5.

Thanks @ddaza, that makes sense I'll test it now

@ddaza Please try version 0.1.9 and let me know if that fixes your issue.

:+1: it works! thanks.

Cool - thanks for checking


FIx: Remove the to much margin top on the Scene controls panel

FoundryVTT Core Version: 9.249
System: dnd5e 1.5.7
ModuleVersion: 1.4.16
A notice i get to much margin top on the scene controls:

A simple solution mayvbe is to remove margin-top: var(--controlstop); line ?
#controls {
    opacity: var(--opacitycontrols);
    transition: 2s;
    /* margin-top: var(--controlstop); */
    margin-left: -14px;
}

here the result:

Hey @p4535992
Thank you for the feedback. Yes right now the control y-axis position is not defined since the V9 build.
I guess, I will soon push a configuration for the user to pick it's preferred position, also remember that many users have 3-5 rows of scenes in the navigation above!


feat: Reference import-sort config file by path

Hello,
I was wondering how feasible it would be to allow users to store their configuration somewhere other than the root of the repository with a --config/ -c flag a la prettier and eslint cli's (ie: ./config/importsort.config.js).
Cheers!

Follow Up: Pull Request #125 will implement this.


Duplicate key handling without rollback

This PR fixes https://github.com/eu-federation-gateway-service/efgs-federation-gateway/issues/269.

Fix and extend unit test of duplicate key handling
Avoid database rollback when upload contains duplicate keys:
By finding and filtering duplicates (conflicts) before inserting them
into the database, we avoid triggering a rollback of the transaction.
Additionally, we need to tell the @transaction not to rollback on
DiagnosisKeyDuplicateInsertException's, which are triggered when
duplicates were detected.
In case of exceptions while trying to INSERT a key into the database,
we have to assume a rollback on database level will be triggered and
therefore report all keys as failed (empty 201 list).

Closed --> https://github.com/eu-federation-gateway-service/efgs-federation-gateway/issues/269#issuecomment-839642038


How publish events to Kafka Topic without introducing Ouputchannel Java interface.

Hello,
This is not an issue but more of a Spring cloud stream kafka output channel capabilities question. We use spring cloud stream kafka module to publish and subscribe events between several microservices. To publish an event to a kafka topic the developer has to set up output channel configuration and also an output channel java interface. However, we have an utility service that dynamically needs to broadcast message to several dynamic topics. We can achieve using spring cloud stream but it requires a code change every time we need to deal new a topic. We are OK with introducing new output channel definition in our config server, but is there a way we can publish events without introducing the java interface definition.

Hi,
If I understand your requirements correct, you need to use BinderAwareChannelResolver when resolving your outbound destination names (the kafka topic names here) so that the message channels are bound to the Kafka topic via kafka binder dynamically. The property spring.cloud.stream.dynamicDestinations can have a pre-defined list of destination names or can be empty (to have all the resolved destination names to be bound).

Hi @dvsridhar,
You can also check out this sample that uses dynamic destination resolution.
Closing this as answered and please feel free to re-open if you have any more questions related o this.


Add a new module supports datafaker

Describe the feature you request
Add a new module supports datafaker

I believe java-faker is no longer maintained. There is an actively maintained forked at https://github.com/datafaker-net/datafaker
@bodiam - maybe somebody from the Data Faker team can help with the integration?

Hi there! This library looks interesting, and happy to share some ideas on this.
Is there some api or idea you had in mind?

@bodiam
Hi thank you for your help!
We would discuss how to integrate with datafaker in a weekly meeting and share ideas on this issue.
Thank you for your help too, @armandino

@seongahjo no worries. Happy to connect two great libraries.

@bodiam
Hello, we've discussed how to integrate with datafaker.
Is there any way to make a random value which satisfies condition?
For example, we want to make a firstName whose length is 5.
It would be helpful with this feature.

@seongahjo given the nature of the fake values, that would be hard. For example, how would we create a country of 30 characters long? We don't really know the limits even, since they are depending on the Locales.
Yes, it's possible to generate a random string of X characters, but that defeats the purpose of the library.
Can I ask why you'd need such a feature?

@bodiam
We are supporting Jakarta Bean Validation annotations when generating an object.
If a String field has a @Size annotation, the length of field would be a given value.
For example.
class Foo{
   @Size(3)
   String Bar;
}

A length of Bar always be 3.
We'd like to use datafaker to generate a feasible String field value inferred by a property name or other condition.
The field might have Jakarta Bean Validation annotations.
It would be helpful if datafaker supports filtering by length for an above reason.

It's tricky I think. Some of these fields are populated by regular expressions, or concatenations of different fields.
This might be a silly idea, but how about invoking the faker, potentially several times (100s of times shouldn't be an issue), and record the shortest/longest lengths?
DaraFaker cannot, and will never be able to generate a string of arbitrary length for any propery. For example, a license plate of 25 characters wouldn't make sense, or a full name of 2 characters.


Is there anyway to transcribe english audio to other languages like the way original whisper -v3 does.

Hi, is there anyway to transcribe english audio to other languages like the way original whisper -v3 does.
If not, could you please add support for that too. It would be such great. Thank you

What is "whisper -v3"?

"whisper-large-v3"

Can't you do same with "whisper-large-v2" or "faster-whisper-large-v2"?

Can't you do same with "whisper-large-v2" or "faster-whisper-large-v2"?

He probably could... But I think his question is missing a statement of what the actual problem is.

model_size = "large-v3"
model = WhisperModel(model_size, device="cpu")
or run on GPU with INT8
model = WhisperModel(model_size, device="cpu", compute_type="int8_float16")
or run on CPU with INT8
model = WhisperModel(model_size, device="cpu", compute_type="int8")
segments, info = model.transcribe("steve.mp3", beam_size=5, language='fr')
###############################
ok so for example I want to transcribe an english video to french. In original whisper from openAI I can do that by specifying language parameter but it doesn't work here the same way. even If i specify other language, it still transcribe the video in original language which is english.

@guillaumekln  any advise?

If i specify other language, it still transcribe the video in original language which is english.

Can't reproduce. It's something wrong on your end.

So you got english video transription in french ?
Can you show me the output?

u simply misused it, and somehow got lucky it output something.
##################
FYI It works very well. They might have not stated it officially. But my startup uses whisper and we use it for translation tasks as well (translation not to english but to another languages).

Make sure that you have official version and use official model.

Btw, found the official comment about it:
Translating into languages other than English wasn't a part of the training objective, so that behavior may not be always reliable.

I see, but It works well on GPU. I am facing issue only with CPU.

@Purfview  still same issue at my end. Are you sure you are using CPU?

I see, but It works well on GPU. I am facing issue only with CPU.

As you can see in my screenshot it run on CPU

Interesting... it's working fine for french on CPU. But not with korean lol.

Interesting... it's working fine for french on CPU. But not with korean lol.

Read: https://github.com/SYSTRAN/faster-whisper/issues/589#issuecomment-1830342596

What if you use int8_float_32 on GPU?

Let me try

Wait, isn't that actually Korean in your screenshot?

yes, but it's actually wrong.
Your issue that you are getting hallucinations with one quantization type vs another.

Anyway, hallucinations is the trademark of  large-v3, nothing unusual. 😆
Use large-v2!


Change uses of 'blacklist' to 'retrylist'

'Retry' more clearly describes what it does now anyway. This is not a functional difference but will change some exported API methods and require a new release, so it's best bundled with the next round of other stuff.
If anyone wants to take this it before I get around to it, it would be a good first issue and I'd appreciate it!

Hello @gtank I can take it. Should I just change functions signatures (and other references)?

Oops, I missed this notification somehow. Yeah @zamariola, if you still have time that would be amazing!


It is not working on Login Bloc

I'm implementing Login Form with Bloc pattern and I have to manage the size of LoginForm when keyboard is appeared. But It is not working...
import 'package:flutter/material.dart';
import 'package:privacy_of_animal/bloc_helpers/bloc_provider.dart';
import 'package:privacy_of_animal/logics/focus/focus.dart';
import 'package:privacy_of_animal/logics/validation/validation_bloc.dart';
import 'package:privacy_of_animal/resources/colors.dart';
import 'package:privacy_of_animal/resources/constants.dart';
import 'package:privacy_of_animal/widgets/initial_button.dart';
import 'package:keyboard_visibility/keyboard_visibility.dart';

class LoginForm extends StatefulWidget {
  @override
  _LoginFormState createState() => _LoginFormState();
}

class _LoginFormState extends State<LoginForm> with SingleTickerProviderStateMixin{

  final FocusNode _focusNode = FocusNode();
  final ValidationBloc _validationBloc = ValidationBloc();
  final TextEditingController _emailController = TextEditingController();
  final TextEditingController _passwordController = TextEditingController();
  final KeyboardVisibilityNotification _keyboardVisibilityNotification = KeyboardVisibilityNotification();

  @override
    void dispose() {
      _emailController.dispose();
      _passwordController.dispose();
      _focusNode.dispose();
      _keyboardVisibilityNotification.dispose();
      super.dispose();
    }

  @override
  Widget build(BuildContext context) {

    final FocusBloc _focusBloc = BlocProvider.of<FocusBloc>(context);

    _keyboardVisibilityNotification.addNewListener(
      onShow: _focusBloc.emitEvent(FocusEventOn()),
      onHide: _focusBloc.emitEvent(FocusEventOff())
    );

    return Container(
      height: ScreenUtil.height/3,
      width: ScreenUtil.width/1.3,
      color: Colors.red,
      child: Column(
        children: <Widget>[
          StreamBuilder<String>(
            stream: _validationBloc.email,
            builder: (BuildContext context, AsyncSnapshot<String> snapshot){
              return TextField(
                decoration: InputDecoration(
                  labelText: '이메일',
                  errorText: snapshot.error,
                ),
                onChanged: _validationBloc.onEmailChanged,
                keyboardType: TextInputType.emailAddress,
                controller: _emailController,
              );
            },
          ),
          SizedBox(height: 20.0),
          StreamBuilder<String>(
            stream: _validationBloc.password,
            builder: (BuildContext context, AsyncSnapshot<String> snapshot){
              return TextField(
                decoration: InputDecoration(
                  labelText: '비밀번호',
                  errorText: snapshot.error
                ),
                onChanged: _validationBloc.onPasswordChanged,
                obscureText: true,
                keyboardType: TextInputType.emailAddress,
                controller: _passwordController,
              );
            },
          ),
          SizedBox(height: 30.0),
          StreamBuilder<bool>(
            stream: _validationBloc.loginValid,
            builder: (BuildContext context, AsyncSnapshot<bool> snapshot){
              return InitialButton(
                text: '로그인',
                color: introLoginButtonColor,
                callback: (snapshot.hasData && snapshot.data==true) ? (){} : null,
              );
            },
          )
        ],
      ),
    );
  }
}

What is the problem?

I will close this issue as there hasn't been any updates recently. If the problem still persists, please re-open


'NoneType' object is not callable and CalledProcessError

Hi! When I try the nlp sample code, some errors occur.
Traceback (most recent call last):
  File "./nlp_example.py", line 173, in <module>
    main()
  File "./nlp_example.py", line 169, in main
    training_function(config, args)
  File "./nlp_example.py", line 64, in training_function
    datasets = load_dataset("glue", "mrpc")
  File "/home/water/anaconda3/envs/Sodic/lib/python3.7/site-packages/datasets/load.py", line 741, in load_dataset
    **config_kwargs,
TypeError: 'NoneType' object is not callable
Traceback (most recent call last):
  File "./nlp_example.py", line 173, in <module>
    main()
  File "./nlp_example.py", line 169, in main
    training_function(config, args)
  File "./nlp_example.py", line 64, in training_function
    datasets = load_dataset("glue", "mrpc")
  File "/home/water/anaconda3/envs/Sodic/lib/python3.7/site-packages/datasets/load.py", line 741, in load_dataset
    **config_kwargs,
TypeError: 'NoneType' object is not callable
Traceback (most recent call last):
  File "/home/water/anaconda3/envs/Sodic/lib/python3.7/runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "/home/water/anaconda3/envs/Sodic/lib/python3.7/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/home/water/anaconda3/envs/Sodic/lib/python3.7/site-packages/torch/distributed/launch.py", line 260, in <module>
    main()
  File "/home/water/anaconda3/envs/Sodic/lib/python3.7/site-packages/torch/distributed/launch.py", line 256, in main
    cmd=cmd)
subprocess.CalledProcessError: Command '['/home/water/anaconda3/envs/Sodic/bin/python', '-u', './nlp_example.py']' returned non-zero exit status 1.

It looks like there is something wrong with your installation of the datasets library, as the script fails on that line datasets = load_dataset("glue", "mrpc") which has nothing to do with Accelerate.

Ok, I will try it again


AP Exams Week 1 - Proctored MC

Points: 2/2

[x] GH Indi Page, Review Ticket, Crossover graded, Study Plan
Github Page
[x] Quiz5 MCQ results >50%, (1 or 0) and test corrections (47/50)
Quiz Corrections

Points: 2/2

[x] GH Indi Page, Review Ticket, Crossover graded, Study Plan
Github Page
[x] Quiz5 MCQ results >50%, (1 or 0) and test corrections (47/50)
Quiz Corrections


Rework cache implementation

Closes #10
BREAKING CHANGES:

Change the namespace in which the PokeApiClient is located
Removed PokeApiNet.Data namespace
PokeApiClient#ClearCache<T> -> PokeApiClient#ClearResourceCache<T>

TODO:

[x] Update README file

Next step would be to add support for configuring the expiration policies of a client´s cache. Let me know what you think @mtrdp642

@mtrdp642 addressed all your points :100: thanks for the review

I forgot to suggest you not to release a new version until the possibility for configuring the cache expiration is implemented :speak_no_evil:


Godot 4: script variables in Visual Script are always exported

Godot version
v4.0.alpha2.official [79077e6c1]
System information
Windows 11, Vulkan Clustered, Intel UHD Graphics 620 v<IP_ADDRESS>0
Issue description
The script variables in Visual Script are exported by default regardless of the export toggler, as shown in the screen recording below:
https://user-images.githubusercontent.com/1403194/154159591-05cc7d80-4f65-4b91-b57b-d40cfacb8e03.mp4
And there's no way to turn it off due to the issue #58072.
This is a regression from Godot 3.4.
I expect the variable to be exported only when selected.
Steps to reproduce

Create a variable in Visual Script. It will be exported regardless of the export toggler.

Minimal reproduction project
No response

Update: even though the variable always shows in the inspect tab as the exported variable, the users can't change its value in the inspector tab unless they actually exported the variable, as shown in the screen recording below:
https://user-images.githubusercontent.com/1403194/155009546-9f9c82a3-7055-4b16-a556-032d9ce00c15.mp4

I did a check and this issue seems to be there from V4.0a1.
The VisualScriptEditorVariableEdit seems to save the export variable_parameter.
So I assume when converting to GDScript 2.0 there is a change in how the export is handled, and as the export variable_parameter is no longer found the inspector defaults to showing the variable.
@Calinou Do you know the next person to ping to get more guidance?

So I assume when converting to GDScript 2.0 there is a change in how the export is handled, and as the export variable_parameter is no longer found the inspector defaults to showing the variable.

VisualScript does not compile to GDScript behind the scenes.

@Calinou Do you know the next person to ping to get more guidance?

I don't know who else is actively working on visual scripting, sorry. I've never worked on it myself.

VisualScript does not compile to GDScript behind the scenes. This is probably due to something else.
Indeed.
The problem is that the editor may now interpret "exported" differently than 3.x


Optimize for server requests/responses

Thoughts for discussion, and a few suggestions:
A large % of json parsed in this world is parsed as server requests and responses. There are a few relevant characteristics here:

Throughput of a single document still matters, but bulk throughput is the bottleneck for such a server--specifically, how many documents you can parse at a time.
POST requests (the main place you do JSON, though sometimes it gets encoded into a query parameter in the URL) tend to be very small (in many cases {}, but often something like { "q": "name = 'john'" }). In fact, if you could measure every valid JSON document ever, you'd find a very significant percentage are the strings {} and { }.
Responses from a given endpoint (not all) tend to be very similar sizes because an endpoint tends to have a single record schema (which often have similar length) and the endpoint type dictates a lot about the response as well.

POST endpoints designed to do an operation, for example, will usually return short responses: {} or { "success": "true" }.
GET endpoints designed to return a single record will often return small or small-ish responses like { "id": 1, "name": "john" }--particularly, endpoints like this that return < 64 bytes are likely to do so frequently.
GET endpoints designed to return a list of records are much harder to predict, but many will be small, for two reasons: first, many lists are just empty :) And second, the entries in a lists generally don't return the whole record and tend to be small, so a surprising number of nonempty lists will fit in under 64 bytes: [ { "id": 1 }, { "id": 10 }, { "id": 20 } ] for example.

Depending on the country you are in, endpoints returning user-facing strings and communication will return non-ASCII UTF-8 on nearly every call. However, even in those countries, these endpoints tend to live alongside other endpoints that only ever return ASCII (for computer to computer communication). In these countries, branch misprediction of UTF-8 in a server will probably be pretty high. And since most of the documents are not going to be huge (a single message, a single customer ...) you don't always get the benefit of the fact that a single document will probably have UTF-8 in nearly every chunk, or nowhere.

All this is to say, we might do well to think about the effects of misprediction in a typical server architecture, where a thread pool is used to handle all requests and threads have no affinity to a given endpoint or JSON profile. In these situations, where there are many different endpoints. My thoughts:

Can we get simdjson to match other JSON parsers when parsing loads and loads of small (< 64 byte) documents?
Can we reduce misprediction for users who know which of their endpoints have mostly small documents and which have lots of UTF-8? For example, a separate copy of the function for each situation, which the user calls and the processor does branch prediction differently each time? Would the instruction cache effect overwhelm the benefit of fewer mispredictions?
Much more "pie in the sky" crazy mode: for super high load situations on endpoints with lots of small documents: I'm curious if simdjson could parse multiple documents in bulk, benefitting from a "batch mode" where multiple documents are crammed together in a single queue. The user could have a small parsing thread pool and cram documents together, asking simdjson to parse them in bulk whenever the buffer reaches 64 bytes or a timeout occurs. Latency increases but overall throughput might be improved.

Can we get simdjson to match other JSON parsers when parsing loads and loads of small (< 64 byte) documents?

Handling tiny documents very fast is certainly possible and fun. However, it is almost an entirely different problem. That is not to say that we shouldn't or couldn't do it... but it almost certainly best handled with a different/new code base.
Would you open this as a new issue?

Can we reduce misprediction for users who know which of their endpoints have mostly small documents and which have lots of UTF-8? For example, a separate copy of the function for each situation, which the user calls and the processor does branch prediction differently each time?

UTF-8 validation is a small part of our parsing as things stand now.  Have you tried running benchmarks?

Much more "pie in the sky" crazy mode: for super high load situations on endpoints with lots of small documents: I'm curious if simdjson could parse multiple documents in bulk, benefitting from a "batch mode" where multiple documents are crammed together in a single queue.  The user could have a small parsing thread pool and cram documents together, asking simdjson to parse them in bulk whenever the buffer reaches 64 bytes or a timeout occurs. Latency increases but overall throughput might be improved.

This is very similar to an existing issue, see https://github.com/lemire/simdjson/issues/188

Handling tiny documents very fast is certainly possible and fun. However, it is almost an entirely different problem. That is not to say that we shouldn't or couldn't do it... but it almost certainly best handled with a different/new code base.

I guess I'm interested in having a valid choice of the fastest JSON parser overall, because I see in simdjson an actual chance to fight global warming :) Bulk processing a la the ndjson thing might help a ton with server throughput, even if it reduces average latency by a little bit. Either way, we should at least have benchmarks and find out exactly what.

Would you open this as a new issue?

Will do!

UTF-8 validation is a small part of our parsing as things stand now. Have you tried running benchmarks?

@lemire Unless I'm way off in my benchmarks, the UTF-8 check nearly doubles stage 1 iteration time (adds about 75%), even without misprediction.
Source: ./parse -tf [structurals-2.json](https://github.com/lemire/simdjson/blob/benchmarker/jsonexamples/baseline-2-structurals.json) and ./parse -tf [baseline-utf-8.json](https://github.com/lemire/simdjson/blob/benchmarker/jsonexamples/baseline-utf-8.json), both 640KB files with 2 structurals per block, one of which has UTF-8 in every block.
(I don't have a good measure of overall impact because one file has numbers and one has strings, which stage 2 treats differently. I'll fix that when I have a moment.)

I’m game to pursue this.
There are things we know regarding the processing of small batches... the overhead (e.g. the memory allocation, function calls) that is negligible when the data has a non-trivial size end up dominating the running time.
Also the metrics need to change... instead of GB/s, you want to move toward measures like documents per second...
I’ll check your UTF-8 benchmark.

Back to UTF-8...
You are correct that in the example you refer to (baseline-utf-8.json), utf-8 validation uses half of the running time. I invite you to contribute at least some of these synthetic cases to master so we can include them in our ongoing performance tests.
I don't think I ever saw such a relatively high UTF-8 cost in a JSON file.
Stage 1, in your example, on one test machine goes from 3.4 GB/s to 6.4 GB/s if I disable UTF-8 validation.  That means that UTF-8 validation runs at 3.4 GHz in this case if my math is correct.
For the next simdjson version, I'd like to move UTF-8 validation to the string tape. Doing so in this case should drastically lower the cost since only a small fraction of the input is actually string content. The idea would be to only run UTF-8 validation on string content.
This means that we should be able to get a nice speed bump for baseline-utf-8.json.
Hence I reiterate that it would be interesting to have it as part of our core benchmarks.

Yep, those are part of a set of files including misprediction cost measurement, as well as feature based performance reporting to help figure it what tradeoffs you are making. It needs a few updates before I'm ready to make it a pr, though.

That means that UTF-8 validation runs at 3.4 GHz in this case if my math is correct.

@lemire note that this is in-context perf impact of UTF-8, which can differ in either direction from the actual impact. If UTF-8 validation causes a long pole to get longer and stop soaking up CPU with parallel instructions, the impact of UTF-8 validation could be higher than its actual cost. If it causes a higher instructions-per-cycle with parallel instructions, then the actual cost will be lower.
At any rate, I think you're 100% right about moving it to the string tape. It's going to be the highest-density place to run it, bar none.

Yeah. Also, keys tend to have VERY high duplication rate across a single file, and are often looked up by name, meaning hashing and dedup might actually buy something.
Even more, because they are typically unescaped, you could dedup before you unescape or write to the string tape, and because they are ASCII, you wouldn't have to worry about Unicode equality canonicalization--just a straight hash of the bytes would be enough for comparison (sans hash collisions, which I don't know what to think about). Keys that had non-normalized Unicode or backslashes wouldn't get deduped, but it might be win anyway.
Heh, getting off topic. As far as optimizing for server requests/responses, I am hoping that SIMD and branch-free techniques will make us faster for documents >= 64 bytes. I think I can live with being slower on < 64 bytes, as long as it's not a huge multiplier.

I think that a good first step would be to write a benchmark. Simulate a stream of server responses.

For this purpose, I think "parse a generically representative spread of documents, for example, 10% 16-byte, 50% 256-byte, 25% 1K, 10% 1M, 5% 10M" is a reasonable benchmark. Percentages may vary, I'm anecdotizing based on servers I've built or used. 16-byte is empty requests/responses. 256-byte are small single objects and lists. 1K is large single objects and reasonably-sized lists. 1M-10M is Just About Everything Else.

It looks to me like we are already faster than the competition for pretty much all sizes.  I can't believe I did not run these benchmarks for myself some time ago.
Of course, we want memory allocation to be done ahead of time... otherwise we probably suffer. So if you are going to eat just one tiny JSON, we are probably not super competitive. Of course, if you are just going to eat one tiny JSON, parsing performance is probably not high on your list of priorities.
Thanks for documenting this... we probably should update the README accordingly.
Do we close this issue, now?

I think so. Streaming parsing would make it easier too, but this is the big blocker.


deps: bump fuel-core to 0.18 and fuel-* to 0.31

We have the sway repo bump here here:
https://github.com/FuelLabs/sway/pull/4428
But I think I am blocked on it since we don't have a SDK release which supports latest the fuel-vm repo crates: (fuel-vm, fuel-tx, fuel-asm etc).

Blocked until a new release of fuel-core.

Unblocked, working on it

Closed by #950


Easter egg?

While looking at the .txt file I found this one:
Human injection

Strings which may cause human to reinterpret worldview
If you're reading this, you've been in a coma for almost 20 years now. We're trying a new technique. We don't know where this message will end up in your dream, but we hope it works. Please wake up, we miss you.
Although I found it humourous I don't think it's testing any actual bug, maybe you should consider to remove it. Or maybe just leave it as an easter egg, I just wanted to point it to you.

I'm ok with some 4th wall breaks (e.g. the reinterpret wordview string) but I don't want to fill it up with all the memes.

It also serves as a control. (Something that should present no trouble to any test and, if it does, it's not the naughtiness of the string that's causing the problem.)

Closing since other comments cover the issue adequately.

It is there because it is true. We're trying to communicate with you @GTP95

@ChipWolf lol

An interesting discussion about this: https://news.ycombinator.com/item?id=18467263
Could it trigger people into psychotic states?


Mermaid support

Dear Saul-Mirone!
Thanks for the extension, I love it. The only thing I miss is the Mermaid support. I saw that milkdown has a plugin for it. Could you add/enable it to this extension?

And btw the first link in the README is broken.

Thanks, I'll add the mermaid support.


Consider merging with aws-secret-operator

https://github.com/mumoshu/aws-secret-operator is a very similar concept, consider merging two projects.

Doh -- just when you think you've scoured the internet.  Thanks @max-lobur.  Yes, we I agree, we should definitely consider merging.

There's also this :)
https://github.com/ContainerSolutions/externalsecret-operator

....and https://github.com/cmattoon/aws-ssm :)

Ok ok, but how should we deal with it? What would be the right approach here for considering to merge?

I believe the right approach would be to reach out to these projects and ask them if they want to unify their efforts in a single project.
Maybe open github issues in each of those projects that links to this issue to start a discussion?

Hi there, and thank you for reaching out!
I am one of the contributors of https://github.com/ContainerSolutions/externalsecret-operator and I think that we would definitely benefit from aligning on a common CRD spec.
We deliberately wanted to keep it simple, so our CRs currently look like this:
apiVersion: externalsecret-operator.container-solutions.com/v1alpha1
kind: ExternalSecret
metadata:
  name: example-externalsecret
spec:
  Key: example-externalsecret-key
  Backend: asm-example

But it might not be enough for the others?

I played around with the idea of doing something similar to what you get with StorageClass, PersistentVolumeClaim and PersistentVolume.
I wrote the idea down in a gist to start a discussion about that (maybe it's overcomplicated):
https://gist.github.com/reegnz/acc1f97fe3e78746394103e9c96d9c76

I like the idea of using annotations.
We had a very similar implementation to support multiple backends on a single operator deployment: https://github.com/ContainerSolutions/externalsecret-operator/issues/6 but didn't consider using annotations.
We decided to simplify this to one operator deployment, one backend. I believe it is easier to reason about and demand namespace isolation to RBACs. See:

https://github.com/ContainerSolutions/externalsecret-operator/issues/10
https://github.com/ContainerSolutions/externalsecret-operator/pull/18

A few questions:

How would you handle multiple deployments of the same operator with distinct backends?
How do you handle configuration of secret backends? Rely entirely on IAM and AWS SDK credentials discovery?

Note that this project holds the most stars of any of the aforementioned projects, FWIW.

Given my requirements this is the one I was looking for:
https://github.com/mumoshu/aws-secret-operator
I need the Operator to be able to automatically refresh, otherwise there's no real data decoupling and might as well do it with regular secrets and KMS.

@ecout what do you mean by automatically refresh? KES does polling by configurable interval and refreshes the kubernetes secrets with the updated values from the backend.

@Flydiverny Yes, I just tested this one today. It generates VERY verbose logs btw. Also, regarding this issue, why merge two completely different code bases written in different languages.
Please simply UPDATE the READ.me to explicitly say your project supports it.
Thanks!

Hej everyone, i opened #477 with a first draft to continue the discussion on the CRD topic.
Let's assume we've found a common CRD, what's the next step then? Actual git-merging is obviously not an option, do we want to:
A) rewrite this project to keep the precious GitHub stars? :star: :trollface:
B) found a new github organization (to be independent from godaddy / or single-person maintainers)?
C) other ideas?
technology-wise i'd strongly recommend using golang for a rewrite due to the 1st class k8s-sdk support, and tooling w/ operator-sdk or kubebuilder.
What do you think?

First of all, thanks for keeping this effort alive. I even tried to get things rolling together with @slamdev, but other business got in the way. I truly believe there's space to build something cool for the Kubernetes community. Channeling our efforts in one common direction has the potential to have a great tool for secret management and achieve ultimate opensource glory :trollface: .
I believe B is the best option. I also think golang is the right choice.
For the github stars, I think if we play it right we can achieve the same level of popularity in a very short time.
The real difficult part is how can we coordinate our efforts in order to make this happen?

I would love for yall to jump in and help with https://github.com/itscontained/secret-manager. The goal is to do exactly what you have stated with a single CRD. itscontained is not a company, simply an org name i thought was fitting of the ecosystem (docker container based) so there are no ties, and we can all share in management of projects.

As someone just starting out to use KES along with our GitOps setup, I would love to this project thrive. KES has a better idea than Sealed Secrets, which is perhaps the most popular way out there to use secrets along with GitOps, since using managed k8s by cloud providers are becoming the norm and it takes away the human element present in sealed secrets.
Saying that, I want to provide some of my opinions, FWIW:

I would prefer any project that comes out of the merge to work with multiple cloud providers. Right now, KES is the only one which supports the big 3 (AWS, GCP, Azure).
If a plugin approach is chosen, consider creating the major providers in the same org. People wishing to maintain a plugin can be given repo access. This will help is having a single place to manage and would also help in creating docs.
I would love the name of the projects that comes out of the merger to be cloud agnostic with reg. to point 1.

Also, we should have a single issue to have this conversation, as a related conversation is also taking place in #423

@moolen @riccardomc Transferring an existing repo to another account can transfer over the stars too. https://docs.github.com/en/github/administering-a-repository/transferring-a-repository#whats-transferred-with-a-repository . If we decide on a new org to have this project, I would suggest transferring this repo over to that account and then rework this repo itself if a conversion to go is planned.

I think the CRD Spec in #477 is good enough to be implemented in a PoC, let's have a meeting to discuss futher steps on how to channel our efforts, find and organization, move code etc etc.
I made a agenda here for Community Meeting #1 :sparkles: / https://hackmd.io/utPLB9nkSmCmfCmmzOkQgQ?view
Please add a comment or request write access to add topics to the agenda.
I'll drop a message in slack to find a good date and update this comment.

Closing this as there are undergoing efforts in https://github.com/external-secrets/external-secrets :)

Closing this as there are undergoing efforts in https://github.com/external-secrets/external-secrets :)


Failing Test: update Matchers::HaveEnqueuedJob spec to add a hash argument

I discovered recently that the have_enqueued_job matcher breaks when one of the job arguments is a hash (unless they all are. I think this has to do with the any? test in map_arguments.
I am opening a PR with the failing test, but hopefully I’ll have a complete patch shortly after lunch.

It is not immediately obvious to me why HaveEnqueuedJob.map_arguments is recursive, so I am a bit wary of changing the logic in HaveEnqueuedJob.job_arguments. The tests all pass, but I worry there is a corner case where an argument is passed that is not a Hash but does respond to [string].

This fixes #74, discovered independently.

Thank you for this. Always great to have the community pitching in with fixes, very much appreciated.
Can I just confirm, you were able to break the tests initially by adding this addition hash args and make them back green with the patch correct?

@philostler That is correct.
I initially opened the PR with a commit (15622f5) that caused the tests to fail when a hash was included as a worker argument. I planned to fix it, but just in case my assumptions about where the bug was (or the fix caused other tests to fail in ways that were not obvious to fix, or it became a game of whack-a-mole), I wanted to at least provide a starting point for the person who eventually fixed it, even if it ended up being someone else.

Sounds great. I'll release with a patch version change ASAP. Thanks very much again for this PR

Sorry for bumping, but will there be a patch version with this fix? :) This just bit me, happy to see a fix exists.

This fix doesn't seem to be working for me. I've moved to the develop branch in my project and still get the following failing test:
Failure/Error: expect(Workers::PushNotificationWorker).to have_enqueued_job ["info", expected]
       expected to have an enqueued Workers::PushNotificationWorker job with arguments [["info", {"trip"=>"1234", "car"=>1, "driver"=>1, "message"=>"Don't forget to checkin"}]]

       found: [["info", {"trip"=>"1234", "car"=>1, "driver"=>1, "message"=>"Don't forget to checkin"}]]


Invalid signature position while typing property declaration

I got this while typing the starting ( of a property declaration:
[Error - 20:35:47] Request textDocument/signatureHelp failed.
  Message: Invalid signature position {
    line : 67,
    character : 25
}
  Code: 0

Unfortunately I don't have a repro case that reproduces this reliably right now.

Can you try if the new signature handling fixes this?

Let's call this fixed, I didn't have a way to consistently repro this anyway.


Tentative Cygwin support

Cygwin needs PyVarObject_HEAD_INIT(NULL as Windows, but does not need msinttypes/stdint.h.

Thank you very much! Personally I haven't used Cygwin for ages.


custom export/render paths

It would be cool if we didn't necessarily hardcode export/render paths. There should be options, probably specified via command line, to indicate where things should be written. This will allow for easier integration with other tools.

Going to be deprecating all rendering/exporting in favor of other tools.


Passphrase Verification for Seed Backup Flow

I added a section to the end of the seed backup flow that will offer the opportunity for a user to verify their passphrase if the seed they are backing up has a passphrase. I made this up in response to issue #90 as a way for users to verify the passphrase in the backup process while still not showing the passphrase to the user again. This should work for both the seed word backup and the QR backup flows.
One thing that I did not implement in this flow that I think may be useful is a max number of attempts at passphrase verification (like 10 or something) before the seed gets wiped from memory.
Thoughts?

Also wondering if people would want this option in the SeedOptionsView.

Still on the fence after giving this some consideration... but leaning towards "I like!"
I do like the choice of having seedsigner test me on important key material... but the passphrase is already visible as I'm entering it, and it's visible once again during finalization where I also get a chance to see my new fingerprint.  That fingerprint, as long as recognized, is good verification all but once in hundreds of millions... less good if only a fraction of it is recognized... personally, I want my attention on the fingerprint but others can have their preference too.  Since you propose the choice to skip passphrase verification, I cannot see how it hurts, while I do recognize how it can be helpful.
I do see a bug... Not in your implementation @EverydayBitcoiner, but rather in the current flow of adding a passphrase.  I'll define it as "User should be able to enter an empty passphrase." which means they effectively are NOT adding a passphrase at all.  This minor bug is not harmful in any way, it's just clunky.  If you go to add a passphrase and then edit the passphrase to delete all chars, you cannot get back to the seed finalization step without a passphrase... whereas it's my opinion that user should be able to back all the way out and finalize the seed without it... it feels like being stuck in a loop.

One thing that I did not implement in this flow that I think may be useful is a max number of attempts at passphrase verification (like 10 or something) before the seed gets wiped from memory.

I'm not sure I understand this one.  I think that for the rightful owner, there is no harm for them to test themselves as much as they want... until they get it right.  For an attacker, they'll choose to step around this and go straight to automated brute-force attack, assuming the wrench was persuasive in getting seedqr/words AND that the fool swinging didn't realize that they might need a passphrase too.

Also wondering if people would want this option in the SeedOptionsView.
Since I'm still on the fence, but only because of my own personal preferences, I can imagine others who want this would want this:

primarily when creating a new seed.
otherwise only during seed-backup... but then again, why the need to test the passphrase after you already loaded the seed?

I've already expressed my concerns (in my naturally redundant nature) that seedsigner is dangerously "leaky" in regards to seed-backup being available everytime we load a seed... and no way to disable it;  but this concern is already solved for this particular user.  I'll continue to rehash my concern about this anytime it rears it's ugly head, and others can continue to ignore it at their risk and at their own peril.

I do like the choice of having seedsigner test me on important key material... but the passphrase is already visible as I'm entering it, and it's visible once again during finalization where I also get a chance to see my new fingerprint. That fingerprint, as long as recognized, is good verification all but once in hundreds of millions... less good if only a fraction of it is recognized... personally, I want my attention on the fingerprint but others can have their preference too.

Yeah while SeedSigner does give you options to see and view the passphrase during the input process I generaly like to double check important passwords/passphrases by reentering them from my backup (whatever form that may be). I agree that the fingerprint is extremely useful for identification, but that doesn't help me know if my backed up passphrase is right until the next time I load my seed and then I'm in trouble if I wrote it down wrong.

I do see a bug... Not in your implementation @EverydayBitcoiner, but rather in the current flow of adding a passphrase.

I didn't notice that. I'll have to take a look.

I'm not sure I understand this one. I think that for the rightful owner, there is no harm for them to test themselves as much as they want... until they get it right. For an attacker, they'll choose to step around this and go straight to automated brute-force attack, assuming the wrench was persuasive in getting seedqr/words AND that the fool swinging didn't realize that they might need a passphrase too.

You may be right, I was just trying to think through precautions and this may not be it (see below for some additional thoughts you evoked about precautions).

I've already expressed my concerns (in my naturally redundant nature) that seedsigner is dangerously "leaky" in regards to seed-backup being available everytime we load a seed... and no way to disable it; but this concern is already solved for this particular user. I'll continue to rehash my concern about this anytime it rears it's ugly head, and others can continue to ignore it at their risk and at their own peril

This is an interesting point. I'm guessing you are partially referring to your Prudently Paranoid issue #273, which I just went back and reread the comments on. My current thoughts as I've mulled over this is that it may be good to have the backup option only available right when you load/create a seed. You could have an option in the SeedOptionsMenu to verify backup (pick correct words, enter passphrase).
@kdmukai makes an good point about not relying on the UI Settings for security (https://github.com/SeedSigner/seedsigner/issues/273#issuecomment-1354739417) and that the seed backup used to load the seed is an equivalent or greater risk, which I will concede. That said, security "leak" points could be reduced with UI Settings. A UI layer of security may not be ironclad, but it could it could certainly thwart or prevent more basic attacks or security leaks.
I am guessing that @kdmukai does not want to lead users to believe that the in-memory seeds are secure simply because they cannot be accessed via the GUI which is a valid concern, but I'm currently inclined towards shifting how we treat seed words to be similar to how we treat passphrases (https://github.com/SeedSigner/seedsigner/issues/90#issuecomment-913780378) where you get to see them and make sure you backed them up (i.e. go through the backup process) at the very start, but are then unavailable to view after that.

This is an interesting point. I'm guessing you are partially referring to your Prudently Paranoid issue https://github.com/SeedSigner/seedsigner/issues/273, which I just went back and reread the comments on. My current thoughts as I've mulled over this is that it may be good to have the backup option only available right when you load/create a seed. You could have an option in the SeedOptionsMenu to verify backup (pick correct words, enter passphrase).

Right!  I get that it could motivate bad habits to rely on a "settings" parameter... but from another perspective, ability to get to seed backup, or even to access utxos via address explorer or xpub is an exceptional one-time feature that may not be wanted under normal circumstances... AND there is no way to turn these features off, even if these concerns are primary to a user's threat model.  My prudently paranoid settings use-case example was a hyperbolic "what if" scenario that is likely bad practice... but I still think it could be deemed sound in some cases... and who is anyone to define another's security/threat model?
I can be more redundant, this time with questions.
Does seedsigner support single-sig?
Does seedsigner support m of n multisig where m is 1?
Does there exist seedsigner dads who might have untrust-worthy wives?  or teenagers who might let the wrong friend into the house?
If I've scanned my seedqr then locked it up in a hidden safe, must I strap my seedsigner to my arm so that power is pulled as my corpse hits the ground... or can I simply lock it up and relax, and be distracted when my wife calls me to the other room with gun to her head, or when the phone rings and I have to step away from my desk?  Can I have hope that the special agent in charge must consider the possibility of uncertainty that they'll get my seedsigner with loaded seed even if they never find the right combination of xor seeds among the many they'll find... so that when they sit me down they are motivated to negotiate with me instead of getting to see all my cards for free thanks to seedsigner?  Can I have some hope to motivate my attacker to keep me alive and conscious... or even that I might entice them to become part of my new security detail?  The answer to all of this is NO... seedsigner will leak whatever info it knows as long as it's still powered on.  It's an invite to attack me via surprise... I'd rather they consider the possibility that I'm taking it all to my grave, so they keep me alive, and so that I can take them on a tour of people and places that will make their attack much more costly.
All of this is a non issue if I just use an m of n multisig where m is greater than 1... but seedsigner allows less than this best practice, and even allows me to load multiple seeds... but not to protect it's own interface from leaking them if surprised.

but from another perspective, ability to get to seed backup, or even to access utxos via address explorer or xpub is an exceptional one-time feature that may not be wanted under normal circumstances

I think this all depends on the user so it's hard to say what is exceptional and what is normal.

AND there is no way to turn these features off, even if these concerns are primary to a user's threat model.

I'm on board with you here though I do understand @kdmukai's concern about not giving users a false sense of security using UI settings. I do think however that UI settings, while not perfect, can improve security incrementally.

If I've scanned my seedqr then locked it up in a hidden safe, must I strap my seedsigner to my arm so that power is pulled as my corpse hits the ground... or can I simply lock it up and relax

While your seedsigner may be "locked" it is not immune to compromise, but if something cannot be access via the GUI it is inherently more secure than a raw seed. That said, I think that as a best practice users should generally treat and protect their loaded seedsigner as if it was their raw seed.

seedsigner will leak whatever info it knows as long as it's still powered on.

Not totally true as the passphrase in unavailable through the UI.

Not totally true as the passphrase in unavailable through the UI.

I agree with you on this.   But since the master hdkey is on the running seedsigner, we can export xpub for new coordinator and sign for those utxos.

I do see a bug... Not in your implementation @EverydayBitcoiner, but rather in the current flow of adding a passphrase. I'll define it as "User should be able to enter an empty passphrase." which means they effectively are NOT adding a passphrase at all. This minor bug is not harmful in any way, it's just clunky. If you go to add a passphrase and then edit the passphrase to delete all chars, you cannot get back to the seed finalization step without a passphrase... whereas it's my opinion that user should be able to back all the way out and finalize the seed without it... it feels like being stuck in a loop.

I think the best bugfix here would be to allow an empty passphrase. However, some minor stupid danger in distinguishing an empty passphrase from one that just consists of invisible space(s).
Maybe in the empty case, the onscreen messaging can be different. Literally: "No passphrase specified" or something like that. And maybe below that: "Fingerprint remains: abcd1234".
This is probably all too wordy, but you get the idea.
@jdlcdl, can you log this as a separate issue and maybe tackle the fix?

@EverydayBitcoiner I'm not convinced that we need another opportunity to verify the passphrase.
However, I do think it's awkward to go through the backup process for a seed that we know was loaded with a passphrase. At the very least a warning at the start of the backup process should point out that the current fingerprint (result of seed + passphrase) is different from the "naked" seed that's about to be backed up.
A whole side discussion can be had about the wisdom of writing down just the "naked" seed's fingerprint on your backup or if it should reference instead/also the seed+passphrase's fingerprint.

but I'm currently inclined towards shifting how we treat seed words to be similar to how we treat passphrases (#90 (comment)) where you get to see them and make sure you backed them up (i.e. go through the backup process) at the very start, but are then unavailable to view after that.

That seems the most reasonable/consistent approach. The only thing really giving me pause is that the UI just doesn't have room. We'd be adding "Back up seed" alongside "Finalize seed". Having three menu options is somehow exponentially more  confusing than simply choosing between two options. And adding an additional step ("Backup? Or continue?") is a big no; loading a seed needs to remain as streamlined as possible.

@EverydayBitcoiner I'm not convinced that we need another opportunity to verify the passphrase.

I did this mainly because there is some additional verification that comes from actually reentering the passphrase from wherever it is stored (paper, password manager, etc.). This is more thorough and IMO better than simply visually comparing my stored passphrase with the passphrase on the SeedSigner screen. I know that I can often make simple mistakes visually comparing things and the additional step of optionally entering the passphrase from the backup to ensure it was not accidentally written down wrong ensures the integrity of the passphrase better than any other way.

However, I do think it's awkward to go through the backup process for a seed that we know was loaded with a passphrase. At the very least a warning at the start of the backup process should point out that the current fingerprint (result of seed + passphrase) is different from the "naked" seed that's about to be backed up.

Yes, this one of the things that I thought about. Currently I could see someone thinking they backed up the whole thing and not know they are missing the passphrase.

A whole side discussion can be had about the wisdom of writing down just the "naked" seed's fingerprint on your backup or if it should reference instead/also the seed+passphrase's fingerprint.

I was thinking about this and trying to figure out what the best option is. If the fingerprint stored with the backup is not the naked fingerprint it would give a potential adversary the information that there is a passphrase while the naked fingerprint would not. As you say, this is a whole different discussion.

That seems the most reasonable/consistent approach. The only thing really giving me pause is that the UI just doesn't have room. We'd be adding "Back up seed" alongside "Finalize seed". Having three menu options is somehow exponentially more confusing than simply choosing between two options. And adding an additional step ("Backup? Or continue?") is a big no; loading a seed needs to remain as streamlined as possible.

This could just be a differentiation between loading a seed vs. creating a seed. Most of my concerns here would generally be during the creation and backup of a new seed. When you load a seed (enter words, scan QR code) I don't know if there should be a backup option available (only scenario I can think of where that could be useful is if you only have a QR and want the words or have the words and want the QR -> this could maybe be an option in tools). I think maybe the creation and backup of a seed should be a single flow (gonna have to be careful here though to not confuse users given that the status quo is that you can backup a key anytime).

@jdlcdl, can you log this as a separate issue and maybe tackle the fix?

Yes @kdmukai.  I will give this a look with fresh eyes in the morning.

Lots of great discussion and possible next steps above, but specifically for the change offered here, concept NACK.
Backing up your naked seed / mnemonic is just a conceptually different activity from entering and verifying potentially many different bip39 passphrases for that one mnemonic. This PR's flow suggests / potentially misleads the user into thinking that the backup represents or only works for the currently-loaded mnemonic+passphrase combo.
Recommend this PR be closed, BUT very interested in pursuing some of the side changes discussed along the way.


textarea dark on mac

The Badge textarea is rendered as white text on black background on mac, iphone, ipad. It should be black text on white background for consistency across platforms.

fixed in e30f3ddb34bfc54a65c636a16c4183cb0f9233e7 on mac
? on iphone
? on ipad


Support itk.Image use in Dask Array map_blocks

To avoid explicit type coersion in Dask Array map_blocks, consider adding

[x] dtype
[x] shape
[x] ndim
[ ] __array_function__

to itk.Image.
@jakirkham @mrocklin

ndim, dtype, shape added in #1780

Nice! Thanks for the update Matt 😄

Woot.  Have we tried this out in a workflow yet?  If not, it might be fun
to try something and throw it into a "Better ITK and Dask Integration"
blogpost.
On Wed, Apr 22, 2020 at 8:40 PM jakirkham<EMAIL_ADDRESS>wrote:

Nice! Thanks for the update Matt 😄
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/InsightSoftwareConsortium/ITK/issues/1091#issuecomment-618158352,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AACKZTGLLS3TBULKKDHCHJ3RN62CXANCNFSM4IDR56VQ
.

@mrocklin great idea -- I'll see about following up on our initial post with some denoising...

Is this something I can help along?

Hi @GenevieveBuckley,
Help on this would be amazing! :pray:
We need to add pickle support to itk.Image.
The process may be a great example basis for a Dask Blog post on how to add required pickle support for data structures from native Python packages.
We need to get this test to pass:
import itk
import pickle
import numpy as np

# Create an itk.Image
array = np.random.randint(0, 256, (8, 12)).astype(np.uint8)
image = itk.image_from_array(array)
image.SetSpacing([1.0, 2.0])
image.SetOrigin([11.0, 4.0])
theta = np.radians(30)
cosine = np.cos(theta)
sine = np.sin(theta)
rotation = np.array(((cosine, -sine), (sine, cosine)))
image.SetDirection(rotation)

# Verify serialization works with a np.ndarray
serialized = pickle.dumps(array)
deserialized = pickle.loads(serialized)
assert np.array_equal(array, deserialized)

# How to check for image consistency
image_copy = itk.image_duplicator(image)
compared = itk.comparison_image_filter(image, image_copy)
assert np.sum(compared) == 0

# We need to add support for this
serialized = pickle.dumps(image)
deserialized = pickle.loads(serialized)
compared = itk.comparison_image_filter(image, deserialized)
assert np.sum(compared) == 0

As first step, I would create a conda environment, pip install itk and hack on site-packages/itk/itkImagePython.py to work out the details that make the test pass -- this is a generated file. The class to add the required dunder methods in that file for this test is class itkImageUC2. The pickle process in Python is a bit complex. I found that the CPython docs helpful but stepping through the code with pdb was also required for my understanding.
We need to def __getstate__, def __setstate__, and likely __reduce_ex__.
Here is what we did for the itk module: https://github.com/InsightSoftwareConsortium/ITK/blob/27f26685cc10be8bee74989a1c03639cd89705ce/Wrapping/Generators/Python/itk/support/lazy.py#L145-L174
To get the state, here is an example that represents the itk.Image state as a Python Dictionary of fundamental types + a np.ndarray (which has pickle support): https://github.com/InsightSoftwareConsortium/itkwidgets/blob/c4f3b158719bbb2720ef2fadcc3df8990a3feb95/itkwidgets/trait_types.py#L163-L172.
For re-constructing the image, it will require:
image = itk.image_view_from_array(state.pixel_array, ttype=state.imageType)
image.SetOrigin(state.origin)
image.SetSpacing(state.spacing)
image.SetDirection(state.direction)

There's also some discussion about improving pickle in ITK in issue ( https://github.com/InsightSoftwareConsortium/ITK/issues/1948 )

So I think I'm almost there.
Approach
Reusing the itkimage_to_json & itkimage_from_json functions, from the link Matt gave here seems like the best approach.

Details:

def _image_to_type(itkimage):  # noqa: C901
    component = itk.template(itkimage)[1][0]
    if component == itk.UL:
        if os.name == 'nt':
            return 'uint32_t', 1
        else:
            return 'uint64_t', 1
    mangle = None
    pixelType = 1
    if component == itk.SL:
        if os.name == 'nt':
            return 'int32_t', 1,
        else:
            return 'int64_t', 1,
    if component in (itk.SC, itk.UC, itk.SS, itk.US, itk.SI, itk.UI, itk.F,
            itk.D, itk.B):
        mangle = component
    elif component in [i[1] for i in itk.Vector.items()]:
        mangle = itk.template(component)[1][0]
        pixelType = 5
    elif component == itk.complex[itk.F]:
        # complex float
        return 'float', 10
    elif component == itk.complex[itk.D]:
        # complex float
        return 'double', 10
    elif component in [i[1] for i in itk.CovariantVector.items()]:
        # CovariantVector
        mangle = itk.template(component)[1][0]
        pixelType = 7
    elif component in [i[1] for i in itk.Offset.items()]:
        # Offset
        return 'int64_t', 4
    elif component in [i[1] for i in itk.FixedArray.items()]:
        # FixedArray
        mangle = itk.template(component)[1][0]
        pixelType = 11
    elif component in [i[1] for i in itk.RGBAPixel.items()]:
        # RGBA
        mangle = itk.template(component)[1][0]
        pixelType = 3
    elif component in [i[1] for i in itk.RGBPixel.items()]:
        # RGB
        mangle = itk.template(component)[1][0]
        pixelType = 2
    elif component in [i[1] for i in itk.SymmetricSecondRankTensor.items()]:
        # SymmetricSecondRankTensor
        mangle = itk.template(component)[1][0]
        pixelType = 8
    else:
        raise RuntimeError('Unrecognized component type: {0}'.format(str(component)))
    _python_to_js = {
        itk.SC: 'int8_t',
        itk.UC: 'uint8_t',
        itk.SS: 'int16_t',
        itk.US: 'uint16_t',
        itk.SI: 'int32_t',
        itk.UI: 'uint32_t',
        itk.F: 'float',
        itk.D: 'double',
        itk.B: 'uint8_t'
    }
    return _python_to_js[mangle], pixelType

def itkimage_to_json(itkimage, manager=None):
    """Serialize a Python itk.Image object.
    Attributes of this dictionary are to be passed to the JavaScript itkimage
    constructor.
    """
    if itkimage is None:
        return None
    else:
        direction = itkimage.GetDirection()
        directionMatrix = direction.GetVnlMatrix()
        directionList = []
        dimension = itkimage.GetImageDimension()
        pixel_arr = itk.array_view_from_image(itkimage)
        componentType, pixelType = _image_to_type(itkimage)
        if 'int64' in componentType:
            # JavaScript does not yet support 64-bit integers well
            if componentType == 'uint64_t':
                pixel_arr = pixel_arr.astype(np.uint32)
                componentType = 'uint32_t'
            else:
                pixel_arr = pixel_arr.astype(np.int32)
                componentType = 'int32_t'
        compressor = zstd.ZstdCompressor(level=3)
        compressed = compressor.compress(pixel_arr.data)
        pixel_arr_compressed = memoryview(compressed)
        for col in range(dimension):
            for row in range(dimension):
                directionList.append(directionMatrix.get(row, col))
        imageType = dict(
            dimension=dimension,
            componentType=componentType,
            pixelType=pixelType,
            components=itkimage.GetNumberOfComponentsPerPixel()
        )
        return dict(
            imageType=imageType,
            origin=tuple(itkimage.GetOrigin()),
            spacing=tuple(itkimage.GetSpacing()),
            size=tuple(itkimage.GetBufferedRegion().GetSize()),
            direction={'data': directionList,
                       'rows': dimension,
                       'columns': dimension},
            compressedData=compressed
        )

def _type_to_image(jstype):
    _pixelType_to_prefix = {
        1: '',
        2: 'RGB',
        3: 'RGBA',
        4: 'O',
        5: 'V',
        7: 'CV',
        8: 'SSRT',
        11: 'FA'
    }
    pixelType = jstype['pixelType']
    dimension = jstype['dimension']
    if pixelType == 10:
        if jstype['componentType'] == 'float':
            return itk.Image[itk.complex, itk.F], np.float32
        else:
            return itk.Image[itk.complex, itk.D], np.float64

    def _long_type():
        if os.name == 'nt':
            return 'LL'
        else:
            return 'L'
    prefix = _pixelType_to_prefix[pixelType]
    _js_to_python = {
        'int8_t': 'SC',
        'uint8_t': 'UC',
        'int16_t': 'SS',
        'uint16_t': 'US',
        'int32_t': 'SI',
        'uint32_t': 'UI',
        'int64_t': 'S' + _long_type(),
        'uint64_t': 'U' + _long_type(),
        'float': 'F',
        'double': 'D'
    }
    _js_to_numpy_dtype = {
        'int8_t': np.int8,
        'uint8_t': np.uint8,
        'int16_t': np.int16,
        'uint16_t': np.uint16,
        'int32_t': np.int32,
        'uint32_t': np.uint32,
        'int64_t': np.int64,
        'uint64_t': np.uint64,
        'float': np.float32,
        'double': np.float64
    }
    dtype = _js_to_numpy_dtype[jstype['componentType']]
    if pixelType != 4:
        prefix += _js_to_python[jstype['componentType']]
    if pixelType not in (1, 2, 3, 10):
        prefix += str(dimension)
    prefix += str(dimension)
    return getattr(itk.Image, prefix), dtype

def itkimage_from_json(js, manager=None):
    """Deserialize a Javascript itk.js Image object."""
    if js is None:
        return None
    else:
        ImageType, dtype = _type_to_image(js['imageType'])
        decompressor = zstd.ZstdDecompressor()
        if six.PY2:
            asBytes = js['compressedData'].tobytes()
            pixelBufferArrayCompressed = np.frombuffer(asBytes, dtype=np.uint8)
        else:
            pixelBufferArrayCompressed = np.frombuffer(js['compressedData'],
                                                    dtype=np.uint8)
        pixelCount = reduce(lambda x, y: x * y, js['size'], 1)
        numberOfBytes = pixelCount * \
            js['imageType']['components'] * np.dtype(dtype).itemsize
        pixelBufferArray = \
            np.frombuffer(decompressor.decompress(pixelBufferArrayCompressed,
                                                numberOfBytes),
                        dtype=dtype)
        pixelBufferArray.shape = js['size'][::-1]
        # Workaround for GetImageFromArray required until 5.0.1
        # and https://github.com/numpy/numpy/pull/11739
        pixelBufferArrayCopyToBeRemoved = pixelBufferArray.copy()
        # image = itk.PyBuffer[ImageType].GetImageFromArray(pixelBufferArray)
        image = itk.PyBuffer[ImageType].GetImageFromArray(
            pixelBufferArrayCopyToBeRemoved)
        Dimension = image.GetImageDimension()
        image.SetOrigin(js['origin'])
        image.SetSpacing(js['spacing'])
        direction = image.GetDirection()
        directionMatrix = direction.GetVnlMatrix()
        directionJs = js['direction']['data']
        for col in range(Dimension):
            for row in range(Dimension):
                directionMatrix.put(
                    row, col, directionJs[col + row * Dimension])
        return image

... then it looks like all we need is to add __getstate__ and setstate` methods like this:
    # For pickle support
    def __getstate__(self):
        state = itkimage_to_json(self)
        return state

    # For pickle support
    def __setstate__(self, state):
        deserialized = itkimage_from_json(state)
        self.__dict__['this'] = deserialized
        self.SetOrigin(state['origin'])
        self.SetSpacing(state['spacing'])

        # FIXME! Something is not quite right about the way I'm setting the direction here
        # ref https://discourse.itk.org/t/set-image-direction-from-numpy-array/844
        direction_data = np.reshape(state['direction']['data'], (state['direction']['rows'], state['direction']['columns']))
        direction_data_vnl = itk.GetVnlMatrixFromArray(direction_data)
        direction = self.GetDirection()
        direction.GetVnlMatrix().copy_in(direction_data_vnl.data_block())
        self.SetDirection(direction)

Results
When I run the example test script the itk.comparison_image_filter function fails, I think because the array direction isn't being set correctly.

Details:
RuntimeError: /work/ITK-source/ITK/Modules/Core/Common/include/itkImageToImageFilter.hxx:219:
ITK ERROR: ComparisonImageFilter(0x55928d0ed180): Inputs do not occupy the same physical space!
InputImage Direction: 1.0000000e+00 0.0000000e+00
0.0000000e+00 1.0000000e+00
, InputImageValidInput Direction: 8.6602540e-01 -5.0000000e-01
5.0000000e-01 8.6602540e-01

	Tolerance: 1.0000000e-06

The line assert np.sum(compared) == 0 does pass, which I'm hoping means the actual image array values are all correct. I'm not very familiar with itk objects.
Questions

What am I doing wrong with setting the direction? I tried to use @thewtex 's answer to this question as a model, but what I've got isn't working to actually overwrite the direction.
Where should these changes live? I've been hacking on the auto-generated python file as suggested, but I take it there's another process. (I've hacked the new __getstate__ and __setstate__ methods onto the itkImageUC2 class, because that's the specific array type generated in the example test script)

Excellent, I've opened a PR over at https://github.com/InsightSoftwareConsortium/ITK/pull/2829, and outlined what the next steps are here.


Confusing error for - in wildchild name.

rules.yaml:
schema:
  type: object
  additionalProperties: false
  $foo-bar:
    type: string
    constraint: $foo-bar.matches(/regex/)

blaze rules.yaml yields:

Error: Bug: 3 Unexpected situation in type system undefined undefined
at falafel_visitor (/home/jyasskin/opt/nodejs/lib/node_modules/blaze_compiler/src/expression.ts:342:167)
at walk (/home/jyasskin/opt/nodejs/lib/node_modules/blaze_compiler/node_modules/falafel/index.js:60:9)
at /home/jyasskin/opt/nodejs/lib/node_modules/blaze_compiler/node_modules/falafel/index.js:57:17
at Array.forEach (native)
at forEach (/home/jyasskin/opt/nodejs/lib/node_modules/blaze_compiler/node_modules/falafel/index.js:8:31)
at walk (/home/jyasskin/opt/nodejs/lib/node_modules/blaze_compiler/node_modules/falafel/index.js:44:9)
at /home/jyasskin/opt/nodejs/lib/node_modules/blaze_compiler/node_modules/falafel/index.js:57:17
at Array.forEach (native)
at forEach (/home/jyasskin/opt/nodejs/lib/node_modules/blaze_compiler/node_modules/falafel/index.js:8:31)
at walk (/home/jyasskin/opt/nodejs/lib/node_modules/blaze_compiler/node_modules/falafel/index.js:44:9)

Yeah thats an interesting inconsistency between valid javascript identifiers and YAML keys. I am not going to fix this as there are probably lots of inconsistencies like this and solving them all would require more time than is worth investing at this stage. But thanks for bringing it up, I'll make a note of it. Its something that should be fixed at some point.


Without reading the titles is hard to tell if the caption belongs to the top picture or the bottom picture

Admit it, without seeing the word "cloud" in the title, one would not be able to tell if the caption belons to the top picture or the bottom picture. Therefore a thick horizontal line is needed above each picture!

I don't know if a thick horizontal line is the way to go, but you have a point. I wonder how other photo browsing apps handle this.

If we look at the explore tab in dark theme we can notice the cards because of slight color difference in the background and card information. And as the contributions fragment background in dark theme has the same color as the card info, it is not visible.
So, I think we can extend this to contribution fragment and light theme by have a slight different/dark color for the card info.
@misaochan ?

@4D17Y4 Sorry for the slow response, I missed your ping! Yes, this sounds like a good idea. :) Would it be possible for you to show some mockups on how the contributions fragment would look in light theme and dark theme, with these changes?

Thanks @4D17Y4 , the mockups look good to me! Pinging @neslihanturan for her input as well. If she approves it, feel free to work on this if you want to. :)

Light theme ( Notable difference in Android screen due to resolution )
Current | Changed

"Changed" looks good for Light Theme, but for Dark theme, one cannot tell if the words belong to the top or bottom picture.

Maybe
^ Sunset
or
↑ Sunset
would even be better, for poor vision people too.


React OWIN article to ASP.NET Core rename

Hi @MaherJendoubi, I'm your friendly neighborhood .NET Foundation Pull Request Bot (You can call me DNFBOT). Thanks for your contribution!

This seems like a small (but important) contribution, so no Contribution License Agreement is required at this point. Real humans will now evaluate your PR.

TTYL, DNFBOT;

@MaherJendoubi Thank you for this contribution! Please note that we are waiting to roll out the ASP.NET Core rename in our docs until we have shipped updated bits with the new names (see https://blogs.msdn.microsoft.com/webdev/2016/02/01/an-update-on-asp-net-core-and-net-core/). We are staging all of the rename work in our dev branch. Could you please update this PR to be based on dev?

Hi @MaherJendoubi, I'm your friendly neighborhood .NET Foundation Pull Request Bot (You can call me DNFBOT). Thanks for your contribution!

This seems like a small (but important) contribution, so no Contribution License Agreement is required at this point. Real humans will now evaluate your PR.

TTYL, DNFBOT;

@danroth27 done.

@MaherJendoubi I don't see a new commit on this PR and it's still based on master. Did you forget to push?

@danroth27 Is it Ok now? https://github.com/aspnet/Docs/pull/979

@danroth27 do you see please my PR on dev branch?

@MaherJendoubi Yup, that's why I closed this one.


Optional input validation of orchestrator.conf.json

I noticed some configuration settings in my /etc/orchestrator.conf.json were no longer valid. Orchestrator reads in the file and does not indicate there's an issue of any sort.
While I'm happy with lazy evaluation and also potentially having invalid settings in the config file it would be most helpful I think to be able to identify such invalid settings.  Two thoughts come to mind:
(A) command line "validate my config file" option
$ orchestrator -c check_validate_config_file
which would indicate if the config contents are good or not. Invalid JSON settings would generate an error.
(B): Optional setting to fail if the current config is invalid
Something like: "ValidateConfigSetting": true,
This is the setting I would prefer but of course setting it now would do nothing until the option is actually implemented, so I probably need to use a combination of both (A) and (B).
Anyway this issue is to simply reflect this potential problem. There are a large number of options that can be used in the config file, a type is quite easy to make, or simply code that is changing rapidly may leave a setting which is expected to do something to be invalid and be ignored rather than generate an error.

Good idea. What I'd suggest though it to allow a _ prefixed variable as "silently ignore".
So, for example:
{
  "NoSuchParam": 7,
  "_NoSuchParam": 8
}

The first would yield error, the 2nd wouldn't.

Is there a good reason to not make parameter validation mandatory? I think it is always easy to run new code against old config and correct all inconsistencies before deployment.
Over a couple years we've accumulated quite some mistakes due to code change and human mistakes.
2017/03/07 15:51:55 Unexpected config option 'ActiveNodeNotificationProcesses' in file /etc/orchestrator.conf.json
2017/03/07 15:51:55 Unexpected config option 'BackendDBConcurrency' in file /etc/orchestrator.conf.json
2017/03/07 15:51:55 Unexpected config option 'DenyAutoPromotionHostnamePattern' in file /etc/orchestrator.conf.json
2017/03/07 15:51:55 Unexpected config option 'DiscoveryConcurrencyLoggingPeriod' in file /etc/orchestrator.conf.json
2017/03/07 15:51:55 Unexpected config option 'DiscoveryPollSeconds' in file /etc/orchestrator.conf.json
2017/03/07 15:51:55 Unexpected config option 'HostnameSuffixSanityHint' in file /etc/orchestrator.conf.json
2017/03/07 15:51:55 Unexpected config option 'IgnoreUnreachableMasterWithStaleSlaves' in file /etc/orchestrator.conf.json
2017/03/07 15:51:55 Unexpected config option 'MySQLDiscoveryReadTimeoutSeconds:' in file /etc/orchestrator.conf.json
2017/03/07 15:51:55 Unexpected config option 'MySQLTopologyReadTimeoutSeconds:' in file /etc/orchestrator.conf.json

Validation above was done with https://github.com/orkestrov/orchestrator/commit/782f75a998cd8e082085f84c7b4fa01a846f0f73.

@orkestrov please see my comment: https://github.com/github/orchestrator/issues/82#issuecomment-281379394
As long as you silently allow _ prefix, I agree with mandatory validation.

Cool.  I don't like that much.
Have been discussing with @orkestrov about this.  I think that in most cases you do want to fail when there's an error in the config and not let it go unnoticed.
I'm partly of the opinion that we should fail hard if the config is wrong. Let's see if / where this causes issues (mainly on downgrades I think) and if so provide a non-fatal behaviour if the config parameters are not good.  ???


[Feature Request] Minor: Allow user to submit credentials on return/enter press on keyboard

Opportunity for smoother login flow
After entering both email and password into the login form, user must either manually click "Sign In" button, or hit tab 3 times on keyboard and then enter to submit credentials.
Suggested solution
For convenience and usability purposes, most sites allow users to hit return/enter immediately once credentials are entered to submit the form.

Can you assign this to me as well please?

Ok @vktr-r2. Assigned.

PR 176 closes this issue.


Hey, I want to add automatic PC shutdown script.  Please assign this to me.

Script Title - Automatic Shutdown
Brief -
Automatic shutdown after x time.
Instructions

Create a new folder for your script and file/folder name should be appropriate.
Create a README.md (using this template) in your folder for program Instructions
add requirements.txt if needed

Programming Language

[x] Python

Happy Coding

Hey I would like to work on this issue. It would be nice if you can assign this to me...

Hi
I would like to contribute if its still available :)


Adds python .venv to gitignore

Thanks for the PR. These files belong in a global .gitignore file, not in a project-specific file. This helps keep our repo .gitignore filled with only the ignores that are needed for the project. Thanks again!


systemd fails to install with SIGABRT

Issue description
I have a nix setup running on a CentOS system with the store on an NFS share in a custom location (/share/nix) without root access.
I cannot rely on Hydra's cache so everything is recompiled.
In order to try to workaround a problem with one package failing I was recommended to use vmTools.runInLinuxVM.
As part of deriving this I currently get a SIGABRT causing systemd to fail to install:
...
installing zh_TW.gmo as /share/nix/store/y9h79i1ar78lp0im0xmva5z308h1lw88-systemd-232-lib/share/locale/zh_TW/LC_MESSAGES/systemd.mo
CC       i915_state.lo
CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/clk/pllgt215.o
CC       i915_state_derived.lo
CC       i915_state_dynamic.lo
CC       i915_state_emit.lo
CC       i915_state_fpc.lo
CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/devinit/base.o
CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/devinit/nv04.o
/share/nix/store/vhbka04yq2h4whzxq179d77k293kx27m-stdenv/setup: line 98:  5606 Aborted                 find $out -name "*kernel-install*" -exec rm {} \;
builder for ‘/share/nix/store/nbjw08k00wx4lgf1s3vp6p7bvivdqay6-systemd-232.drv’ failed with exit code 134
cannot build derivation ‘/share/nix/store/m8svh2nrm8n11l218l71lffylfyjwjxd-dbus-1.10.14.drv’: 1 dependencies couldn't be built
cannot build derivation ‘/share/nix/store/zy5x6r2fcfx9shj9s0v38kq92p671ql4-libusb-1.0.20.drv’: 1 dependencies couldn't be built
cannot build derivation ‘/share/nix/store/6447bh8ibs1l5v7w7hhsim5fg8vls62q-util-linux-2.29.drv’: 1 dependencies couldn't be built
cannot build derivation ‘/share/nix/store/4vy52mq3si93qksxqqgrsriyyjxz89zq-libpulseaudio-10.0.drv’: 1 dependencies couldn't be built
killing process 15556
cannot build derivation ‘/share/nix/store/7frjz79sp6gyv2qq80pagjpnix8c8i3b-usbredir-0.7.1.drv’: 1 dependencies couldn't be built
cannot build derivation ‘/share/nix/store/nfxcbq5mwf5nx2j85w4id0kjxpnsa1y7-vm-run-stage2.drv’: 1 dependencies couldn't be built
killing process 14862
cannot build derivation ‘/share/nix/store/3zb3l5v3vs5mnsy2d3a6xn3bqr4a2shk-vm-run.drv’: 1 dependencies couldn't be built
cannot build derivation ‘/share/nix/store/45bikfynqajbpsa13ab7s764d47zax20-hello-2.10.drv’: 1 dependencies couldn't be built
error: build of ‘/share/nix/store/45bikfynqajbpsa13ab7s764d47zax20-hello-2.10.drv’ failed

This currently fails on both stable and unstable channels (versions below).
Steps to reproduce
nix-repl
nix-repl> :l <nixos>
nix-repl> :b vmTools.runInLinuxVM hello

Technical details

System: CentOS 6.5
Nix version: nix-env (Nix) 1.11.6
Nixpkgs version: 16.09.1650.d2cd8a0 and 17.03pre100557.3e7dffd

Are you using nested hardware virtualization by any chance?

No nested virtualization.

Are there any updates to this issue, please?

It has been a while and I haven't been able to replicate. Closing as obsolete.