Rbf last argument of constructor

would there be any advantage to allow the first n-1 arguments to be the same shape while the last argument only needs to have the same number of rows but could have multiple columns to represent multiple vectors of values or it is all the same to just create individual Rbf objects?  I have also found that the Rbf object is 2.7 mb for a grid 1530 points for 5 dimensions, thin_plate.  Trying to distribute 3000+ individual Rbf obejcts across 48 engines and the 2.7 mb is really cloging me up.  I end up having to recreate the Rbf object on the fly and discard it, but that is slower than i would like.  Any ohter suggestions on how I can optimize the process of interpolating  3000+ differnet objects?

Looks abandoned for more than five years. Let's close this. Thanks anyway, @marcus21283, Ralf.


Yields.Par errors on this combination of rates and tenors

rates = [0.057, 0.0755, 0.0837, 0.078, 0.1084, 0.0702, 0.1167]
tenors = [1,3,5,10,15,20,25]

closed with #116


[fix][test]Fix cannot resolve method addLast error

Motivation
Cannot resolve method 'addLast(java.lang.String, org.apache.pulsar.client.api.MockBrokerService.MockServerCnx)'
Modifications
Cast MockServerCnx to ChannelHandler
Documentation
Check the box below or label this PR directly.
Need to update docs?

[ ] doc-required
(Your PR needs to update docs and you will update later)

[x] no-need-doc
(Please explain why)

[ ] doc
(Your PR contains doc changes)

[ ] doc-added
(Docs have been already added)

I notice the Pulsar have many similar codes, could you fix these code?
It should be working, but the IDEA will tell us there are errror here.

I notice the Pulsar have many similar codes, could you fix these code?
It should be working, but the IDEA will tell us there are error here.

I only find one of this kind error.  @nodece

@nodece PTAL again, Thanks for pointing it out

I think it's a issue of Intellij Idea, there is no need to add a cast in code.

Clone the Pulsar repo to a new folder, then use the IDEA to open this new project, it is working.


Button disapeared/turns white when closing style editor

When selecting a button, opening the style editor and then closing it the button turns white.
Recreate problem:
-Place button
-Place object
-Select button
-Open style editor
-Close style editor

The style editor only supports text, maybe walv apply the wrong style for the button(see wrapper.js), code.push(${id}.set_style(lv.label.STYLE.MAIN,s))

Actually happens with any widget added on a screen.
They just become invisible.

Yes it seems to be that the ID is not passed on to the style editor.


Method 'registerUserResolver' doesn't exist

In the config file, under the User section it is stated:

... you can call the Bugsnag::registerUserResolver method from the boot method of your app service provider.

However, no such method exists. I can make a pull request with the changes to fix this if needed.

Please can you let us know the full class name of "Bugsnag" please?

It should be the facade, rather than the client.

Hmmm, this does look like a mistake in the docs actually.

Actually, I can't find anything in the docs that says that? https://docs.bugsnag.com/platforms/php/laravel/#identifying-users

Oh OK I see. i got confused for a second there. It's in the config file: https://github.com/bugsnag/bugsnag-laravel/blob/master/config/bugsnag.php#L212

Ah, I see now. Thanks for reporting. :)

Should I make a pull request or will you do the honors?

I'm working on one now, but feel free to send one also if you want. It might be better than mine. :)


Bugfix/1173/inotify api

Proposed changes

Types of changes

[ ] Bugfix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Improvement (general improvements like code refactoring that doesn't explicitly fix a bug or add any new functionality)
[ ] Documentation Update (if none of the other choices apply)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)

Paste Link to the issue

Checklist

[ ] I have read the CONTRIBUTING doc
[ ] I have signed the CLA (in all commits with git commit -s)
[ ] I ran cargo fmt as mentioned in CODING_GUIDELINES
[ ] I used cargo clippy as mentioned in CODING_GUIDELINES
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] I have added necessary documentation (if appropriate)

Further comments

Closing this PR. This contains deprecated code which is no longer relevant.


Unable to view properties of exported Rust structs

Describe the Bug
When exporting a struct from Rust to JavaScript, calling console.log or JSON.stringify on an object of the class shows only a ptr property and none of the exported struct's properties
Steps to Reproduce
I've created an example project at codehearts/whoops to reproduce the issue
Consider the following exported Rust struct:
#[wasm_bindgen]
pub struct Series {
    name: String
}

#[wasm_bindgen]
impl Series {
    #[wasm_bindgen(js_name=okKo)]
    pub fn ok_ko() -> Self {
        Self {
            name: "OK K.O.! Let's Be Heroes".to_string(),
        }
    }

    #[wasm_bindgen(getter)]
    pub fn name(&self) -> String {
        self.name.clone()
    }
}

In the output from wasm-pack build, the Series object has the following properties:
const series = Series.okKo();
console.log(series.name); // OK K.O.! Let's Be Heroes

However, when logging the object we see neither of these properties:
console.log(series); // Series { ptr: 1114136 }
console.log(JSON.parse(JSON.stringify(series))); // { ptr: 1114136 }

Expected Behavior
I would expect to see the name property exported from Rust, like how a native JavaScript class would look
Actual Behavior
The object shows only a ptr property, which is not useful for debugging or logging state
Additional Context
I found a solution that works for Node.js at least. The output of console.log can be customized by defining a [util.inspect.custom] method within the class, and the JSON.stringify result is based on an existing toJSON method if one is defined
wasm-bindgen would have to define the [util.inspect.custom] method because util is not imported by default and the brackets create an invalid symbol during compilation, but toJSON can be exported from the Rust
I'm wondering if wasm-bindgen should provide a default [util.inspect.custom], toJSON, and toString which provides the exported properties. Would these be appropriate methods for wasm-bindgen to include when targeting Node.js (and possible just JS for the JSON and string representations?)

Thanks for the report! I'd be somewhat wary to develop a node.js-specific solution here rather than a JS-general solution. Do you know if it's possible to fix this on the web as well? If not then this may fall within the category of "not fixable at this time" for now

@alexcrichton toJSON and toString are standard and work everywhere, so we can at least support those.
I do like this idea, but I'm a little concerned about code size: this will add a significant amount of code to every single class, and that code cannot be dead code eliminated.
So I'd prefer if this was behind an attribute or a feature or something like that. Or maybe it could be only enabled in debug mode, but that has some compat risks.

I do like the idea of placing these behind an attribute, my only reasoning to include them by default is that the JS objects would match the Rust structs when you log and inspect them. If the attribute is documented, thought I think it's fair that anyone picking up wasm-bindgen would see that caveat and be able to decide if they need it in their case
I'll try and make time to implement this behind a wasm_bindgen(inspect=true) attribute, generating the console inspection code only for the Node.js target (unfortunately, web doesn't seem to have anything equivalent to override output from console.log)

Instrumenting this as part of #[wasm_bindgen] sounds great to me!

I've been able to get this working, but I'm not happy with the implementation. The #[wasm_bindgen(inspectable)] attribute goes on the struct, so the macro on the impl can't know about it as far as I'm aware. I wanted to panic if the user defined toJSON or toString in that case, but it seems like this has to be done on the cli side (which I think would be an error that rsl/analyze couldn't report)
I also had to add some bookkeeping I'm not happy about. The cli code has to keep a vector of methods on the struct to check for toJSON and toString being defined by the user, and then another vector for getter names to generate exposed fields in the toJSON body. I tried generating toJSON as part of the macro processing, but it seemed difficult to generate a function that returns a js_sys::Object or which builds an object JsValue without serde or js_sys

I suspect it's probably fine to ignore the case where toJSON and/or toString is custom defined, and a struct annotation should likely be good enough for now? Adding more error handling and/or better diagnostics is fine to happen at a future date.


add methods to Extents.extent not GeoInterface.extent

This is the fallback for GeoInterface.extent now anyway, and it's confusing to have to use both packages.

The tests were failing with
  MethodError: no method matching extent(::Tile, ::MapTiles.WebMercator)

  Closest candidates are:
    extent(::GeoInterface.AbstractTrait, ::Any)
     @ GeoInterface C:\Users\visser_mn\.julia\packages\GeoInterface\JDGLc\src\fallbacks.jl:112
    extent(::Any; fallback)
     @ GeoInterface C:\Users\visser_mn\.julia\packages\GeoInterface\JDGLc\src\interface.jl:425

This is calling GeoInterface.extent, but doesn't get to the Extents.extent fallback since looking at https://github.com/JuliaGeo/GeoInterface.jl/pull/94 this only covers a single argument, and we added the extra crs argument here. I added c88b5b1882523633fa28641016ea06c19f2f1d10, @rafaqz do you think that is an acceptable workaround?

Ahh right thats annoying, guess the workaround is fine.
Having two extrnt methods is kind of a mess but we need it to stay separate to calculate geometry extents.


Linux port

The changes here allow running a sketch on Linux (rather than uploading it to an Arduino) and read some tags.
I tested DumpInfo and maybe one or two other sketches.
Since operating this card reader by writing random values to the SPI bus by hand proved unsuccessful so far this might be useful for other people trying to use the thing on Linux.
Two more complex sketches fail to build because I did not add code for some features in the Arduino environment emulation layer.
travis environment does not have sys/ioctl.h so all tests fail

hm, the travis environment does not have sys/ioctl.h

@hramrach Thanks. To merge this, travis has to be successful. Can you correct the the travis check?

Perhaps this is better kept in another project?  Since it seems to depart from the main "Arduino library for MFRC522 and other RFID RC522 based modules" goal.

Yes, that maybe the better solution. I think this library should be still for Arduino IDE only to avoid issues.
Many boards are supported by the Arduino IDE and they implement the Arduino specific functions.
So I think I close this pr and maybe add a link to this repo in the readme? @hramrach

Missing sys/ioctl.h can be only fixed on travis.
It's present on Linux systems which I target with this port.
This is not another project. it's port of this project to run on Linux.
I can understand that you may not want to merge the port since you are focused on Arduino.
Thanks

fwiw if you install libc6-dev in travis the build will probably work

hi guys im a student and new in this world, i have a doubt about this,  can it uses this with python interface on an intel galileo board?

There are no python bindings.
There is another project which targets Raspberry PI which is written in
Python. It uses broadcom-specific library for GPIO, however.

I believe it won't work. E.g in MFRC522::PCD_WriteRegister you wrote:
	for (byte index = 0; index < count; index++) {
		SPI.transfer(values[index]);
	}

Which means that after each SPI.transfer chip-select will goes off, and goes on in next SPI.transfer call. It does not meet writting multiple bytes to register algorithm (see <IP_ADDRESS> SPI write data).
However, it good start point to have working implementation on Linux:)

The thing is that it does NOT work when using the Linux API that triggers chipselect properly and it DOES work with this bastardized sketchy implementation. Maybe there is some undocumented 'feature' of the chip that the author of the Arduino library found by trial and error captured in this code.

The author of the Arduino library handles chipselect properly. In this implementation this is not properly handled, because chipselect is on only during ioctl call.
When it goes to writing values to registers, two bytes (address and value) have to be send without switching off the chipselect. In this implementation chipselect goes off and on between address and value bytes. The result is that, the value is not set in register.
Below the results of the simple demo, which I run right now with MFRC522 v2.0:
    // The right way of writing register
    write_register(spi, CommandReg, 0x00); // write with one ioctl
    read_register(spi, CommandReg); // returned value 0x00 (OK)
    write_register(spi, CommandReg, 0x20); // write with one ioctl
    read_register(spi, CommandReg); // returned value 0x20 (OK)
    write_register(spi, CommandReg, 0x00); // write with one ioctl - just for reset the value
    // The way of writing register in implementation from this pull request
    write_register(spi, CommandReg); // write with one ioctl - only address was sent
    write_register(spi, 0x20); // write with one ioctl - only value was sent
    read_register(spi, CommandReg); // returned value 0x00 (NOK) - should be 0x20

It shows that writting register with flapping chipselect does not work.
I just want to warn future users:)

yes, and that's the biggest difference between this library and using Linux ioctls directly. Doing everything manually takes time and the chip probably needs some delays inserted somewhere to work properly.


Getting dependency errors when running Grails example

Getting the following on Ubuntu.  What am I missing?
::::::::::::::::::::::::::::::::::::::::::::::
::          UNRESOLVED DEPENDENCIES         ::
::::::::::::::::::::::::::::::::::::::::::::::
:: io.swagger#swagger-jaxrs;1.5.0-SNAPSHOT: not found
:: org.grails.plugins#jaxrs;0.8: not found
:: org.grails.plugins#cache;1.0.0: not found
::::::::::::::::::::::::::::::::::::::::::::::
| Error Failed to resolve dependencies (Set log level to 'warn' in BuildConfig.groovy for more information):

io.swagger:swagger-jaxrs:1.5.0-SNAPSHOT
org.grails.plugins:jaxrs:0.8
org.grails.plugins:cache:1.0.0

@hellmersjl3ds - while the swagger dependency is easily fixable, the rest are a bit beyond me. This sample was contributed to us, but unfortunately, we're not really grails users/developers so it's difficult to maintain. The sample was mostly copied as a remnant, and perhaps we should delete it itself.
If you have any experience with grails and think you can help us with it, we'd appreciate the assistance.

@ceekayel has kindly contributed a set of changes to the sample which indeed help it compile now.
Unfortunately, there are still issues with the sample, so it's not working just yet. Would have to look further into it.


Add support for inactive vs active plugins

Summary
Add support for inactive vs active plugins.
Checklist

[x] Added or updated unit tests (required for all new features)
[x] All new/modified APIs include changes to the drivers

It's unrelated


Add Post

Please add this post:
Embody System Commands in Rust Programming
Post URL: https://blog.knoldus.com/embody-system-commands-in-rust-programming/
Blog Homepage: https://blog.knoldus.com
Author Name: Pawan Singh Bisht, Knoldus Inc.
Categories: Language

Thank you for your submission. I have read you post and decided not to post it at this time as it is mostly contains content covered in the Rust documentation.


Unable to run inference on customized highres3dnet

Hi, I trained 3D classification network using highres3dnet as a backbone, but I'm unable to infer (getting segmentation fault)
the command used for inference:
python net_classify.py inference -c ./config/QualityControlConfigEval.ini
corresponding config.ini used:
===============================

[T1]
csv_file = ./T1_data.csv
path_to_search =
filename_contains =
filename_not_contains =
pixdim = (1.0, 1.0, 1.0)
spatial_window_size = (128, 128, 128)
interp_order = 3

[label]
csv_file = ./Label_data.csv
spatial_window_size = (1, 1, 1)
interp_order = -1

######################## system configuration sections
[SYSTEM]
cuda_devices = ""
dataset_split_file = ./cross_validation_fold_01.txt
model_dir = ./models/model_highres3dnet

[NETWORK]
name = highres3dnet
activation_function = relu
batch_size = 1
volume_padding_size=0
histogram_ref_file = ./models/model_highres3dnet/histogram_ref_file.txt
cutoff = (0.01, 0.99)
normalisation = True
whitening = True
normalise_foreground_only=True

[INFERENCE]
inference_iter = -1
border=1
# save_seg_dir=./INFERENCE
output_interp_order=0
spatial_window_size=(128, 128, 128)

[EVALUATION]
save_csv_dir = ./EVALUATION
evaluations = accuracy

[CLASSIFICATION]
image = T1
label = label
output_prob = False
num_classes = 2
===========================================

This results in a Segmentation fault, after loading model weights and  data, the output looks like:
NiftyNet version 0.5.0+78.g6eb3821.dirty
[CUSTOM]
-- num_classes: 2
-- output_prob: True
-- label_normalisation: False
-- sampler: ()
-- inferred: ()
-- label: ('label',)
-- image: ('T1',)
-- name: net_classify
[CONFIG_FILE]
-- path: /home/users/kavinash/QualityControl/NiftyNet/config/QualityControlConfigEval.ini
[T1]
-- csv_file: T1_data.csv
-- filename_contains: ()
-- filename_not_contains: ()
-- filename_removefromid:
-- interp_order: 3
-- loader: None
-- pixdim: (1.0, 1.0, 1.0)
-- axcodes: ()
-- spatial_window_size: (128, 128, 128)
[LABEL]
-- csv_file: Label_data.csv
-- filename_contains: None
-- filename_not_contains: ()
-- filename_removefromid:
-- interp_order: -1
-- loader: None
-- pixdim: ()
-- axcodes: ()
-- spatial_window_size: (1, 1, 1)
[SYSTEM]
-- cuda_devices: ""
-- num_threads: 1
-- num_gpus: 0
-- model_dir: /home/users/kavinash/QualityControl/NiftyNet/models/model_highres3dnet
-- dataset_split_file: cross_validation_fold_01.txt
-- event_handler: ('model_saver', 'model_restorer', 'sampler_threading', 'apply_gradients', 'output_interpreter', 'console_logger', 'tensorboard_logger', 'performance_logger')
-- iteration_generator: iteration_generator
-- action: inference
[NETWORK]
-- name: highres3dnet
-- activation_function: relu
-- batch_size: 1
-- smaller_final_batch_mode: pad
-- decay: 0.0
-- reg_type: L2
-- volume_padding_size: (0, 0, 0)
-- volume_padding_mode: minimum
-- volume_padding_to_size: (0,)
-- window_sampling: resize
-- queue_length: 2
-- multimod_foreground_type: and
-- histogram_ref_file: /home/users/kavinash/QualityControl/NiftyNet/models/model_highres3dnet/histogram_ref_file.txt
-- norm_type: percentile
-- cutoff: (0.01, 0.99)
-- foreground_type: otsu_plus
-- normalisation: True
-- rgb_normalisation: False
-- whitening: True
-- normalise_foreground_only: True
-- weight_initializer: he_normal
-- bias_initializer: zeros
-- keep_prob: 1.0
-- weight_initializer_args: {}
-- bias_initializer_args: {}
[INFERENCE]
-- spatial_window_size: (128, 128, 128)
-- inference_iter: 1120
-- dataset_to_infer:
-- save_seg_dir: ./INFERENCE
-- output_postfix: _niftynet_out
-- output_interp_order: 0
-- border: (0, 0, 0)
-- fill_constant: 0.0
[EVALUATION]
-- evaluations: accuracy
-- save_csv_dir: ./EVALUATION
INFO:niftynet: starting classification application
INFO:niftynet: [T1] using existing csv file /oak/stanford/groups/russpold/data/openneuro.org/derivatives/kavinashscoolnet-1.0.0/csv_data/T1_data.csv, skipped filenames search
INFO:niftynet: [label] using existing csv file /oak/stanford/groups/russpold/data/openneuro.org/derivatives/kavinashscoolnet-1.0.0/csv_data/Label_data.csv, skipped filenames search
WARNING:niftynet: Loading from existing partitioning file /oak/stanford/groups/russpold/data/openneuro.org/derivatives/kavinashscoolnet-1.0.0/csv_data/cross_validation_fold_01.txt, ignoring partitioning ratios.
INFO:niftynet:

Number of subjects 272, input section names: ['subject_id', 'T1', 'label']
Dataset partitioning:
-- training 190 cases (69.85%),
-- validation 54 cases (19.85%),
-- inference 28 cases (10.29%).

INFO:niftynet: Image reader: loading 28 subjects from sections ('T1',) as input [image]
INFO:niftynet: normalisation histogram reference models ready for image:('T1',)
2019-06-07 12:33:21.128970: I tensorflow/core/platform/cpu_feature_guard.cc:141] Your CPU supports instructions that this TensorFlow binary was not compiled to use: SSE4.1 SSE4.2 AVX AVX2 AVX512F FMA
2019-06-07 12:33:21.135517: I tensorflow/core/platform/profile_utils/cpu_utils.cc:94] CPU Frequency:<PHONE_NUMBER> Hz
2019-06-07 12:33:21.135669: I tensorflow/compiler/xla/service/service.cc:150] XLA service 0x5557d12ca240 executing computations on platform Host. Devices:
2019-06-07 12:33:21.135703: I tensorflow/compiler/xla/service/service.cc:158]   StreamExecutor device (0): <undefined>, <undefined>
INFO:niftynet: reading size of preprocessed images
WARNING:niftynet: sampler queue_length should be larger than batch_size, defaulting to batch_size * 5.0 (5).
INFO:niftynet: initialised resize sampler {'image': (1, 128, 128, 128, 1, 1), 'image_location': (1, 7)}
WARNING:niftynet: From /home/users/kavinash/QualityControl/NiftyNet/niftynet/engine/application_initializer.py:106: calling VarianceScaling.__init__ (from tensorflow.python.ops.init_ops) with distribution=normal is deprecated and will be removed in a future version.
Instructions for updating:
`normal` is a deprecated alias for `truncated_normal`
INFO:niftynet: using HighRes3DNet
INFO:niftynet: Initialising Dataset from 28 subjects...
WARNING:niftynet: From /home/users/kavinash/QualityControl/NiftyNet/niftynet/engine/image_window_dataset.py:300: py_func (from tensorflow.python.ops.script_ops) is deprecated and will be removed in a future version.
Instructions for updating:
tf.py_func is deprecated in TF V2. Instead, use
    tf.py_function, which takes a python function which manipulates tf eager
    tensors instead of numpy arrays. It's easy to convert a tf eager tensor to
    an ndarray (just call tensor.numpy()) but having access to eager tensors
    means `tf.py_function`s can use accelerators such as GPUs as well as
    being differentiable using a gradient tape.

INFO:niftynet: net_out.shape may need to be resized: (1, 2)
INFO:niftynet: Restoring parameters from /home/users/kavinash/QualityControl/NiftyNet/models/model_highres3dnet/models/model.ckpt-1120

Segmentation fault

Is this perhaps an issue with your Tensorflow install? The segfault would indicate something lower down than Niftynet is the issue. What versions of Tensorflow and Python are you using? What hardware platform (I see it says XLA)?

Thanks for your reply, current environment settings are:
Tensor flow 1.13.1 (did necessary edits in niftynet so it supports this version of tf)
Python 3.7.2
Hardware: cpu cluster with 64 GB of RAM

I'm afraid I think this is a technical issue on your setup. Please try to start inference again with Niftynet running on Tensorflow 1.12 and a regular desktop computer. We're working on getting the later versions of TF working and have encountered enough differences for it to be a challenge.

But I'm able to train the model with the same setup, an error occurs only with inference flag

Which is really odd I admit, but I can't imagine what in Niftynet could possibly cause a segmentation fault. Since it's all Python it's an error in the Tensorflow library or something it interacts with below the Python level so doing this test is all I can think of. Trying it with CPU rather than on GPU might work also.

Thanks, I'll check that once and update

Now suddenly it starts to work after reinstalling all the packages


add issunce data in rawData

Summary

lite credential中把issunceDate加入签名和验签中

Codecov Report

Merging #215 into develop will increase coverage by 0.00%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             develop     #215   +/-   ##
==========================================
  Coverage      39.85%   39.85%
- Complexity      1504     1506    +2
==========================================
  Files            232      232
  Lines          12806    12805    -1
  Branches        1585     1585
==========================================
  Hits            5104     5104
- Misses          7069     7070    +1
+ Partials         633      631    -2

Impacted Files
Coverage Δ
Complexity Δ

...java/com/webank/weid/util/CredentialPojoUtils.java
51.20% <ø> (-0.11%)
103.00 <0.00> (ø)

...e/impl/engine/fiscov2/EvidenceServiceEngineV2.java
73.40% <0.00%> (+0.27%)
41.00% <0.00%> (+2.00%)

Continue to review full report at Codecov.

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


Add release note for 2.11.1

Description
Add release note for 2.11.1
Issues Resolved
N/A
Check List

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

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

Only adding release note. Will not fix build error which is not caused by this PR. Will verify successful build only in 2.11.1.


Issue with inverted colours on terminal using more.

This bug-tracker is monitored by Windows Console development team and other technical types.  We like detail!
If you have a feature request, please post to the UserVoice.

Important: When reporting BSODs or security issues, DO NOT attach memory dumps, logs, or traces to Github issues. Instead, send dumps/traces to<EMAIL_ADDRESS>referencing this GitHub issue.

Please use this form and describe your issue, concisely but precisely, with as much detail as possible

Your Windows build number:  (Type ver at a Windows Command Prompt)
Version 10.0.16299.309

What you're doing and what's happening: (Copy & paste specific commands and their output, or include screen shots)
using ssh to a remote server, running ls -l | more in /var/log/

What's wrong / what should be happening instead:
It should just disable a list of files in this folder but for some reason the terminal goes nuts and shows black texted with a white background as if i have highlighted it (I haven't)

Seems to invert the colours when you get to -- more --

I wouldn't need to use more if i could find a way to scroll the terminal without the mouse!!
Thanks

Is it possible that your ssh session used a "24-bit color" at some point before this happened? Because this sounds exactly like the behaviour reported in issue #78. I can reproduce the same thing in a local session with:
printf "\e[38;5;7m"
ls -la /usr/bin | more

If it's the same bug, then it should hopefully be fixed as soon we receive the Spring 2018 update, which I believe was released a few days ago.

Hi @j4james
I suspect it might be the same issue - I can't seem to reproduce it without using the above command.
Can you tell me what printf "\e[38;5;7m" does?
Cheers
Joe.

@Hyper200 That's just an escape sequence that sets the foreground color to white (the 7 in that sequence is the choice of color). But instead of selecting from the basic 8-color palette, this is one of the extended color commands that selects from a 256-color palette. There is also a command that lets you specify the exact RGB values of the color you want. Either of these extended color commands will trigger a bug in the handling of the inverse attribute, exactly like the problem you reported.
So my guess was you might have run an app beforehand that used one of those commands to set their color scheme. It could even just be a color that was used in the command prompt of the server you were connecting to.

@j4james
Perfect thanks for the info - I guess this can be closed as a duplicate!


Stability of the app & future plans

The frequent bus fault upon application start is reported to the firmware developer team. But this won't cope with the fact, that the application got bigger and bigger due to new features. So RAM space will always be a limited resource.
But I'm thinking about releasing a fork of the original firmware with the MicroPython interpreter as a core service. This would mitigate the memory problem. But could also mean, that I have to remove some other core service.
The app store version would still be around and maintained, but with a limited set of features.
If you have an opinion about what feature should be part of the app version or what should be added to the firmware version, feel free to share your thoughts here.

Just this ♥

I have never, ever been able to successfully launch microPython, it always reports OOM. Unclear what is filling memory.

Possibly of interest: I bought a new Flipper for my wife this week, and while setting it up, on impulse I loaded mPython... And it seems to work fine, although I did not try working it out thoroughly. The two devices are I assume running the same firmware.

I know I'm late, but I vote firmware fork!
(Plus HID plz)


Breakpoint specific sizes for off-canvas

This PR add the possibility to define a different off-canvas size for small and medium by replacing the number with a map.
In a current project the off-canvas is supposed to have clearly more width for medium than for small.
But no matter what value I choose (even percentaged or viewport related), it doesn't look good for both breakpoints.
The bottom line is I need two different off-canvas sizes.
The new maps $offcanvas-sizes and $offcanvas-vertical-sizes replace the prior $offcanvas-size and $offcanvas-vertical-size. Since I don't consider any custom setting of these deprecated variables I've added warnings that appear during the gulp process.
Alternatively I could leave the variables name untouched and add several conditions to check if it's a number or a map. But imo a warning is better because it isn't much work for the user to update the settings and keeps the code cleaner.
@brettsmason @IamManchanda what do you think about this feature?

For backwards compatibility with old settings files, can you have the old variables set up the new ones if they're defined? Can also print a deprecation warning, but it's best if we don't break projects that have the older settings and not the newer.

@kball a deprecation warning was already included by me but you're right, still supporting the deprecated settings would not be amiss.
I've updated the PR and take over the values now.

Awesome... this is looking good as far as it goes - makes me wonder though if we should make the logic iterate through the sizes (to allow someone to do this for any arbitrary map of breakpoints) rather than explicitly call out small & medium... thoughts?
Also @brettsmason would love your thoughts & review

This is looking cool from outset... let me dig in...

I'm going to merge this as is, because I'd like to get a point release out and want to land on testable set of changes... that said, would really love a new PR that iterates over the breakpoints to allow any set rather than hard coding small & medium


Use logrus instead of fmt.Println

Do not use fmt.Println in client, shows up in UX of importers

LGTM


[FEATURE_REQUEST] An new widget showing CPU temperature

Is your feature request related to a problem? If so, please describe.
No response
Describe the solution you'd like
Hi Lissy,
I'm interested in a widget that shows me the current temperature of the CPU of my Raspberry PI 4.
My Glances docker container shows it under sensors as cpu_temp1. It can have the same look as gl-current-cpu and gl-current-mem.
I'm very happy with the dashboard. Got netdata up and running also. That dives very deep into all possible parameters you can think of. I wish I had that tool available in my working days as datacenter system engineer :smiley:
regards
Henk
Priority
Low (Nice-to-have)
Is this something you would be keen to implement
Yes!

The new widget is working (ofcourse 😄 ), but it doesn't seem to accept the interval parameter? If I look at the (F12) console api/3/mem and cpu are constantly updating. but api/3/sensors only if you refresh by hand. Maybe a crazy idea. But wouldn't it be nicer (I mean less resource intensive) if you could make these kind of requests (xhr?) depended on the parameter if the widget is collapsed or not? My poor PI 4 is having a hard time 😢 .
I am already an advocate of dashy on discord and reddit whenever I can 😃 .
Using this as a template is still a bridge too far for me 😄 .

Glad it's working :) And thank you for sharing Dashy, that means a lot :D
That's a good idea, I can make requests be paused when the widget is collapsed.
The continuous updates seems to be working. If you open up the browser tools, under the networking tab, select XHR and you should see the updates coming through. It might be that the actual Glances sensors plugin isn't showing changes as regularly as your updating.
  - type: gl-cpu-temp
+   updateInterval: 20
    options:
      hostname: http://dns-device.local:61208

Also in terms of performance, it seems that enabling Glance's sensors plugin is known to cause a hit in performance on some systems. Increasing the time between updates (higher update interval) should help with this.
Hope that helps :)

Oh I'm sorry, you are right. I put the updateInterval in the wrong widget. That's the dashboard I wanted.


Add slug to uploads from Azure Pipelines

Fixes #421
Use the predefined variable BUILD_REPOSITORY_NAME to set the slug for uploads from Azure Pipelines.
Based on the documentation, I believe this variable is the correct choice. The other option would be BUILD_REPOSITORY_ID but that doesn't change even if the repo name changes.
I looked at the source for the bash uploader and it looks like it was using ${SYSTEM_TEAMFOUNDATIONSERVERURI}${SYSTEM_TEAMPROJECT} which has the slug as a substring of those two values combined, but not a specific variable for the slug.
Let me know if I have picked the incorrect variable and I'll be happy to change it.
Update tests to ensure slug is always included.

@samdoran I think it was getting set with this fallback logic from git... https://github.com/codecov/codecov-bash/blob/43c5d3c7147b91674dd69c3e0e0becc48eba04bd/codecov#L1040-L1060
I'm trying to determine if that's the case.

Thanks for merging the fix. I confirmed that 0.1.6 of the new uploader works as expected from Azure Pipelines now.


Fix event names

Considering the recent changes (#302), we also need to update the name of the generated events in all NApps.
In of_core, for instance, they are generated outside of the 'main' (see of_core.utils module).

As discussed, I reverted the changes so we don't break NApps that listen to "kytos/...".


CAD-3638: extended trace-forward library.

Since both trace-forward and datapoint-forward specify node-specific protocols, it's better to combine them into one package. This package will be used by trace-dispatcher library for forwarding TraceObjects and DataPoints from the node to external acceptor app (for example, cardano-tracer or cardano-wallet).

bors r+

bors r+

bors cancel

bors r-

bors r+

bors r+

bors merge

bors r+

bors r+

bors r+

bors r+


add README

readme and also added one code change to continue the thread if an error occurs so that you don't have to restart the server.

LGTM but wait for someone from docs @npentrel feel free to delegate


Unable to configure xpack.infra ENV vars

Support the below keys.
XPACK_INFRA_SOURCES_DEFAULT_METRICALIAS
XPACK_INFRA_SOURCES_DEFAULT_LOGALIAS
XPACK_INFRA_SOURCES_DEFAULT_FIELDS_MESSAGE
XPACK_INFRA_SOURCES_DEFAULT_FIELDS_HOST
XPACK_INFRA_SOURCES_DEFAULT_FIELDS_POD
XPACK_INFRA_SOURCES_DEFAULT_FIELDS_CONTAINER
XPACK_INFRA_SOURCES_DEFAULT_FIELDS_TIMESTAMP
XPACK_INFRA_SOURCES_DEFAULT_FIELDS_TIEBREAKER

+1 for this, after viewing /usr/local/bin/kibana-docker file I think this approach of adding env var hardcoded into an array should be improved:
# Run Kibana, using environment variables to set longopts defining Kibana's
# configuration.
#
# eg. Setting the environment variable:
#
#       ELASTICSEARCH_STARTUPTIMEOUT=60
#
# will cause Kibana to be invoked with:
#
#       --elasticsearch.startupTimeout=60

kibana_vars=(
    console.enabled
    console.proxyConfig
    console.proxyFilter
    elasticsearch.customHeaders
    elasticsearch.logQueries
    elasticsearch.password
    elasticsearch.pingTimeout
    elasticsearch.preserveHost
    elasticsearch.requestHeadersWhitelist
    elasticsearch.requestTimeout
    elasticsearch.shardTimeout
    elasticsearch.ssl.ca
    elasticsearch.ssl.cert
    elasticsearch.ssl.certificate
    elasticsearch.ssl.certificateAuthorities
    elasticsearch.ssl.key
    elasticsearch.ssl.keyPassphrase
    elasticsearch.ssl.verificationMode
    elasticsearch.ssl.verify
    elasticsearch.startupTimeout
    elasticsearch.tribe.customHeaders
    elasticsearch.tribe.password
    elasticsearch.tribe.pingTimeout
    elasticsearch.tribe.requestHeadersWhitelist
    elasticsearch.tribe.requestTimeout
    elasticsearch.tribe.ssl.ca
    elasticsearch.tribe.ssl.cert
    elasticsearch.tribe.ssl.certificate
    elasticsearch.tribe.ssl.certificateAuthorities
    elasticsearch.tribe.ssl.key
    elasticsearch.tribe.ssl.keyPassphrase
    elasticsearch.tribe.ssl.verificationMode
    elasticsearch.tribe.ssl.verify
    elasticsearch.tribe.url
    elasticsearch.tribe.username
    elasticsearch.url
    elasticsearch.username
    kibana.defaultAppId
    kibana.index
    logging.dest
    logging.quiet
    logging.silent
    logging.useUTC
    logging.verbose
    map.includeElasticMapsService
    ops.interval
    path.data
    pid.file
    regionmap
    regionmap.includeElasticMapsService
    server.basePath
    server.customResponseHeaders
    server.defaultRoute
    server.host
    server.maxPayloadBytes
    server.name
    server.port
    server.rewriteBasePath
    server.ssl.cert
    server.ssl.certificate
    server.ssl.certificateAuthorities
    server.ssl.cipherSuites
    server.ssl.clientAuthentication
    server.customResponseHeaders
    server.ssl.enabled
    server.ssl.key
    server.ssl.keyPassphrase
    server.ssl.redirectHttpFromPort
    server.ssl.supportedProtocols
    server.xsrf.whitelist
    status.allowAnonymous
    status.v6ApiFormat
    tilemap.options.attribution
    tilemap.options.maxZoom
    tilemap.options.minZoom
    tilemap.options.subdomains
    tilemap.url
    timelion.enabled
    vega.enableExternalUrls
    xpack.apm.enabled
    xpack.apm.ui.enabled
    xpack.canvas.enabled
    xpack.graph.enabled
    xpack.grokdebugger.enabled
    xpack.infra.enabled
    xpack.ml.enabled
    xpack.monitoring.elasticsearch.password
    xpack.monitoring.elasticsearch.pingTimeout
    xpack.monitoring.elasticsearch.url
    xpack.monitoring.elasticsearch.username
    xpack.monitoring.elasticsearch.ssl.certificateAuthorities
    xpack.monitoring.enabled
    xpack.monitoring.kibana.collection.enabled
    xpack.monitoring.kibana.collection.interval
    xpack.monitoring.max_bucket_size
    xpack.monitoring.min_interval_seconds
    xpack.monitoring.node_resolver
    xpack.monitoring.report_stats
    xpack.monitoring.ui.container.elasticsearch.enabled
    xpack.monitoring.ui.container.logstash.enabled
    xpack.monitoring.ui.enabled
    xpack.reporting.capture.browser.chromium.disableSandbox
    xpack.reporting.capture.browser.chromium.proxy.enabled
    xpack.reporting.capture.browser.chromium.proxy.server
    xpack.reporting.capture.browser.chromium.proxy.bypass
    xpack.reporting.capture.browser.type
    xpack.reporting.capture.concurrency
    xpack.reporting.capture.loadDelay
    xpack.reporting.capture.settleTime
    xpack.reporting.capture.timeout
    xpack.reporting.csv.maxSizeBytes
    xpack.reporting.enabled
    xpack.reporting.encryptionKey
    xpack.reporting.index
    xpack.reporting.kibanaApp
    xpack.reporting.kibanaServer.hostname
    xpack.reporting.kibanaServer.port
    xpack.reporting.kibanaServer.protocol
    xpack.reporting.queue.indexInterval
    xpack.reporting.queue.pollInterval
    xpack.reporting.queue.timeout
    xpack.reporting.roles.allow
    xpack.searchprofiler.enabled
    xpack.security.authProviders
    xpack.security.cookieName
    xpack.security.enabled
    xpack.security.encryptionKey
    xpack.security.secureCookies
    xpack.security.sessionTimeout
    xpack.xpack_main.telemetry.enabled
)

Yes. I'd love to see this generalized and standardized across all the Elastic images for the 7.0.0 release.

@tylersmalley maybe adding longopts to usage will help to create a more generic approach. Kind of:
$ kibana --help
...
    --xpack.security.authProviders    some help text.
    --xpack.security.cookieName    some help text.
    --xpack.security.enabled    some help text.
    --xpack.security.encryptionKey    some help text.
    --xpack.security.secureCookies    some help text.
    --xpack.security.sessionTimeout    some help text.
    --xpack.xpack_main.telemetry.enabled    some help text.
...

Then every argument prefixed with -- (longopts) could be parameterized via environment variables, so instead of:
kibana_vars=(
    console.enabled
    console.proxyConfig
...
)

You could do:
# Create kibana_vars array based on longopts provided by kibana --help command
kibana_vars=($(kibana --help | sed -e "s/^.*--\([^ ]\+\).*$/\1/g"))

# use the same loop

Has their been anymore traction on this?
According to the documentation this should be doable:
https://www.elastic.co/guide/en/kibana/6.5/docker.html#environment-variable-config
Logs is configurable:
https://www.elastic.co/guide/en/kibana/6.5/settings-xpack-kb.html
So settings the OP variables should work based on the setting -> ENV naming convention of "." to "_".
https://www.elastic.co/guide/en/kibana/6.5/logs-ui-settings-kb.html
And I've tested running the container and while the ENV variable is there, it still is using filebeat-* for the Logs UI. I'm sure I could mount the kibana.yml but trying to use ENV variables instead.
bash-4.2$ env
HOSTNAME=cad190f5be77
TERM=xterm
ELASTIC_CONTAINER=true
...
XPACK_INFRA_SOURCES_DEFAULT_LOGALIAS=logstash-*
...

@cdenneen we've added these to the whitelist here for releases going forward
Long term, we've moved kibana-docker to the kibana repo and are tracking a generic approach at https://github.com/elastic/kibana/issues/30598.


🐛 Bug: Check walk connectivity of the NM network in SF

Describe the bug

There are edge cases in which all the elevated non-motorized infrastructure around some zones in SF caused them to not be able to access the roadway network. We discovered this in Link 21 and suggested them to add a few more centroid connectors.
Progress:

[ ] Sufficient information provided
[ ] Cause identified/found
[ ] Test developed/identified
[ ] Approach determined
[ ] Test passes

To Reproduce
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Failing tests

[ ] No applicable test failed, need to create.
[ ] other...specify

Triggering line of code
Thoughts on resolution
Full stack trace
Environment
Operating system:
Context (conda, jupyter, etc):
Environment (e.g. output from conda list):

@ychtw please update the issue description above.


cachedImplicit presentation compiler hack

in ENSIME we have a file that takes 2 minutes to compile, and it (paraphrasing) looks like this :
object Formats extends FamilyFormats {
  implicit val foo: JsonFormat[EnsimeIn] = cachedImplicit
  implicit val bar: JsonFormat[EnsimeOut] = cachedImplicit
}

c.f. https://github.com/ensime/ensime-server/blob/master/jerk/src/main/scala/org/ensime/jerk/JerkFormats.scala#L39
it is the kind of pattern that I'm encouraging people to use with spray-json-shapeless (and sexpress when I get round to writing it properly).
the thing is, when anyone opens this file in ENSIME, the presentation compiler also takes about 2 minutes to infer the types.
As you know, there is no way to interrupt the presentation compiler when it really gets going, so basically this knocks out the presentation compiler for all tasks until it finishes. And it'll happily do the whole thing again if the file is trivially modified or the file is closed and opened again.
This is a problem with all complex implicits when using shapeless.
From an ENSIME user perspective, giving back control of the presentation compiler is far far far more important than getting it right. I believe that the vast majority of ENSIME (and scala-ide) users would be happy with the presentation compiler effectively ignoring this code.
Until the presentation compiler allows such interruptions, I propose a hack. cachedImplicit expands something like this
  implicit val foo: JsonFormat[EnsimeIn] = {
    def foo: JsonFormat[EnsimeIn] = ???
    implicitly[JsonFormat[EnsimeIn]]
  }

but if it expanded like so when run only as the presentation compiler (or perhaps only in presentation compiler and some setting is activated):
  implicit val foo: JsonFormat[EnsimeIn] = null // or throw a GuruMeditationFailure

then that would be pretty fantastic because the code would typecheck immediately.
I'm aware that this won't fix all the presentation compiler performance problems with shapeless (there are also a few non-performance related ones) but I believe this works around the biggest problem that I've seen. It'll mean that the presentation compiler cannot be trusted to catch missing cachedImplicits, but could it ever be trusted to do this anyway?

note to self, start here https://github.com/milessabin/shapeless/blob/master/core/src/main/scala/shapeless/package.scala#L110

I think I might be able to do something here.
I could arrange for cachedImplicit[T] to not perform the resolution on the RHS iff the following two conditions are met,

We're running in the context of the presentation compiler.
An implicit of type TrustMe[T] is in scope.

Would that work for you?

It seems a bit nasty that an implicit makes it to runtime for this and that code changes are needed by the user. Why not just use an annotation in that case?

Also, bare in mind that cachedImplicit doesn't work at all in the PC, even for simple things. I'm also not sure if this will work as a macro, but it's worth investigating.

An annotation would work too.
The effect of this is that,
@trustMe val foo: T = cachedImplicit

would be rewritten as,
val foo: T = null

If that doesn't get along well with the PC then I'm afraid you're doomed.

well not entirely doomed. If that doesn't work it probably means that a presentation compiler plugin is the answer. I was going to try coding up this exact feature last night when you threw me the curveball with the typed class example, which appears to completely confuse the compiler :smile:

Do you want this or not?

Definitely want! I'm incredibly interested to see if this can be implemented as a macro vs compiler plugin.

Okey doke ... I'll see what I can do ...

alternative behaviour under the presentation compiler can now be asserted using http://github.com/ensime/pcplod

we created a project to do this, nothing needed from shapeless https://github.com/ensime/ensime-plugin-implicits


Remove Python DM installer code

[x] Remove Python code from Forseti Security Repo
[x] Test and validate there is no TF dependencies on the removed Python code.

There are some script dependencies from TF in the forseti-security repo.  I am going to leave them for now and then move them to the Terraform module in a future PR (incremental changes).


DTS-38319

https://publicissapient.atlassian.net/browse/DTS-38319

update the installation json ok fieldmapping structure as well

Done

in the ticket fix version is 10.1.0, and we have added the mongock files in 950, and update this https://publicissapient.atlassian.net/wiki/spaces/SPDS/pages/354058241/10.1.0+Mongock+Release confluence as well

Done


antspyx==0.3.2 not available

When trying to install requirements, antspyx version 0.3.2 does not exist anymore.

Thanks for reporting! It looks there are PyPi size limitations on the antspyx account that cause older versions to be deleted/removed.
For now, you can safely edit the requirements.txt to bump the version to antspyx==0.3.5.
I'll test the changes and push updates in a few days to initiate the docker image rebuild


PR #42063 - sql: new session variable strict_ddl_atomicity

Exalate commented:
Related PR: https://github.com/cockroachdb/cockroach/pull/42063
Commit: https://github.com/cockroachdb/cockroach/commit/3de280109f4e1151ce5b72418e3c911f00b15fdc
Epic: CRDB-28893
Fixes: CRDB-30617
Informs: CRDB-5394 CRDB-19226

Release note (sql change): a SQL client can now request strict
atomicity for mixed DDL/DML transactions with the new session variable
strict_ddl_atomicity, which defaults to false. When this variable
is set to true, CockroachDB will refuse to accept processing those
specific DDL statements inside BEGIN...COMMIT for which it cannot
guarantee atomic processing (other DDL statements are still allowed).
Note that schema changes implicit in certain operations (e.g. IMPORT)
are not protected via the new mechanism and can still fail with
XXA00 errors.
Jira Issue: DOC-8628

@rmloveland , could you please add / link an info which statements are DDL and which DML? What does GRANT ... count as?

hi @OndraZizka - DDL is talked about a little in our schema change docs - we don't list every statement that is DDL, but we link to the DDL wikipedia page
re: your specific question, I think CREATE ROLE, CREATE USER, and GRANT are all DDL statements - @rafiss is that correct?

I think CREATE ROLE, CREATE USER, and GRANT are all DDL statements - @rafiss is that correct?

that's correct


优化_example代码以及文档

see #186
状态:代码基本优化完，还差点文档

Codecov Report

Merging #187 into master will increase coverage by 0.05%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #187      +/-   ##
==========================================
+ Coverage   93.15%   93.21%   +0.05%
==========================================
  Files          41       41
  Lines        1856     1856
==========================================
+ Hits         1729     1730       +1
+ Misses         86       85       -1
  Partials       41       41

Impacted Files
Coverage Δ

bench/task.go
87.8% <0%> (+1.21%)
:arrow_up:

Continue to review full report at Codecov.

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


[hotfix] Fix hypelink typo in connect.md and connect.zh.md

What is the purpose of the change
Fix hyperlink typo in connect.md and connect.zh.md
Verifying this change
This change is a trivial rework / code cleanup without any test coverage.
Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): (no)
The public API, i.e., is any changed class annotated with @Public(Evolving): (no)
The serializers: (no)
The runtime per-record code paths (performance sensitive): (no)
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn/Mesos, ZooKeeper: (no)
The S3 file system connector: (no )

Documentation

Does this pull request introduce a new feature? (no)
If yes, how is the feature documented? (not applicable)

cc @wuchong

@wuchong thanks for the review and merging.


How to remove inline or reply keyboard markup after clicking

Please follow issue template
If you want to chat, feel free to join our group.


Release 0.37.0

Target release date is the first weekend in September.

Fix unsound return types being allowed for autorecover
The existing autorecover code was checking whether it was safe to write to the recovery cap, regardless of whether it was an argument. That's correct for arguments, but for result types we need to ensure that it's safe to extract.
Safety to extract is derived from Steed's extracting table: a type is safe to extract if results in itself under extracting viewpoint adaptation. Thus it is unsound to extract trn from trn, but it is sound to extract box.

Revert RFC 67
The original intent behind RFC0067 was to make it easy to add a prefix with the
log level for any given log message. However, there is a logic bug in the
implementation; the log level prefix added to messages in LogFormatter would
always be the log level specified in Logger.create(), not the log level desired
at specific call sites. This would lead to misleading log messages where the log
level prefix doesn't match the severity of the log message, such as "FINE:
Critical error. Shutting down".
It would be better if these changes were reverted so a more thought-out solution
could be implemented in the future.

Always allow field access for objects defined inside a recover block
Some field accesses were incorrectly being rejected inside recover blocks. This fix allows all nested field accesses on variables which were defined inside the recover block, like the examples below:
recover
   let x = ...
   let y = x.y
   x.y = Foo
   x.y.z = y.z

Release will be started whenever https://github.com/ponylang/ponyc/pull/3626 is merged.

The release will be some time this weekend. Probably this evening.

Release is underway.

Released.


Documentation

change the Sphinx theme for the pydata one
publish on Netlify
link with timeatlas.dev

One extra task of this issue is to add an initial comprehensive documentation

Done


"unknown opecode type: undefined"

Using BiwaScheme 0.6.3.dev
When I run
((lambda (a . b) 0))

I get
[BUG] unknown opecode type: undefined []

which I guess means the compiler's generating invalid bytecode?

Maybe it's because you called up the lambda expression without it operating on any parameters.
I ran:
((lambda (a . b) 0) 'a)
It returned:
=> 0

The reason it's a bug (apart from that fact that it throws [BUG]…) is because the result is inconsistent with these cases
((lambda (a) 0))
((lambda (a b) 0))
((lambda (a b . c) 0))

which all return => 0

I'm pretty sure that all of those cases should return an error since your parameters don't match. Either way there certainly seems to be something wrong.
I can confirm that I get this behaviour in 0.6.2.

For what it's worth, I checked the spec to see what the correct behaviour is:
( http://www.r6rs.org/final/html/r6rs/r6rs-Z-H-15.html#node_sec_A.9 )
P1[((lambda (x1 x2 ··· dot x) e e ···) v1 ···)] →
P1[(raise (make-cond “arity mismatch”))]   (#v1 < #x2 + 1)

So all those cases should indeed throw.
Further testing reveals that the bug appears in a series of cases:
((lambda (a b . z) 0) 0)
((lambda (a b c . z) 0) 0 0)
((lambda (a b c d . z) 0) 0 0 0)
; all => [BUG] unknown opecode type: undefined []
; generally:
((lambda (x ··· . z) 0) v ···) ; when #v = #x - 1

So, when the function is variadic, and (number of actual parameters) = (number of formal parameters before the dot) - 1, we get this bug.
Issue #12 is related but distinct — it addresses non-standards-compliant behaviour with non-variadic functions.

Actually, current version of BiwaScheme does not check whether the number of arguments is correct.
#49 will fix this (and #12).


Cargo.toml in iron 0.3 doesn't match version in repository

As of rustc 1.12.0-nightly (7333c4ac2 2016-07-31), iron 0.3 as downloaded by nightly Cargo fails to compile with the following error:
$ cargo build
    Updating registry `https://github.com/rust-lang/crates.io-index`
 Downloading iron v0.3.0
error: unable to get packages from source

Caused by:
  failed to parse manifest at `/home/centos/.cargo/registry/src/github.com-1ecc6299db9ec823/iron-0.3.0/Cargo.toml`

As far as I can tell, this is due to plugin = "0.2*" in Cargo.toml - removing the * causes it to compile again quite happily. This was fixed in 16c858ec2901e2992fe5e529780f59fa8ed12903 - I don't know how this is still present in the version that cargo automatically downloads.
Might it be possible to get a v0.3.1 released with this fixed?

Do older Rust versions not have this problem?
On 2 August 2016 17:11:52 CEST, BenjaminGill-Metaswitch<EMAIL_ADDRESS>wrote:

As of rustc 1.12.0-nightly (7333c4ac2 2016-07-31), iron 0.3 as
downloaded by nightly Cargo fails to compile with the following error:
$ cargo build
   Updating registry `https://github.com/rust-lang/crates.io-index`
Downloading iron v0.3.0
error: unable to get packages from source

Caused by:
failed to parse manifest at
`/home/centos/.cargo/registry/src/github.com-1ecc6299db9ec823/iron-0.3.0/Cargo.toml`

As far as I can tell, this is due to plugin = "0.2*" in Cargo.toml -
removing the * causes it to compile again quite happily. This was
fixed in 16c858ec2901e2992fe5e529780f59fa8ed12903 - I don't know how
this is still present in the version that cargo automatically
downloads.
Might it be possible to get a v0.3.1 released with this fixed?

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/iron/iron/issues/471

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

No - rustc 1.12.0-nightly (1225e122f 2016-07-30) is perfectly happy compiling iron 0.3.

I'm unable to reproduce this. I can't find the broken version specifier at either the git repo or the frontend

Sorry, nevermind.


Mark slow tests and don't run them by default

We'll have a few more of these after #1198 goes in, but plotting and some of the rolling aggregation tests already fall in this category.
For development purposes, it would be nice if these don't run automatically so the whole test suite can finish in handful of seconds. They should still always run on Travis-CI and Appveyor, which take a few minutes to setup.
See
http://doc.pytest.org/en/latest/example/simple.html#control-skipping-of-tests-according-to-command-line-option for guidance from pytest.

@shoyer, this seems pretty straight forward from http://doc.pytest.org/en/latest/example/simple.html#control-skipping-of-tests-according-to-command-line-option-- all we need is to define the @slow decorator and mark the slow tests, correct?  This seems like a fast PR write-up / fulfill following merge of #1198 unless I'm missing something.

I would have a preference for py.test --skip-slow to explicitly skip, rather than default skipping.
And then unit tests should be fast, this is only for tests that really can't be made fast


Separate Label from Visualizations

Labels can very often be combined with visualizations for individual items.
Instead of having labels be part of a visualization, it should probably be a separate thing that we can switch on for items (not for groups or summaries).
Options could be just binary ("Show Label"), or it could be three states:

Show Label
Show Label for Selected
No Label

a complex request since each renderer defines the content of a cell. In order to add labels as another layer on top of each, the cells needs to be wrapped such that the renderer renders in a child of cell and not the cell anymore. This also requires to adapt a lot of the CSS code since they assume that the cell = renderer space.
For some elements and cells a label can be very long, e.g. for a column with a long text, or multiple values. That might impact the performance

Hmm, ok, how about introducing two states then for each relevant renderer? One with label, one without. Would that be easier? If so, I can think through which ones would be affected.


UI Fixes

[x] Remove the new docs page, revert to that docs section being on bottom of home page
[x] Remove "Read more" menu nav
[x] Introduce the docs section on home page with the intro text here: http://okfnlabs.org/blog/2015/03/06/goodtables-web-service.html
[x] fix the current path issue in bootstrap-sass (path to glyph font)
[x] make videos a bit smaller, remove padding from their iframes

Fixed


Request: support className in addition to style

It would be nice to style the avatar using CSS classes instead of a style object.  Should be a simple change to propagate className to the main div.

already merged in master


Fix Docker Publish workflow

https://github.com/ckb-cell/rgbpp-sdk/actions/runs/10397406203 was failed since PR278.
References

https://github.com/ckb-cell/rgbpp-sdk/pull/278

I'm just wondering: Is the Docker Image for the SDK Service necessary?
Likely, CoinEx doesn't use it, and Docker isn't needed in daily development. I suggest we remove Docker.

Docker isn't needed in daily development

You may be right.
We can disable the workflow for now.


Add possibility to set className to rendered span

Sometimes is necessary to style span because of some non trivial page layout (e.g. using flexbox).

Thanks for your interest in react-waypoint!
Is it possible to solve your issue by wrapping your waypoint with a span and styling that span instead? We believe that passing a className to components is an anti-pattern so we'd prefer to avoid expanding this component's API in this way. More info: https://medium.com/brigade-engineering/don-t-pass-css-classes-between-components-e9f7ab192785

Well, it's interesting and also kinda limiting. But I respect it. What about adding some default className  to the <span> element like .waypoint to be more specific then just the bare element?

I'm closing this without any action. I understand that a class name could be helpful and it isn't hard to add. But we want to stay consistent with how we deal with className props, and this is not the only component where we have been firm on the no-className policy. @petrbrzek I hope you don't feel like we're being overprotecting (I understand it might come across as such). And if adding a wrapper isn't possible in some scenarios, let us know and we can reconsider our policy. :)


How many airdrops per transaction can I do?

Hi,
Thanks for the app. I'm trying to find out how many airdrops per transaction can I send?. I have to do batch airdrops like thousands of them and you know the gas fees are high these days. Other solutions normally can do up to 150 airdrops per transaction, how much is this going to do? After I create a safe, can I batch transfer 1000s of airdrops in a single safe transaction?

You should be able to do about 200 maybe 220 before you reach about 60% of the block gas limit. I made a benchmark for this in another repo. I will dig this up for you. Thanks for the great question!
Of course you can always try to go for higher block limits, but it is unlikely that your block will be mined without a very high gas price.

Here is the test for an equivalent transaction that pushes the number of transactions to 50% of the block gas limit:
https://github.com/gnosis/dex-liquidity-provision/blob/67a887952631da11e0b5f40dc551d121a04b8be4/test/scripts/test_airdrop.js#L128-L169

Actually this test used a gas cap of 4M and managed to squeeze in 213 transfers. Of course the gas consumed for a transfer also depends on the token you are sending as they may implement the transfer function differently than others.

understood..thank you for the detailed explanation

understood..thank you for the detailed explanation


Incorrect inferences for has input

While doing an annotation review of this annotation:

mASAP1/isom1/UnPhos1 Mmus
enables
protein binding
PMID:12771146
direct assay evidence used in manual assertion

20161216
MGI
has_input(1-phosphatidyl-1D-myo-inositol 4,5-bisphosphate)
contributor=http://orcid.org/0000-0001-7476-6306|model-state=production|noctua-model-id=gomodel:581e072c00000473

from this model:
http://noctua.berkeleybop.org/editor/graph/gomodel:581e072c00000473
We can see that there is an inference of protein binding with input of a chemical. This seems incorrect or misleading.
I believe it is a result of these rules:
( ?x2 type molecular_function ) ∧ ( ?x3 directly_regulates ?x2 ) ∧ ( ?x3 type molecular_function ) ∧ ( ?x1 enables ?x2 ) → ( ?x3 has_input ?x1 )
,
( ?x1 type enzyme activator activity ) → ( ?x1 type molecular_function )
,
( ?x1 type binding ) ∧ ( ?x1 has_input ?x2 ) ∧ ( ?x2 type protein ) → ( ?x1 type protein binding )
We need to investigate and correct this. It might be traceable to having generic inputs.

@ukemi I think your assessment is correct regarding the explanation.  I'm wondering if this inference is generally desirable ?:
( ?x2 type molecular_function ) ∧ ( ?x3 directly_regulates ?x2 ) ∧ ( ?x3 type molecular_function ) ∧ ( ?x1 enables ?x2 ) → ( ?x3 has_input ?x1 )

I set up another model in noctua-dev to experiment:
http://noctua-dev.berkeleybop.org/editor/graph/gomodel:5b4695e900000439
Experiments there show that many of the terms that appear in the 'gene product' searches are not typed as proteins (indeed often not typed as anything).  e.g. Cdk2 Mmus , Vipr1 Mmus.  This is also evident on the production Noctua.  If genes like these are swapped in for one that are typed as proteins (like [PR:Q8CEE6] mPASK Mmus) the inference in question in the ticket won't happen.
I wonder if the reason we haven't noticed this problem before is that the reasoner has not known what kinds of gene products it has been looking at.  This seems like an important thing to fix.

This is the same problem I had with the transcription factor example, isn't it ?

It is not exactly the same, but stems from the same errors. I think we really need to step back and look at the algebra of property chains, particularly for regulates relations.

This seems to be fixed.


Make readme.md more readable

Organize the readme.md so that people can easily understand about the repo.

@subhashis2204 Interested. Would like to work.

ok @RashakDude go ahead.

Hey Kindly look into the PR #50 and help in closing it.

Hey @subhashis2204, if you have some additional features to add, kindly let me know. Otherwise, it would be helpful if you close this issue. 😁
Thanks,
Rajat


Added better Java sample (FizzBuzz instead of JUnit)

I thought that the JUnit sample was, frankly, a lousy example of Java code. So I wrote a full FizzBuzz program to use as a new example. My program uses most of the common Java syntax and logic flows (block comment styles, if/else/for statement styles and patterns, etc) to hopefully provide a better Java sample.

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.:x: dabockster sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.


Update requirements-dev.txt

Addresses https://github.com/DenisCarriere/geocoder/issues/298
Production package should really not be using "requirements-dev" when there's already a requirements file- this leads to confusion and bugs.

Agreed, I guess we could replace requirements-dev.txt => requirements.txt since the production dependencies are being handled in setup.py.


Add michael-valdron as has-admin

Requesting access for has-admin as a member of the devfiles team.

/lgtm


Weird margin issue at certain size

Issue description:
I have a really annoying issue, whereas the slider seems to go outside its boundaries at a certain size. It works fine:
< 1400px its a problem:
https://ibb.co/kMDrG8
> 1400px its fine:
https://ibb.co/gVVGio
(why can't we add images here directly? I've done it loads of times before on Github projects)
Demo link/slider setting:
https://www.athertonsltd.co.uk/new/testimonials.html
Config:
	var slider = tns({
    	container: '.home-slider',
    	items: 1,
    	slideBy: 'page',
    	autoplay: true,
    	controls: false,
    	nav: false
  	});

HTML:

Having had Rich and his team do work for me in the past, I asked him if he could design me an oak log store to match my new oak framed garage. He discussed the design with me and came up with a very reasonable quote. He made me the most beautiful log store with lovely oak beams and curved braces and a tile roof. He and his apprentice cut all the oak to size on site, dug out small foundations for the uprights onto which they built small brick piers to support the oak uprights. It took three days. They tidied up, so it looked like they hadn't even been there. I have no hesitation to recommend him.

Some Person | Location here

Having had Rich and his team do work for me in the past, I asked him if he could design me an oak log store to match my new oak framed garage. He discussed the design with me and came up with a very reasonable quote. He made me the most beautiful log store with lovely oak beams and curved braces and a tile roof. He and his apprentice cut all the oak to size on site, dug out small foundations for the uprights onto which they built small brick piers to support the oak uprights. It took three days. They tidied up, so it looked like they hadn't even been there. I have no hesitation to recommend him.

Some Person | Location here

SCSS:
#slider-wrapper {

	display: flex;
	justify-content: center;
	background: blue;

	.tns-outer {
		button {
			display: none;
		}
	}

	.home-slider {

		background:yellow;

		.slide  {
			position: relative;

			.inner-slide {

				margin-left: 1.4rem;
				margin-right: 1.4rem;

				@include mq($from: sm) {
					display: flex;
					justify-content: space-between;
				}

				.inner-img {
					width: 100%;
					display: flex;
					justify-content: center;
					flex-grow: 0;
					img {
						max-width: 100%;
					}
				}

				.review {
					flex-grow: 1;
					.comment {
						position: relative;
						padding-left: 2.5rem;
						padding-right: 2.5rem;
						padding-top: .5rem;

						&:before {
							left: 0;
							content: "\201C";
							position: absolute;
							font-size: 80px;
							line-height: 1;
							color: #999;
							font-style: normal;
						}

						&:after {
							content: "\201D";
							position: absolute;
							font-size: 80px;
							line-height: 1;
							color: #999;
							font-style: normal;
							right: 0px;
						}
					}
					.person {
						margin-top: .5rem;
						font-weight: bold;
						padding-left: 2.5rem;

						span {
							color: #333;
							font-weight: normal;
						}
					}
				}
			}
		}

	}

}

Tiny-slider version:    2.8.2
Browser name && version:   All browsers it seems
I've been going round and  round in circles with this for the last couple of hours, and I still can't see whats going on. Maybe a fresh pair of eyes could see my boo-boo? :)

Ah you star - not sure how I missed removing the flex part in the wrapper! That works like a charm now :)

Glad to hear it works.


feat(devtools): expose selected store as global variable

Refs: #732
Clicking on a store in pinia devtools should make it available as a global variable
https://github.com/vuejs/pinia/assets/22590005/1b6fc1dd-9704-4bea-95cc-8def5f5bbc98

This is nice! Maybe $p is too short. I also think we could have 2 properties:

$pinia for the pinia associated with the store
$store for the store in question

Sorry, I didn't understand, did you mean
assigning $pinia for the root pinia instance, and
assigning variable $store for the current selected store?

https://github.com/vuejs/pinia/pull/2692#issuecomment-2168089160

Implemented in https://github.com/vuejs/pinia/pull/2692/commits/36a56a88f9b1f461e0d746b711404c810bc73c8c
Do you think we should address this feature in the doc?

Is this compatible with the new version of the devtools? It seems to not be working. (I didn't try it on the legacy devtools of the video.)


Zoom fails when the origin changes

Hi my friend, I just came across this issue.
In Android, while you are driving, the zoom fail because origin is constantly changing and the setOrigin functions calls this code
val initialCameraOptions = CameraOptions.Builder()       .zoom(14.0)       .center(origin)       .build()     binding.mapView.mapboxMap.setCamera(initialCameraOptions)
It  will work fine if you move this code into the initNavigation function like this:
`private fun initNavigation() {
if (origin == null || destination == null) {
sendErrorToReact("origin and destination are required")
return
}
val initialCameraOptions = CameraOptions.Builder()  // <== Move here
  .zoom(14.0)
  .center(origin)
  .build()
binding.mapView.mapboxMap.setCamera(initialCameraOptions)

// Start Navigation
startNavigation()
....`

Thanks.

@Nocolais95, Thanks for your feedback


error validating the wrap verification data on mighty-wombat

I see the massive wall of text in the daemon log: https://gist.githubusercontent.com/enolan/387abcf7155865c9b46979b94ec24bf0/raw/0f73f869848a14ff3f388dc55a98c41eaf45909d/verifier__prod%2520error.
I am running a snark worker, so maybe this is a failure validating a SNARK it generated? It hasn't banned any peers. But it looks like it's a blockchain snark since the message includes stuff like has_ancestor_in_same_checkpoint_window, and I'm not running a proposer.
full log here

Ahh sorry this was a log I added to debug why I couldn't verify any SNARKs. It has since been removed, but was present on the might wombat network binaries. It's safe to ignore these logs


Catch missing messages in transformer fn

ibrowse generates a number of other async_* messages which aren't currently caught
transformer function needs to also catch:

:ibrowse_async_response_timeout
:ibrowse_async_raw_req

timeout messages in particular need to be caught since they otherwise leave the calling process hanging.
I have no idea what you would use the "raw_req" option for in practice, but seems sensible to support it since it exists...

Thanks!

Thanks!  Really fast!
Slight curiosity in that I needed to create an extra connection... Seems
that once the connection times out, then you cannot re-use it... Not
quite sure I understand that? Perhaps ibrowse won't re-open connections?
Cheers
Ed W
On 17/05/2017 22:56, Greg wrote:

Thanks!
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/myfreeweb/httpotion/pull/111#issuecomment-302243030,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAA0Nq1OBN2rbkoumBgx8dNDyEjHg_p3ks5r620fgaJpZM4Nee-K.

I don't know. I actually don't use Elixir a lot… or at all really except for maintaining this library :D So I haven't looked into connection reuse.


Feat: Add Navbar to Fruits and Vegetables Pages

Describe the feature
I noticed that the Fruits and Vegetables pages currently do not have a navigation bar (navbar). To improve user experience and site navigation, I recommend adding the navbar to these pages.
Add ScreenShots

Record

[X] I agree to follow this project's Code of Conduct
[X] I'm a GSSOC'24 contributor
[X] I want to work on this issue

I would like to work on this issue. Please assign me this task for GSSoC'24. @himanshu-03

@AsmitaMishra24 This issue already exists

@AsmitaMishra24 This issue already exists

ok..no problem


Revised proposal: Tuples

This design doc takes the information from Bob's original proposal here: #24
It reformats it to the standard RFC format and adds additional information on the currently proposed implementation.
In particular, it details IO formats and some of the implementation challenges.
Rendered version:
https://github.com/WardBrian/design-docs/blob/tuples/designs/0018-tuples.md

This all looks great.  I am sure that these have already been discussed repeatedly and I don't want to bike shed, but a few I have a comments about potential user experience.
What is the motivation for having({ a, b, c }) and ([a, b, c]) be equivalent to (typeof(a), typeof(b), typeof(c))?  If typeof(a) = typeof(b) = typeof(c) won't there be a conflict between (typeof(a), typeof(b), typeof(c)) and the array singleton (array[3] typeof(a, b, c)) or if typeof(a) = typeof(b) = typeof(c) = realthen a conflict between(typeof(a), typeof(b), typeof(c))and the the vector singleton(vector[3])?  This seems like an unnecessary source of confusion when the tuple declarations can just be restricted to (a, b, c)`.
Why the new accessor for individual elements?  Because both arrays and linear algebra use [] to access individual elements the language already has a convention for using [] to access elements of a container.  Given that tuples are just heterogeneous containers it seems like it would be natural to continue this convention and not confuse users with another notation.
I have to say that I'm a huge fan of tuple(T1, T2, T3) instead of (T1, T2, T3).  The extra verbosity is minimal and it emphasizes to users that this is a new container type.  This would also be consistent with the recent move to the more verbose array syntax.  As an additional feature is that this would provide an explicit differentiation between declarations and unpacking,
real a, b, c;
tuple(real, real, real) x = (2, 2, 2);
(a, b, c) = x; // LHS is not the declaration of a variable but temporarily packing existing variables together

verses the more ambiguous
real a, b, c;
(real, real, real) x = (2, 2, 2);
(a, b, c) = x;

Yes the difference between variable names and type names should be enough to separate the two operations but I think that the added redundancy would be more accessible to the majority of the user base (again similar to the array syntax).

What is the motivation for having({ a, b, c }) and ([a, b, c]) be equivalent to (typeof(a), typeof(b), typeof(c))

I’m not sure I follow your question, the snippets you’re referencing are establishing what already exists for arrays and row vectors, not what would be used for a tuple. Tuple values would only use {} or [] if they contain arrays or linear algebra types.

Why the new accessor for individual elements?

Besides being heterogenous, the key distinction between a tuple and an array is that the tuple has a static, fixed size. The use of . instead of [] is useful precisely because it is different - one should consider tuples separately than arrays or linear algebra types, since they cannot be iterated over dynamically and you cannot access them with a variable index, only a raw integer. This style is also how struct access would most likely look if we’re going off of structs in other languages.

I have to say that I'm a huge fan of tuple(T1, T2, T3) instead of (T1, T2, T3).

I generally prefer the more succinct syntax, since I think of the fact that tuple types and values are written down very similarly as a win for understandability, but I take your point with the array syntax as well. I do feel quite strongly about not going so far as to make tuple values look like tuple(1.2, 4), though.
I’m not sure that the unpacking/assignment syntax has any ambiguity if we require parenthesis around the LHS of an unpacking. This is not needed in languages like Python, but it is a decent choice in a statically typed language. That way, if you leave the parenthesis off, it will simply be a type error, e.g
real a, b = (2.5, 3.5)
Will fail, since it will parse as trying to assign a tuple of reals to the singular real variable b.

I’m not sure I follow your question, the snippets you’re referencing are establishing what already exists for arrays and row vectors, not what would be used for a tuple. Tuple values would only use {} or [] if they contain arrays or linear algebra types.

In that case I think the sentence
The expression for creating tuples can follow the array notation ({ a, b, c }) and vector notation ([a, b, c]) and use (a, b, c). This will create a tuple of type (typeof(a), typeof(b), typeof(c)), each subject to the normal promotion rules.
is too confusing as it seems to imply that { a, b, c }),  ([a, b, c]) and (a, b, c) all construct a tuple of type (typeof(a), typeof(b), typeof(c)).

Besides being heterogenous, the key distinction between a tuple and an array is that the tuple has a static, fixed size. The use of . instead of [] is useful precisely because it is different - one should consider tuples separately than arrays or linear algebra types, since they cannot be iterated over dynamically and you cannot access them with a variable index, only a raw integer. This style is also how struct access would most likely look if we’re going off of structs in other languages.

I appreciate this motivation for the different accessor methods, although I think that the initial documentation will have to be very clear and redundant about the differences between tuple containers and array containers.  I think that there will be many “how do I loop over tuples” questions from users who pattern match tuples to how they already use arrays.

I have to say that I'm a huge fan of tuple(T1, T2, T3) instead of (T1, T2, T3).
I generally prefer the more succinct syntax, since I think of the fact that tuple types and values are written down very similarly as a win for understandability, but I take your point with the array syntax as well. I do feel quite strongly about not going so far as to make tuple values look like tuple(1.2, 4), though.

I definitely agree that (1.2, 4) should be sufficient for defining inline tuple values.
In my experience one of the biggest hurdles to learning the Stan language for new users who are used to less strongly/staticly typed languages like R and Python is the type system.  That’s why I think that being as explicit as possible about the type declarations, even at the expense of some mild additional verbosity, will be beneficial overall.

I’m not sure that the unpacking/assignment syntax has any ambiguity if we require parenthesis around the LHS of an unpacking. This is not needed in languages like Python, but it is a decent choice in a statically typed language. That way, if you leave the parenthesis off, it will simply be a type error, e.g
real a, b = (2.5, 3.5)
Will fail, since it will parse as trying to assign a tuple of reals to the singular real variable b.

Sorry I wasn’t referring to formal ambiguity of the compiler but rather cognitive ambiguity of users.  This new type introduces a few new concepts that I think can trip up many users, and I think that language design that explicitly discriminates between type declarations and assignments where appropriate would help ease that burden.

is too confusing as it seems to imply that { a, b, c }), ([a, b, c]) and (a, b, c) all construct a tuple of type (typeof(a), typeof(b), typeof(c)).

I will reword that part, good catch.
Agreed on the point of documentation. In addition to being very clear about the issues you describe, I think it will be important to stress what benefits this provides; e.g., it is possible right now to define a function which returns two real values by settting the return type to array[] real and making a contract with yourself that this will always be length 2. By contrast, if the return type is (real, real) the compiler will make that guarantee for you.
I see your point on the extra verbosity of type declarations, and would like to hear the thoughts of some others (@rybern, @SteveBronder, @bob-carpenter). To be clear, the proposed syntax would look like tuple(int, real, int) = (1, 2.5, 3); in full. A more complicated type could look like array[3] tuple(int, array[2] real)

Agreed on the point of documentation. In addition to being very clear about the issues you describe, I think it will be important to stress what benefits this provides; e.g., it is possible right now to define a function which returns two real values by settting the return type to array[] real and making a contract with yourself that this will always be length 2. By contrast, if the return type is (real, real) the compiler will make that guarantee for you.

Yeah, especially since this (very good) motivation is not the motivation that has long been thrown around for tuples which are ragged arrays.  Users coming to this tuple design thinking that it will allow them to loop over ragged arrays will be frustrated, and so the sooner the documentation can communicate the scope of this tuple type the better.

(@betanalpha) not the motivation that has long been thrown around for tuples which are ragged arrays

I don't know who was thinking that was the motivation, but that was never my intention.  I've always just wanted standard prouct types in the type theoretic sense.  What tuples give you is like a fixed-size, fixed-type version of a list in R.

(@WardBrian) would like to hear the thoughts of some others

I'm OK with either tuple(T1, ..., TN) or (T1, ..., TN) for the type syntax.   So that'd be either,
tuple(real, int, real) x = (2.7, 12, -1e-6);

or
(real, int, real) x = (2.7, 12, -1e-6);

I very much like the idea of being able to follow this with:
real a, c;
int b;
a, b, c = x;

which follows Python convention, or, if necessary for the parser,
a, b, c = x;

so cool!

On May 4, 2022, at 4:48 PM, Bob Carpenter @.***> wrote:
@.*** https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_betanalpha&d=DwMCaQ&c=009klHSCxuh5AI1vNQzSO0KGjl4nbi2Q0M1QLJX9BeE&r=6Ms1ds7pQWLGyUpE515738eqKiCbdfW5Cd4P8GwFGB0&m=A7K8CUV62t1qEq2W6sRzQZDhnlWGkARvhzMvhFeHNtLboQZv5-KNtP-CYutuxfrX&s=48beLXmfBkQI5Bjkby97MaSlwAm_OfXgJwcJUFc5MdQ&e=) not the motivation that has long been thrown around for tuples which are ragged arrays
I don't know who was thinking that was the motivation, but that was never my intention. I've always just wanted standard prouct types in the type theoretic sense. What tuples give you is like a fixed-size, fixed-type version of a list in R.
@.*** https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_WardBrian&d=DwMCaQ&c=009klHSCxuh5AI1vNQzSO0KGjl4nbi2Q0M1QLJX9BeE&r=6Ms1ds7pQWLGyUpE515738eqKiCbdfW5Cd4P8GwFGB0&m=A7K8CUV62t1qEq2W6sRzQZDhnlWGkARvhzMvhFeHNtLboQZv5-KNtP-CYutuxfrX&s=IvnHYYlIM5siBxUjuYbdZ-fBKT0K3-LIBfP54boyvho&e=) would like to hear the thoughts of some others
I'm OK with either tuple(T1, ..., TN) or (T1, ..., TN) for the type syntax. So that'd be either,
tuple(real, int, real) x = (2.7, 12, -1e-6);
or
(real, int, real) x = (2.7, 12, -1e-6);
I very much like the idea of being able to follow this with:
real a, c;
int b;
a, b, c = x;
which follows Python convention, or, if necessary for the parser,
a, b, c = x;
—
Reply to this email directly, view it on GitHub https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_stan-2Ddev_design-2Ddocs_pull_46-23issuecomment-2D1117921604&d=DwMCaQ&c=009klHSCxuh5AI1vNQzSO0KGjl4nbi2Q0M1QLJX9BeE&r=6Ms1ds7pQWLGyUpE515738eqKiCbdfW5Cd4P8GwFGB0&m=A7K8CUV62t1qEq2W6sRzQZDhnlWGkARvhzMvhFeHNtLboQZv5-KNtP-CYutuxfrX&s=cwBuzcRnDoLbZUXOFWE2Wf7CeA5MmXq2O5RoV8-PUB8&e=, or unsubscribe https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AAZYCUPLV4E7HOIXPUE6UXTVILPDTANCNFSM5UDAKVDQ&d=DwMCaQ&c=009klHSCxuh5AI1vNQzSO0KGjl4nbi2Q0M1QLJX9BeE&r=6Ms1ds7pQWLGyUpE515738eqKiCbdfW5Cd4P8GwFGB0&m=A7K8CUV62t1qEq2W6sRzQZDhnlWGkARvhzMvhFeHNtLboQZv5-KNtP-CYutuxfrX&s=CH4AlzS0djFgs0-Y43EfZhRdAwItSNaGRi2Z0Yj1K90&e=.
You are receiving this because you are subscribed to this thread.

The initial tuples PR we have for stanc doesn't support unpacking, but it is something I want to add soon thereafter. I think it will be possible to translate it directly to a std::tie if I read the C++ docs correctly, or we could generate the necessary sequential assignments ourselves.

During today's monthly language meeting, @spinkney and @avehtari both expressed a preference for the syntax tuple(T1, ..., TN) for tuple types, as proposed by @betanalpha.
Aki made the particular point that the more explicit form makes it much easier to search a large program (either with your eyes or with a tool like grep) for tuple types, which has a lot of utility.
Tuple expressions are still made with parenthesis, so a full example is
tuple(real, int, real) x = (2.7, 12, -1e-6);

I'm totally OK with the tuple(...) syntax.

After updating the implementation to match it has grown on me more than I thought. It makes things like nested tuples much more apparent to the eye, (real, real, (real, real)) vs tuple(real, real, tuple(real, real)) is a big difference.

regarding static - was confused by the language - perhaps "slots" makes more sense?
arrays have  a fixed number of dimensions, but the size of each can be specified at runtime.
tuples have a fixed number of slots, known at compile - analogous to number of array dimensions.
I think we need to be explicit to here to avoid confusion between "size" and "dimension".

Agreed, especially in the final user-facing documentation. The analogy to arrays is a good one, but also has its own potential to be confusing since the relationship between different dimensions of an array and different elements in a tuple is not the same


vsTable expand row is broken

VsTable expanded content is not rendered at all since version 3.11.18.
See documentation page for proof: https://lusaxweb.github.io/vuesax/components/table.html#expandable-data
Having to roll back to 3.11.17 with broken select boxes :-/

Same here, hope it's fixed

is it solved?


Add hotkey to Delete a Screen (Cmd-W)

Also fixes "confirm" alerts not closing/canceling when you hit "ESC"

Fix for #181


updating page weights for content/en/docs/concepts/containers

updating page weights for content/en/docs/concepts/containers
contributes to https://github.com/kubernetes/website/issues/35093
@reylejano @natalisucks @bradtopol
updating page weights for content/en/docs/concepts/containers
Confirmation that pages haven't changed order:
original

new

/lgtm
/approve


PfxImport: Cannot find an overload for "Import" and the argument count: "2"

Details of the scenario you tried and the problem that is occurring
I have a PFX as base64 with no password. When I use the pfxImport resource with the Content property and a null Credential, I get the error Cannot find an overload for "Import" and the argument count: "2"
Verbose logs showing the problem
Cannot find an overload for "Import" and the argument count: "2".
    + CategoryInfo          : NotSpecified: (:) [], CimException
    + FullyQualifiedErrorId : MethodCountCouldNotFindBest
    + PSComputerName        : localhost

Exception calling "Add" with "1" argument(s): "pCertContext is an invalid handle."
    + CategoryInfo          : NotSpecified: (:) [], CimException
    + FullyQualifiedErrorId : CryptographicException
    + PSComputerName        : localhost

VERBOSE: [redacted]:                            [[PfxImport]sslImport] Set-TargetResource: Setting Certificate ''
from 'LocalMachine' store 'My' friendly name to 'redacted'. (PI0011)
VERBOSE: [CEESO-PINQ02]: LCM:  [ End    Set      ]  [[PfxImport]sslImport]  in 0.5810 seconds.
The PowerShell DSC resource '[PfxImport]sslImport' with SourceInfo '::23::9::pfxImport' threw one or more
non-terminating errors while running the Set-TargetResource functionality. These errors are logged to the ETW channel
called Microsoft-Windows-DSC/Operational. Refer to this channel for more details.
    + CategoryInfo          : InvalidOperation: (:) [], CimException
    + FullyQualifiedErrorId : NonTerminatingErrorFromProvider
    + PSComputerName        : localhost

Suggested solution to the issue
System.Security.Cryptography.X509Certificates.X509Certificate2.Import does not have an overload that takes two parameters. The Modules/CertificateDsc.Common/CertificateDsc.Common.psm1 module attempts to call the Import method with 2 parameters here.

I think it should be using the overload that includes an empty string for the password.
The DSC configuration that is used to reproduce the issue (as detailed as possible)
Configuration repro
{
    Import-DscResource -ModuleName CertificateDsc -ModuleVersion '5.1.0'

    $sslCertPfxBase64String = Get-AutomationVariable -Name 'ssl-cert'
    $ssl_thumb = Get-AutomationVariable -Name 'ssl-thumb'

    Node "localhost"
    {
        LocalConfigurationManager {
            DebugMode = 'ForceModuleImport'
        }
        pfxImport sslImport {
            Thumbprint           = "$ssl_thumb"
            FriendlyName         = "repro ( $( (Get-Date).ToString('yyyy-MM-dd') ) )"
            Content              = $sslCertPfxBase64String
            Location             = "LocalMachine"
            Store                = "My"
            Credential           = $null
        }
    }
}

The operating system the target node is running
OsName               : Microsoft Windows Server 2019 Datacenter
OsOperatingSystemSKU : DatacenterServerEdition
OsArchitecture       : 64-bit
WindowsVersion       : 1809
WindowsBuildLabEx    : 17763.1.amd64fre.rs5_release.180914-1434
OsLanguage           : en-US
OsMuiLanguages       : {en-US}
Version and build of PowerShell the target node is running
PSRemotingProtocolVersion      2.3
BuildVersion                   10.0.17763.1852
PSVersion                      5.1.17763.1852
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
PSEdition                      Desktop
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
SerializationVersion           <IP_ADDRESS>
Version of the DSC module that was used ('dev' if using current dev branch)
5.1.0

I updated a local copy of the module and confirmed that changing this
$cert.Import($importDataValue, $flags)

to this
$cert.Import($importDataValue, "", $flags)

fixed the issue and the certificate was successfully imported. I am going to submit an initial PR to illustrate the fix.


simplify execution control

I think the system could be simplified greatly. Execution control has two purposes:

Set the includeScriptOutput flag. This is immutable and we can use the ARGO_INCLUDE_SCRIPT_OUTPUT flag.

Fixed in feat(controller) Emissary executor. (#4925) I think.