Use CPU during validation

I have been training a set of CT images (already pre-processed) with two classes in GaNDLF (0.16) on a NVidia 3090 24GB GPU. I think I have set all the settings and hyperparameters to demand the minimal resources possible.
During validation, I seem to run out of VRAM, regardless of the settings I choose. Is it possible to choose to use the CPU during the validation phase only? If not, could it be implemented?
Crash log:
`Creating subjects loader with 2 workers
Looping over training data: 100%|██████████████████████████████████████████████████████████████████████████| 295/295 [16:30<00:00,  3.36s/it]
Epoch Final   train loss :  1.0374998981669799
Epoch Final   train dice :  0.002381664597666044

Starting validation :

Looping over validation data:   0%|                                                                                | 0/15 [00:00<?, ?it/s]/home/hinton/anaconda3/envs/gandlf/lib/python3.8/site-packages/torchio/data/image.py:131: UserWarning: Not specifying the image type is deprecated and will be mandatory in the future. You can probably use tio.ScalarImage or tio.LabelMap instead
warnings.warn(
Looping over validation data:   0%|                                                                                | 0/15 [00:01<?, ?it/s]
Traceback (most recent call last):
File "GaNDLF/gandlf_run", line 100, in
main_run(
File "/home/hinton/gandlf/GaNDLF/GANDLF/cli/main_run.py", line 86, in main_run
TrainingManager(
File "/home/hinton/gandlf/GaNDLF/GANDLF/training_manager.py", line 254, in TrainingManager
training_loop(
File "/home/hinton/gandlf/GaNDLF/GANDLF/compute/training_loop.py", line 399, in training_loop
epoch_valid_loss, epoch_valid_metric = validate_network(
File "/home/hinton/gandlf/GaNDLF/GANDLF/compute/forward_pass.py", line 295, in validate_network
result = step(model, image, label, params, train=True)
File "/home/hinton/gandlf/GaNDLF/GANDLF/compute/step.py", line 81, in step
output = model(image)
File "/home/hinton/anaconda3/envs/gandlf/lib/python3.8/site-packages/torch/nn/modules/module.py", line 1110, in _call_impl
return forward_call(*input, **kwargs)
File "/home/hinton/gandlf/GaNDLF/GANDLF/models/unet.py", line 215, in forward
x = self.de_0(x, x1)
File "/home/hinton/anaconda3/envs/gandlf/lib/python3.8/site-packages/torch/nn/modules/module.py", line 1110, in _call_impl
return forward_call(*input, **kwargs)
File "/home/hinton/gandlf/GaNDLF/GANDLF/models/seg_modules/DecodingModule.py", line 47, in forward
x = self.conv0(self.act(self.in_0(x)))
File "/home/hinton/anaconda3/envs/gandlf/lib/python3.8/site-packages/torch/nn/modules/module.py", line 1110, in _call_impl
return forward_call(*input, **kwargs)
File "/home/hinton/anaconda3/envs/gandlf/lib/python3.8/site-packages/torch/nn/modules/batchnorm.py", line 168, in forward
return F.batch_norm(
File "/home/hinton/anaconda3/envs/gandlf/lib/python3.8/site-packages/torch/nn/functional.py", line 2421, in batch_norm
return torch.batch_norm(
RuntimeError: CUDA out of memory. Tried to allocate 938.00 MiB (GPU 0; 23.69 GiB total capacity; 20.55 GiB already allocated; 827.19 MiB free; 20.89 GiB reserved in total by PyTorch) If reserved memory is >> allocated memory try setting max_split_size_mb to avoid fragmentation.  See documentation for Memory Management and PYTORCH_CUDA_ALLOC_CONF`

# affix version
# Use CPU for validation?
#
version:
  {
    minimum: 0.0.16,
    maximum: 0.0.16 # this should NOT be made a variable, but should be tested after every tag is created
  }
## Choose the model parameters here
model:
  {
    dimension: 3, # the dimension of the model and dataset: defines dimensionality of computations
    base_filters: 16, # Set base filters: number of filters present in the initial module of the U-Net convolution; for IncU-Net, keep this divisible by 4
    architecture: unet, # options: unet, resunet, deep_resunet, deep_unet, light_resunet, light_unet, fcn, uinc, vgg, densenet
    norm_type: none, # options: batch, instance, or none (only for VGG); used for all networks
    final_layer: softmax, # can be either sigmoid, softmax or none (none == regression/logits)
    # sigmoid_input_multiplier: 1.0, # this is used during sigmoid, and defaults to 1.0
    class_list: [0,1,2], # Set the list of labels the model should train on and predict
    # class_list: '[*range(0,100,1)]' # a range of values from 0 to 99 with a step of 1 will be created; customize as needed, but ensure this is defined as a string as it will be passed through 'eval' function
    # class_list: '[0,1||2||3,1||4,4]', # combinatorial training - this will construct one-hot encoded mask using logical operands between specified annotations. Note that double '|' or '&' should be passed and not single to avoid python parsing
    ignore_label_validation: 0, # this is the location of the class_list whose performance is ignore during validation metric calculation
    amp: False, # Set if you want to use Automatic Mixed Precision for your operations or not - options: True, False
    # num_channels: 3, # set the input channels - useful when reading RGB or images that have vectored pixel types from the CSV
    # save_at_every_epoch: True, # allows you to save the model at every epoch
    print_summary: True, # prints the summary of the model before training; defaults to True

    ## densenet models have the following optional parameters:
    # growth_rate (int) - how many filters to add each layer (k in paper)
    # num_init_features (int) - the number of filters to learn in the first convolution layer
    # bn_size (int) - multiplicative factor for number of bottle neck layers
    # (i.e. bn_size * k features in the bottleneck layer)
    # drop_rate (float) - dropout rate after each dense layer
    # num_classes (int) - number of classification classes
    # final_convolution_layer (str) - the final convolutional layer to use
    # norm_type (str) - the normalization type to use

    ## unet_multilayer, unetr, transunet have the following optional parameter:
    # depth (int) - the number of encoder/decoder layers

    ## imagenet_unet has the following optional parameter:
    # pretrained (bool) - if True (default), uses the pretrained imagenet weights
    # final_layer - one of ["sigmoid", "softmax", "logsoftmax", "tanh", "identity"]
    # encoder_name (str) - the name of the encoder to use, pick from https://github.com/qubvel/segmentation_models.pytorch#encoders
    # decoder_use_batchnorm (str) - whether to use batch norm or not or inplace, this will override 'norm_type', see https://github.com/qubvel/segmentation_models.pytorch/blob/master/segmentation_models_pytorch/decoders/unet/model.py
    # decoder_attention_type (str) - the decoder attention type, see https://github.com/qubvel/segmentation_models.pytorch/blob/master/segmentation_models_pytorch/decoders/unet/model.py
    # encoder_depth (int) - the depth of the encoder, also picked up from 'depth'
    # decoder_channels (list) - a list of numbers of channels for each decoder layer, should be same length as 'encoder_depth'
    # converter_type (str) - either acs (targets ACSConv) or conv3d (targets nn.Conv3d) or soft (targets SoftACSConv with learnable weights, default); see https://doi.org/10.1109/JBHI.2021.3049452
    # the following parameters can be used to convert the "imagenet_unet" model to a classifier/regression network; they only come into the picture when the "problem_type" is identified as not segmentation.
    # - pooling (str): One of "max", "avg"; default is "avg"
    # - dropout (float): Dropout factor in [0, 1); default is 0.2
  }
## metrics to evaluate the validation performance
metrics:
  - dice # segmentation
  # - hausdorff # hausdorff 100 percentile, segmentation
  # - hausdorff95 # hausdorff 95 percentile, segmentation
  # - mse # regression/classification
  # - accuracy # classification
  # - classification_accuracy # classification
  # - balanced_accuracy # classification ## more details https://scikit-learn.org/stable/modules/generated/sklearn.metrics.balanced_accuracy_score.html
  # - per_label_accuracy # used for classification
  # - f1 # classification/segmentation
  # - precision # classification/segmentation ## more details https://torchmetrics.readthedocs.io/en/latest/references/modules.html#id3
  # - recall # classification/segmentation ## more details https://torchmetrics.readthedocs.io/en/latest/references/modules.html#id4
  # - iou # classification/segmentation ## more details https://torchmetrics.readthedocs.io/en/latest/references/modules.html#iou
## this customizes the inference, primarily used for segmentation outputs
inference_mechanism: {
  grid_aggregator_overlap: crop, # this option provides the option to strategize the grid aggregation output; should be either 'crop' or 'average' - https://torchio.readthedocs.io/patches/patch_inference.html#grid-aggregator
  patch_overlap: 0, # amount of overlap of patches during inference, defaults to 0; see https://torchio.readthedocs.io/patches/patch_inference.html#gridsampler
}
# this is to enable or disable lazy loading - setting to true reads all data once during data loading, resulting in improvements
# in I/O at the expense of memory consumption
in_memory: False
# this will save the generated masks for validation and testing data for qualitative analysis
save_output: False
# this will save the patches used during training for qualitative analysis
save_training: False
# Set the Modality : rad for radiology, path for histopathology
modality: rad
## Patch size during training - 2D patch for breast images since third dimension is not patched
patch_size: [320,320,320]
# uniform: UniformSampler or label: LabelSampler
patch_sampler: uniform
# patch_sampler: label
# patch_sampler:
#   {
#     label:
#       {
#         padding_type: constant # how the label gets padded, for options, see 'mode' in https://numpy.org/doc/stable/reference/generated/numpy.pad.html
#       }
#   }
# If enabled, this parameter pads images and labels when label sampler is used
enable_padding: True
# Number of epochs
num_epochs: 100
# Set the patience - measured in number of epochs after which, if the performance metric does not improve, exit the training loop - defaults to the number of epochs
patience: 50
# Set the batch size
batch_size: 1
# gradient clip : norm, value, agc
clip_mode: norm
# clip_gradient value
clip_grad: 0.1
## Set the initial learning rate
learning_rate: 0.001
# Learning rate scheduler - options:"triangle", "triangle_modified", "exp", "step", "reduce-on-plateau", "cosineannealing", "triangular", "triangular2", "exp_range"
# triangle/triangle_modified use LambdaLR but triangular/triangular2/exp_range uses CyclicLR
scheduler:
  {
    type: triangle,
    min_lr: 0.00001,
    max_lr: 1,
  }
# Set which loss function you want to use - options : 'dc' - for dice only, 'dcce' - for sum of dice and CE and you can guess the next (only lower-case please)
# options: dc (dice only), dc_log (-log of dice), ce (), dcce (sum of dice and ce), mse () ...
# mse is the MSE defined by torch and can define a variable 'reduction'; see https://pytorch.org/docs/stable/generated/torch.nn.MSELoss.html#torch.nn.MSELoss
# use mse_torch for regression/classification problems and dice for segmentation
loss_function: dcce
# this parameter weights the loss to handle imbalanced losses better
weighted_loss: True
#loss_function:
#  {
#    'mse':{
#      'reduction': 'mean' # see https://pytorch.org/docs/stable/generated/torch.nn.MSELoss.html#torch.nn.MSELoss for all options
#    }
#  }
# Which optimizer do you want to use - sgd, asgd, adam, adamw, adamax, sparseadam, rprop, adadelta, adagrad, rmsprop,
# each has their own options and functionalities, which are initialized with defaults, see GANDLF.optimizers.wrap_torch for details
optimizer: adam
## this parameter controls the nested training process
# performs randomized k-fold cross-validation
# split is performed using sklearn's KFold method
# for single fold run, use '-' before the fold number
nested_training:
  {
    testing: 2, # this controls the testing data splits for final model evaluation; use '1' if this is to be disabled
    validation: 2 # this controls the validation data splits for model training
  }
## pre-processing
# this constructs an order of transformations, which is applied to all images in the data loader
# order: all_methods_as_specified_in_dict --> normalize [normalization methods always applied at the end]
# 'to_canonical': change the image to canonical orientation, see https://torchio.readthedocs.io/transforms/preprocessing.html#torchio.transforms.ToCanonical
# 'rgba2rgb': convert images from rgba to rgb
# 'threshold': performs intensity thresholding; i.e., if x[i] < min: x[i] = 0; and if x[i] > max: x[i] = 0
# 'clip': performs intensity clipping; i.e., if x[i] < min: x[i] = min; and if x[i] > max: x[i] = max
# 'threshold'/'clip': if either min/max is not defined, it is taken as the minimum/maximum of the image, respectively
# 'normalize': performs z-score normalization: https://torchio.readthedocs.io/transforms/preprocessing.html#torchio.transforms.ZNormalization
# 'normalize_positive':perform z-score normalize but with mean and std-dev calculated on only pixels > 0
# 'normalize_nonZero': perform z-score normalize but with mean and std-dev calculated on only non-zero pixels
# 'normalize_nonZero_masked': perform z-score normalize but with mean and std-dev calculated on only non-zero pixels with the stats applied on non-zero pixels
# 'crop_external_zero_planes': crops all non-zero planes from input tensor to reduce image search space
# 'resample: resolution: X,Y,Z': resample the voxel resolution: https://torchio.readthedocs.io/transforms/preprocessing.html#torchio.transforms.Resample
# 'resample: resolution: X': resample the voxel resolution in an isotropic manner: https://torchio.readthedocs.io/transforms/preprocessing.html#torchio.transforms.Resample
# resize the image(s) and mask (this should be greater than or equal to patch_size); resize is done ONLY when resample is not defined -- WARNING: resizing images on the fly ensures that images get loaded in memory, which dramatically increases RAM usage
# 'resize_image' resizes the image and mask BEFORE applying any another operation
# 'resize_patch' resizes the image and mask AFTER extracting the patch
data_preprocessing:
  {
    # 'histogram_matching':{
    #   'target': '/path/to/target/image.nii.gz', # this is the target image to which the histogram of the current image is matched, if this not defined, histogram equalization is performed on the entire image with an equal ramp of [-1,1]
    #   'num_hist_level': 1024, # number of histogram levels
    #   'num_match_points': 16, # number of matching points for histogram matching
    # },
    # 'histogram_equalization':{ # this performs global histogram equalization using the same logic as 'histogram_matching', just without the target
    #   'num_hist_level': 1024, # number of histogram levels
    #   'num_match_points': 16, # number of matching points for histogram matching
    # },
    # 'adaptive_histogram_equalization', # this performs Power Law Adaptive Histogram Equalization using https://simpleitk.org/doxygen/latest/html/classitk_1_1simple_1_1AdaptiveHistogramEqualizationImageFilter.html
    # 'threshold':{
    #   'min': 10,
    #   'max': 75
    # },
    # 'clip':{
    #   'min': 10,
    #   'max': 75
    # },
    # 'normalize',
    # 'normalize_positive', # this performs z-score normalization only on pixels > 0
    # 'normalize_nonZero', # this performs z-score normalization only on non-zero pixels
    # 'normalize_nonZero_masked', # this performs z-score normalization only on masked region
    # 'resample':{
    #   'resolution': [1,2,3]
    # },
    # 'resample_min':{
    #   'resolution': 1, # this will be the maximum spacing (translates to minium resolution) across all axes
    # },
    #'resize_image': [128,128], # this is generally not recommended, as it changes image properties in unexpected ways
    #'resize_patch': [128,128], # this is generally not recommended, as it changes image properties in unexpected ways
    # 'crop_external_zero_planes', # this will crop all zero-valued planes across all axes
    # 'crop': [64,64,64], # this will crop the image by removing specified number of pixels; see https://torchio.readthedocs.io/transforms/preprocessing.html#torchio.transforms.Crop
    # 'centercrop': [64,64,64], # this will crop the image to the specified size from the center of image; see https://torchio.readthedocs.io/transforms/preprocessing.html#croporpad
    ## histogram matching algorithms
    # 'histogram_matching':{
    #   'target': '/path/to/template.nii.gz', # if this is absent, global histogram equalization takes place
    #   # 'target': 'adaptive', # this will perform adaptive histogram matching using https://simpleitk.org/doxygen/latest/html/classitk_1_1simple_1_1AdaptiveHistogramEqualizationImageFilter.html
    # },
    ## stain normalization algorithms
    # 'stain_normalization':{
    #   'target': '/path/to/target.png', # this is required
    #   'extractor': 'vahadane', # can be either vahadane, ruifrok or macenko; defaults to ruifrok
    # }
    ## rescale image
    # 'rescale':{
    #   'in_min_max': [15,125], # desired output intensity range, defaults to min/max of image
    #   'out_min_max': [0,1], # desired output intensity range, defaults to [0,1]
    #   'percentiles': [5,95], # percentile values of the input image that will be mapped to the output range, defaults to [0,100]
    # }
  }
## various data augmentation techniques
# options: affine, elastic, downsample, motion, kspace, bias, blur, gaussianNoise, swap
# keep/edit as needed
# all transforms: https://torchio.readthedocs.io/transforms/transforms.html
# 'kspace': one of ghosting or spiking is picked (randomly) for augmentation
# 'probability' subkey adds the probability of the particular augmentation getting added during training (this is always 1 for normalize and resampling)
data_augmentation:
  {
    default_probability: 1.0, # keeping probability 1.0 to ensure that all augmentations are applied
    # 'affine':{ # for options, see https://torchio.readthedocs.io/transforms/augmentation.html#randomaffine
    #   'scales': [0.5, 1.5],
    #   'degrees': 25,
    #   'translation': 2,
    # },
    # 'elastic',
    # 'kspace':{
    #   'probability': 1
    # },
    # 'motion':{
    #   'probability': 1
    # },
    'bias',
    blur, # this is a gaussian blur, and can take 'std' as a subkey, however, the default 'std' is [0, 0.015 * std(image)]
    ## example of blur with specific std range
    # 'blur': {
    #   'std': [0, 1] # example std-dev range, for details, see https://torchio.readthedocs.io/transforms/augmentation.html#torchio.transforms.RandomBlur
    # },
    'noise': { # for details, see https://torchio.readthedocs.io/transforms/augmentation.html#torchio.transforms.RandomNoise
      'mean': 0, # default mean
      'std': [0, 1] # default std-dev range
    },
    noise_var, # this is a gaussian noise, and can take 'std' and 'mean' as a subkey, however, the default 'std' is [0, 0.015 * std(image)]
    'gamma',
    'swap':{
      'patch_size': 15, # patch size for swapping; if a single number if provided, the same number is used for all axes
      'num_iterations': 50, # number of times that two patches will be swapped, defaults to 100
    },
    'flip':{
      'axis': [0,1,2] # one or more axes can be put here. if this isn't defined, all axes are considered
    },
    'anisotropic':{
      'axis': [0,1],
      'downsampling': [2,2.5]
    },
    'rotate_90':{ # explicitly rotate image by 90
      'axis': [0,2] # one or more axes can be put here. if this isn't defined, all axes are considered
    },
    'rotate_180', # explicitly rotate image by 180; if 'axis' isn't defined, default is [1,2,3]
    # 'colorjitter':{ # this is used to apply the ColorJitter transform form torch - only used for rgb images
    #   'brightness': [0,1], # optional: needs to be between [0,1]
    #   'contrast': [0,0.75], # optional: needs to be between [0,1]
    #   'saturation': [0,0.5], # optional: needs to be between [0,1]
    #   'hue': [-0.25,0.25], # optional: needs to be between [-0.5,0.5] for range and [0,1] for a single value
    # },
  }
# ## post-processing steps - only applied before output labels are saved
# data_postprocessing:
#   {
#     'fill_holes', # this will fill holes in the image
#     'mapping': {0: 0, 1: 1, 2: 4}, # this will map the labels to a new set of labels, useful to convert labels from combinatorial training (i.e., combined segmentation labels)
#   }
## parallel training on HPC - here goes the command to prepend to send to a high performance computing
# cluster for parallel computing during multi-fold training
# not used for single fold training
# this gets passed before the training_loop, so ensure enough memory is provided along with other parameters
# that your HPC would expect
# ${outputDir} will be changed to the outputDir you pass in CLI + '/${fold_number}'
# ensure that the correct location of the virtual environment is getting invoked, otherwise it would pick up the system python, which might not have all dependencies
parallel_compute_command: 'qsub -b y -l gpu -l h_vmem=32G -cwd -o ${outputDir}/\$JOB_ID.stdout -e ${outputDir}/\$JOB_ID.stderr `pwd`/sge_wrapper _correct_location_of_virtual_environment_/venv/bin/python'
## queue configuration - https://torchio.readthedocs.io/data/patch_training.html?#queue
# this determines the maximum number of patches that can be stored in the queue. Using a large number means that the queue needs to be filled less often, but more CPU memory is needed to store the patches
q_max_length: 20
# this determines the number of patches to extract from each volume. A small number of patches ensures a large variability in the queue, but training will be slower
q_samples_per_volume: 1
# this determines the number subprocesses to use for data loading; '0' means main process is used
q_num_workers: 20 # scale this according to available CPU resources
# used for debugging
q_verbose: True

Changing norm_type to "batch" allowed the validation to commence without crashing.


Mnemonics -> ECDSA key -> ECDSA key doesn't yield same public key

Description
I'm recovering a private key from Mnemonics and printing the public key as a string.
I then use the private key string above to instantiate a PrivateKey and print its public key as a string.
The two public keys differ, yet printing both private keys as string yield the same result, see example below
Steps to reproduce
import {
    Mnemonic, PrivateKey,
} from "@hashgraph/sdk";

async function test() {
    const mnemonic = await Mnemonic.fromString("hamster produce dry base sunny bubble disease throw cricket garden beyond script");
    const privateKey = await mnemonic.toEcdsaPrivateKey();

    const privateKeyString = privateKey.toStringRaw();
    const publicKeyString = privateKey.publicKey.toStringRaw();

    // Restore from string
    const restoredPrivateKey = PrivateKey.fromStringECDSA(privateKeyString);
    const restoredPrivateKeyString = privateKey.toStringRaw();
    const restoredPublicKeyString = restoredPrivateKey.publicKey.toStringRaw();

    const results = {
      FromMnemonics: {Private: privateKeyString, Public: publicKeyString},
      ECDSA: {Private: restoredPrivateKeyString, Public: restoredPublicKeyString}
    };
    console.table(results);

}

test();

outputs
┌───────────────┬────────────────────────────────────────────────────────────────────┬──────────────────────────────────────────────────────────────────────┐
│    (index)    │                              Private                               │                                Public                                │
├───────────────┼────────────────────────────────────────────────────────────────────┼──────────────────────────────────────────────────────────────────────┤
│ FromMnemonics │ '63167e08a41aaaa8226945b999a201f789e1a362d4d5b93d605e0841795eb500' │ '0322c1cc8bdbdd54b851251a61ea98d4da31f2749f00e44d66efc2295df76b4a9a' │
│     ECDSA     │ '63167e08a41aaaa8226945b999a201f789e1a362d4d5b93d605e0841795eb500' │ '0283ddc3dfca5dab9c10b4a6be831bae1b50ab36224c305bdd008c6042b34b3123' │
└───────────────┴────────────────────────────────────────────────────────────────────┴──────────────────────────────────────────────────────────────────────┘

Shouldn't both public keys be the same ?
Note, investigating through debugging the SDK shows that the two private keys differ slightly, see below
First key (from mnemonics - chaincode attribute value removed)
{ "_key": { "_keyPair": { "privateKey": { "type": "Buffer", "data": [ 99, 22,
126, 8, 164, 26, 170, 168, 34, 105, 69, 185, 153, 162, 1, 247, 137, 225, 163,
98, 212, 213, 185, 61, 96, 94, 8, 65, 121, 94, 181 ] },
"publicKey": { "type":
"Buffer", "data": [ 3, 34, 193, 204, 139, 219, 221, 84, 184, 81, 37, 26, 97,
234, 152, 212, 218, 49, 242, 116, 159, 0, 228, 77, 102, 239, 194, 41, 93, 247,
107, 74, 154 ] } }
  }

Second key (fromStringECDSA)
Second _key { "_keyPair": { "privateKey": { "type": "Buffer", "data": [ 99, 22,
126, 8, 164, 26, 170, 168, 34, 105, 69, 185, 153, 162, 1, 247, 137, 225, 163,
98, 212, 213, 185, 61, 96, 94, 8, 65, 121, 94, 181, 0 ] },
"publicKey": {
"type": "Buffer", "data": [ 2, 131, 221, 195, 223, 202, 93, 171, 156, 16, 180,
166, 190, 131, 27, 174, 27, 80, 171, 54, 34, 76, 48, 91, 221, 0, 140, 96, 66,
179, 75, 49, 35 ] } }, "_chainCode": null
}

note that the first contains an extra element at the end of the buffer 0, the public key buffer is vastly different.
Additional context
No response
Hedera network
mainnet, testnet, previewnet
Version
v2.19.1 and 2.19.0
Operating system
None

May be related to https://github.com/hashgraph/hedera-sdk-js/issues/1350
Note: Any changes should carefully consider the impact on existing users/accounts.
Accounts created using a public key from mnemonics will not work if they are later recovered and the SDK generates a different public key as a result of the change.
Likewise, accounts created using a public fromString will not work if they are later recovered with the same private key string and the SDK generates a different public key as a result of the change.

Hello @gregscullard and thank you for your issue. We are currently discussing this in the reference issue.
We plan to work as soon as we clear every questions around the refactor.

I don't think this problem is related to the derivation path issue.
@gregscullard Looking at the raw bytes you posted, I'm only counting 31 bytes in the first private key. You say that is what came out of mnemonic.toEcdsaPrivateKey()? Private keys ought to be 32 bytes.
[ 99, 22, 126, 8, 164, 26, 170, 168, 34, 105, 69, 185, 153, 162, 1, 247, 137, 225, 163, 98, 212, 213, 185, 61, 96, 94, 8, 65, 121, 94, 181 ]

This also explains why the next key has an "extra" 0. PrivateKey.fromStringECDSA is probably just blindly reading the values into a properly sized 32 byte array.
Next step is to get confirmation of whether mnemonic.toEcdsaPrivateKey(), always yields a 31 byte key, or if this is intermittent.

We are going to investigate the cryptography package and return with a potential fix.

@gregscullard @alittley
Fixed with the following PR and added an unit test as well. It will be available after the next release of the cryptography package

I think it is very important that we figure out why that particular derivation path is returning a private key of 31 bytes.
Something is very wrong here: the existing (non-hardened) derivation path ought to yield a valid key. [44, 3030, 0, 0] isn't the derivation path we want to be using, but it is still a valid derivation path.
I think merging a fix for this should be delayed for 2 reasons:

We need a full understanding of what is going wrong with the current key derivation. How can it be that a certain derivation path yields non-sensical keys?
IMO even once this has been clarified, the fix should be delayed until the resolution of the mentioned epic. There should be one more change to how keys are handled, and we should be certain that the new implementation is correct.

@alittley That's why we put the PR in draft. We are on the same page that when we clarify the reason, we need to include the fix in the Epic for the Mnemonic refactor. @petreze is still researching it.

@alittley
As I mentioned, whenever we are on the last iteration of indexes of the wrong derivation path hex.decode(secp256k1.keyFromPrivate(ki.toArray()).getPrivate("hex")) returns a ByteArray with 31 length. Since after each iteration, we are overwriting the value of keyData, this last iteration over the second 0 index strongly depends on the previous outcomes when bip32.derive() is called with the other (44, 3030, 0) indexes of the derivation path. This means that by changing the indexes from not hardened to hardened indexes, so from [44, 3030, 0, 0]  to [44 | 0x80000000, 3030 | 0x80000000, 0 | 0x80000000, 0], every private key derived from the previous one will be different if we change the path.
Meaning that, if using the right derivation path, it should generate the correct private key and it does so. We are using elliptic JS library with the secp256k1 elliptic curve and the mentioned line secp256k1.keyFromPrivate(ki.toArray()).getPrivate("hex") comes from there...
Furthermore, we have an unit test inside the cryptography package which compares all of the derived keys, generated from a specific mnemonic, with the predefined correct ones for that same mnemonic phrase described here
So it is safe to say that this should be the right approach

Like I mentioned above, [44, 3030, 0, 0] is one of infinitely many arbitrary, but valid, derivation paths. Even though no one is ever likely to choose it, it should still be possible to do so. No derivation path, even the "wrong" one currently in use, should ever yield a key of 31 bytes.
The fact that we somehow have a derivation path which does yield an invalid key speaks to there being a bug somewhere, whether in the external library, or its usage. Unless there is something fundamental I'm missing here

The oddity in the test sample I provided is that it's a particular set of mnemonics that don't work, mnemonics generated from the current SDK do work.
The unit test may indeed pass, but not with these mnemonics (hamster produce dry base sunny bubble disease throw cricket garden beyond script).

I don't think the linked PR does anything to address the root cause of this issue. Like Greg said, there are weird inconsistencies still happening. This isn't changed by the fact that using a different derivation path makes the issue disappear for a couple test mnemonic phrases.
I would be curious if a test that generates a million different mnemonic phrases and tests their derivation would reveal any other instances of 31 byte keys.

@alittley @gregscullard
I've tested a random mnemonic generation and the behaviour of the SDK
So, whenever we generate a mnemonic with Mnemonic.generate12() (this takes 12 words from the official BIP39 list of words that generate a proper entropy and checksum), there is a chance of getting a 31 bytes key. From the tests, I can conclude that it does not matter if we use the right derivation path [44 | HARDEDED, 3030 | HARDEDED, 0 | HARDEDED, 0] or the wrong one [44, 3030, 0, 0], it can still generate at random times 31 bytes keys
But the randomness does not stop here... As you remember, I mentioned that when we call Mnemonic.toEcdsaPrivateKey() we iterate over the indexes of the derivation path and on each iteration, we overwrite the previous private key value with the newly derived key data.
So lets say we are using [44, 3030, 0, 0] derivation path (for simplicity).

the first iteration over index 44 yields pk1 which is the returned keyData value
the second one iterates over index 3030 with pk1 as parentKey and it returns the derived key pk2 from its parent key pk1
this process continues until we get to the last index and the last returned value is in fact the private key at this specified path

The strange behaviour where we can get a 31 bytes private key could happen on each of these iterations randomly for a random mnemonic phrases. It just happened that in Greg's case the last iteration returns 31 bytes key and we found the bug but up until now I could not find any relations between the generated mnemonics and the cases where we yield 31 bytes

@petreze @ochikov It sounds to me like the bug is in bip32::derive.
In particular, I'm suspicious of this return statement
        return {
            keyData: hex.decode(         // << suspicious
                secp256k1.keyFromPrivate(ki.toArray()).getPrivate("hex")
            ),
            chainCode: IR,
        };

hex.decode must be returning an array without 0 padding in the case that the most significant byte of the resulting key is 0x0. I believe this case should arise 1/16 times (ouch).

@alittley
Will investigate that, but yes this part is a bit uncertain and one of my suggestions was also that statement, since the other part of the derive functionality LGTM

@alittley
Hello Austin, I think the issue might be in fact returning an array without 0 padding in the case that the most significant byte of the resulting key is 0x00
I dug into ethers.js implementation of how they handle the situation.
They are using bytes32 function in order to generate the private key on each index iteration. Under the hood it uses hexZeroPad which I think handles the 0 padding case
In our implementation, as I mentioned elliptic JS library is used for the whole generation and derivation of the private keys and there is an option for the toArray() method to specify the endian and zero pad to length if already exceeding
Basically the equivalent of their implementation. When I set the length to 32, it always generates 32 bytes private keys.. but the test with the predefined mnemonic to set of private key derivation fails. This is defined here and it was the only test for correctly generated and derived ecdsa private keys in our SDK

@alittley
Short update
The functionality from the library did not work, so I've implemented the zero padding in the SDK itself. I also added an ecdsa generation from a specific mnemonic with the default ethereum derivation path 44'/60'/0'/0/0 which is used to test in ethers.js as well. Everything is pushed in the same branch so you can check it

@ochikov @petreze I'm not sure if it has been discussed yet, but the fix here requires separate consideration from the derivation path bug.
Whereas a "compatibility mode" for keys generated at the incorrect derivation path can be achieved by manually specifying the old path, that won't be possible for keys that fall victim to this derivation bug. The existing bad bip32 derivation implementation will have to be preserved in some way, to rescue the ~1.6% of people who are affected by this additional bug.

Fixed with PR


I would ❤ to see this turned into a project time tracker (a la Harvest sort of thing)

Cause I was looking for one that wasn't over the top crazy and could just log things, though looking for a human readable text file format for recording (I use taskpaper and ledger... don't act surprised... =] ).
Anyhow, like it... my favourite part is the "Moro \o/"...

Hi @wakatara!
Thanks for showing some love :)
I'm not sure Moro is a good fit for a full blown task manager. As it's aimed for 9 to 5 jobs with flexible hours.
We addes the notes feature, so that users can remember when they switched task during the day.
But please go ahead and share your ideas as feature requests or pull requests. We'll see how it can stay simple, and satisfy your needs too.
Omid

Heya @omidfi !
Fair enough. =]
I do need a proper project time tracker though, so lemme see if I can make the changes within moro's as PRs and if not I'll just use your stuff as a base and fork (Moar-o?... =p ). I wanted to do the thing in js and as a cli so this is definitely great as a base if I do. Will keep you posted!

Cool :)
I think it doesn't exist in the JS world as far as I know. It would be
appreciated.
Take a look at other ecosystems, there are good examples like Time Strap,
task warior etc.
ti 6. kesäkuuta 2017 klo 9.37 Daryl Manning<EMAIL_ADDRESS>kirjoitti:

Heya @omidfi https://github.com/omidfi !
Fair enough. =]
I do need a proper project time tracker though, so lemme see if I can make
the changes within moro's as PRs and if not I'll just use your stuff as a
base and fork (Moar-o?... =p ). I wanted to do the thing in js and as a cli
so this is definitely great as a base if I do. Will keep you posted!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/omidfi/moro/issues/82#issuecomment-306395811, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AHV04NqiTaA7JNwyui6PG_TzWR3Lu4PUks5sBPOcgaJpZM4NvUry
.


feat(ci): Conditional Release Workflow

Description
Conditionally execute the release on ci and tag creation workflow success.

Current dependencies on/for this PR:

main

PR #38   👈

This comment was auto-generated by Graphite.


feat: upgrade packages

This has changes for Vue 3 migration

@chatwoot/frontend take note, I'll be making a separate tagged release on npm next. Use pnpm i @chatwoot/prosemirror-schema@next to install that. The regular install should work as it is. I'll get this PR merged soon


Maven Standard Directory Layout compatibility and fixing -sources artifact.

maven-sources-plugin simply jars the sourceDirectory to create the
-sources artifact. We don't have empty dirs for the package path and
there's no way to configure maven-sources-plugin to prepend path. Create
a .mvn-compat directory at top level and symlink it
src/main/java/ to top level src/ directory.
Update's pom.xml.in' with the new sourceDirectory' and while there add
the missing version decleration to maven-sources-plugin and update
maven-jar-plugin.
closes #1

Thanks, merged as stumbleupon/async@331f624c6d70c1dd897c7d3e79139f007ba68a78.


Why so much memory using by node

var redis = require("redis"),
client = redis.createClient();
for(var i =0 ; i < 1000000; i++){
client.publish('channel_1', 'hello!');
}
after code is executed, node.js process allocate 1,2GB of memory; nothing happen; GC does not reduce allocated memory. if it will be 2 million messages or 4x500000, node crashes with memory error.
Node: 0.8.* ,  after this i trying 4.1.1 , but nothing changed
redis: 2.8 , work good 1Mb allocated memory.

This code synchronously creates a large number of strings channel_1, "hello!", and functions and appends all of those to an array that grows to be 1e6 elements long.
If you select a number high enough, Node will be allocating too much JS heap and pass the V8 1.5gb limit.
Garbage collection can't run until these things aren't referenced anymore, which won't be until after the callbacks have fired for each of these functions.
Your best bet is to spread these out over multiple event-loop hops by doing something like batches of ~100 at a time.

Just a general question about the behavior which relates to this.
If I were to execute
var redis = require("redis"),
    client = redis.createClient();

for (var i = 0; i < 1000000; i++) {

    // please note the 0ms timeout here
    setTimeout(function() {
        client.publish('channel_1', 'hello!');
    }, 0);

}

Would that give Node(-redis) the chance to run GC in between of cycles?

@jdegger this should work, yes.

After looking at it again, this is actually likely not going to work, as you create all timeouts sync with the same timeout. They might/should therefor be called in the same tick and this would result in just the same as @brycebaril already mentioned.


ConsumerWidget documentation doesn't match with Api Reference

This documentation
https://riverpod.dev/docs/concepts/reading#consumerwidget
doesn't match with this
https://pub.dev/documentation/flutter_riverpod/latest/flutter_riverpod/ConsumerWidget-class.html

The api reference is using 0.14.0
The documentation is using 1.0.0-dev.x
So this is expected

Oh, sorry, My mistake.
El mié, 23 jun 2021 a las 10:14, Remi Rousselet @.***>)
escribió:

Closed #537 https://github.com/rrousselGit/river_pod/issues/537.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/rrousselGit/river_pod/issues/537#event-4928762558,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEX4UXXWGUS2MAKFCXE6KGDTUHM4TANCNFSM47FYVWDQ
.


Add infrastructure for test projects using IndexStoreDB's "Tibs"

This builds on the indexer changes (https://github.com/apple/indexstore-db/pull/32) to support test projects using the tibs build system. See the commit message from IndexStoreDB for more information.
This commit adds a couple of simple tests using test fixtures in the INPUTS directory. It is a fairly minimal change for using the indexer's test support code to prove the model works. One missing piece here is support for mutable sources and updating the index, which is supported on the IndexStoreDB side, but needs a bit more work here.  This also doesn't include any tests using swiftpm's build system.

https://github.com/apple/indexstore-db/pull/32
@swift-ci please test

apple/swift#26300
apple/indexstore-db#32
@swift-ci please test

apple/swift#26300
apple/indexstore-db#32
@swift-ci please test


Add BEGIN event. Set the limit to 'All jobs' in case of 0 as value

I have added a feature to scrape the total number of jobs and included this number in a new BEGIN event. If the limit is set to zero, it will now default to the total job count. I have also updated the README to reflect these changes.
While this number may not strictly indicate how many jobs are available for scraping, it can provide an estimate of how long the entire process might take. It’s worth noting that currently, LinkedIn does not provide more than 1000 jobs per query (no jobs or irrelevant jobs appear after skip=1000).
As I am not a Python expert, any feedback or criticism is welcome.

Hi there!
I am not sure I understand what is the purpose of the BEGIN event. How do you plan to use it?
Btw I am ok for adding the option to have limit=0 -> all jobs 😉

Firstly, upon reviewing the diff, I noticed that more commits than intended were included in this PR. My apologies for the oversight. I can close this PR and split the changes into a few different PRs.
As for the begin event, the main purpose is to show how many jobs will be parsed beforehand. I see at least two useful applications:

It allows for an estimation of the time required for parsing.
It helps handle unusual behavior from LinkedIn. For instance, currently, LinkedIn returns no jobs after https://www.linkedin.com/jobs/search/....&start=1000, even if the query yields more than 1000 jobs. In this case, the user (me) can react to this before parsing happens.


Unpacking of the archive on deploy should also install dependencies if necessary

Fixed in 1.0.0-alpha.1


added publishedAt and tag to Relay subscription models

@jakubuid  Specs: https://specs.walletconnect.com/2.0/specs/servers/relay/relay-server-rpc#subscription-payload


ERROR: Config value 'gpu' is not defined in any .rc file

root@in-dev-docker:/apollo# ./apollo.sh build
[INFO] Apollo Environment Settings:
[INFO]     APOLLO_ROOT_DIR: /apollo
[INFO]     APOLLO_CACHE_DIR: /apollo/.cache
[INFO]     APOLLO_IN_DOCKER: true
[INFO]     APOLLO_VERSION: master-2021-08-27-a3f5f72
[INFO]     DOCKER_IMG: dev-x86_64-18.04-20210426_0123
[INFO]     APOLLO_ENV:  STAGE=dev USE_ESD_CAN=false
[INFO]     USE_GPU: USE_GPU_HOST=1 USE_GPU_TARGET=1
[ OK ] Running GPU build on x86_64 platform.
[WARNING] ESD CAN library supplied by ESD Electronics doesn't exist.
[WARNING] If you need ESD CAN, please refer to:
[WARNING]   third_party/can_card_library/esd_can/README.md
[INFO] Build Overview:
[INFO]     USE_GPU: 1  [ 0 for CPU, 1 for GPU ]
[INFO]     Bazel Options: --config=gpu
[INFO]     Build Targets: //modules/... union //cyber/...
[INFO]     Disabled:      except //modules/drivers/canbus/can_client/esd/...
WARNING: The following rc files are no longer being read, please transfer their contents or import their path into one of the standard rc files:
/apollo/tools/bazel.rc
ERROR: Config value 'gpu' is not defined in any .rc file

could you pls try  ./apollo.sh build --config=cpu

Missing the file https://github.com/ApolloAuto/apollo/blob/master/.bazelrc. You could create and copy file under apollo folder.

root@in-dev-docker:/apollo# ./apollo.sh build [INFO] Apollo Environment Settings: [INFO] APOLLO_ROOT_DIR: /apollo [INFO] APOLLO_CACHE_DIR: /apollo/.cache [INFO] APOLLO_IN_DOCKER: true [INFO] APOLLO_VERSION: master-2021-08-27-a3f5f72 [INFO] DOCKER_IMG: dev-x86_64-18.04-20210426_0123 [INFO] APOLLO_ENV: STAGE=dev USE_ESD_CAN=false [INFO] USE_GPU: USE_GPU_HOST=1 USE_GPU_TARGET=1 [ OK ] Running GPU build on x86_64 platform. [WARNING] ESD CAN library supplied by ESD Electronics doesn't exist. [WARNING] If you need ESD CAN, please refer to: [WARNING] third_party/can_card_library/esd_can/README.md [INFO] Build Overview: [INFO] USE_GPU: 1 [ 0 for CPU, 1 for GPU ] [INFO] Bazel Options: --config=gpu [INFO] Build Targets: //modules/... union //cyber/... [INFO] Disabled: except //modules/drivers/canbus/can_client/esd/... WARNING: The following rc files are no longer being read, please transfer their contents or import their path into one of the standard rc files: /apollo/tools/bazel.rc ERROR: Config value 'gpu' is not defined in any .rc file

I have also encountered the same problem, how to can i sovle this problem?


rtl doesn't work

short description of the bug / issue, provide more detail below.

Slick doesn't show slides
when infinite is on true nothing is show instead when it is on false it is shown only the first slide
====================================================================
https://jsfiddle.net/maofree/z7eq6azg/3/
====================================================================
Steps to reproduce the problem
it happens on all examples
====================================================================
More Details

Which browsers/versions does it happen on?  firefox 54.0.1 on linux
Which jQuery/Slick version are you using? last slick.js 1.6
Did this work before?

thanks
bye

Did you add dir="rtl" to the slider parent o html element?

Hi
I don't know that, however I'll try it tomorrow
thanks

do you suggest like that?

slide1
slide2
slide3
slide4
slide5
slide6

I've updated the example on jsfiddle but I get the same error

Yes, but I think you have to change this attribute depending on your breakpoint
JSFiddle

Hi
thanks makshh
I've understood how it works
bye

Would you please share ? Thanks ! :)

Please help I have used dir = rtl the slides not working properly only first is showing
that also when infinite is turned off

Please help I have used dir = rtl the slides not working properly only first is showing
that also when infinite is turned off
clicking next slides slider but slide seems to be in ltr direction empty slide sliding in.

Try used dir = ltr. For example add to
.slick-slider .slick-track, .slick-slider .slick-list {
direction: ltr;
}
It will works)

@mostafazs thank you so much!!!!

This works for me:
[dir='rtl'] .slick-slide
{
    float: left;
}

and
.slick-slider .slick-track, .slick-slider .slick-list {
direction: ltr;
}

Thanks a lot!


NPE in com.badlogic.gdx.scenes.scene2d.ui.Cell

Since uniformX, uniformY fields are wrapper boolean classes and getUniformX(), getUniformY() return non-wrapper boolean, cell.getUniformX and cell.getUniformY methods may result in NPE instead of returning null.
Boolean uniformX, uniformY;

public boolean getUniformX () {
	return uniformX;
}

public boolean getUniformY () {
	return uniformY;
}

True, I suppose these methods would be better returning @Null Boolean.


chore: release main

:robot: I have created a release beep boop
node-versions: 2.0.4
2.0.4 (2024-09-09)
Dependencies

The following workspace dependencies were updated

dependencies

@rowanmanning/package-json bumped from ^1.0.2 to ^1.0.3

npm-dependencies: 1.1.1
1.1.1 (2024-09-09)
Bug Fixes

relax package version requirement (d4ed9af)

Dependencies

The following workspace dependencies were updated

dependencies

@rowanmanning/npm-workspaces bumped from ^1.0.1 to ^1.0.2
@rowanmanning/package-json bumped from ^1.0.2 to ^1.0.3

npm-workspaces: 1.0.2
1.0.2 (2024-09-09)
Dependencies

The following workspace dependencies were updated

dependencies

@rowanmanning/package-json bumped from ^1.0.2 to ^1.0.3

package-json: 1.0.3
1.0.3 (2024-09-09)
Bug Fixes

relax package version requirement (d4ed9af)

package-json-github: 1.0.3
1.0.3 (2024-09-09)
Dependencies

The following workspace dependencies were updated

dependencies

@rowanmanning/package-json bumped from ^1.0.2 to ^1.0.3

This PR was generated with Release Please. See documentation.

:robot: Created releases:

node-versions-v2.0.4
npm-dependencies-v1.1.1
npm-workspaces-v1.0.2
package-json-v1.0.3
package-json-github-v1.0.3
:sunflower:


Can't get linux version of BSQL to work

I can't get SQL to work on the docker version of tgstation.
I get the error: [10:50:35] Runtime in library.dm,4: Unable to load library /root/.byond/bin/libBSQL.so
Here's the log for the round: https://gist.github.com/HiddenKn/8cb994b83be35c20497aa333b28b2d38
MariaDB version: Server version: 10.2.20-MariaDB-1:10.2.20+maria~bionic-log mariadb.org binary distribution
ldd output:
/tgstation/libBSQL.so: /usr/lib/i386-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.22' not found (required by /tgstation/libBSQL.so)
linux-gate.so.1 =>  (0xf77b7000)
libmariadb.so.2 => not found
libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xf75eb000)
libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xf75ce000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf7418000)
libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xf73c3000)
/lib/ld-linux.so.2 (0xf77b8000)
I tried compiling it manually as well on my ubuntu server but ran into the same issue.
I can connect to the mysql server manually using the mysql command.

@HiddenKn Im REALLY ate on a response to this, but there's a dependency not listed, gcc++ and c++ libraries are necessary to get the libraries functional on linux, try these commands:
sudo apt-get install build-essential
sudo apt-get install gcc-multilib
sudo apt-get install g++-multilib
sudo apt-get install gcc-4.8-multilib
sudo apt-get install g++-4.8-multilib`

Thanks for letting me know!


[spi_passthru] SPI passthru test plan

Description
SPI Passthrough Testing
Introduction
This document discusses the tests needed to verify OpenTitan SPI Passthrough.
EEPROM Parts
Since SPI passthrough puts the OpenTitan chip in the position of a SPI interposer, we need a set of EEPROM parts to serve a representatives of EEPROMs we would expect an OpenTitan user to connect to OpenTitan’s SPI_HOST.
Test Cases
Built-in Interposer Opcodes
Tests need to make sure these opcodes return the correct data from the interposer register or memory space and/or set appropriate status/control bits in the interposer.

READ_ID (read Jedec ID)
READ_SFDP
READ_STATUS
WRITE_{ENABLE, DISABLE} (interacts with the status register)
EN4B, EX4B (enter/exit 4-byte address mode)

Read Opcodes
The following opcodes are expected to flow through the interposer to the backing EEPROM.  Their address phase may be subject to the address translation capabilities of the interposer.

READ
FAST_READ
FAST_DUAL_READ (aka DREAD)
FAST_QUAD_READ (aka QREAD)

Note: 2READ and 4READ opcodes operate in SPI 1-2-2 and 1-4-4 modes and are not supported by the interposer.
All of the prior commands are subject to the address mode of the chip as controlled by EN4B and EX4B.  There are also versions of all of the prior commands that always accept a 4-byte address.  They have the same names as the prior list with “4B” appended to the name: READ becomes READ4B.
Intercepted Opcodes
The remaining opcodes provide EEPROM erase and write functionality.  Typically, firmware will capture these commands, evaluate the requested operation and regenerate the opcode to the backing eeprom.

PP (PAGE_PROGRAM)
SE (SECTOR_ERASE)
BE32K (Block Erase 32K)
BE64K (Block Erase 64K)
CE (CHIP_ERASE)

As with the read opcodes, the above opcodes (except chip_erase) are subject to the address mode and have exclusive 4-byte versions with “4B” appended to the name.
Opcode Filtering
There are several opcodes (often vendor extensions) which control the state of the backend EEPROM.  For example, the WREAR (write extended address register) provides a mechanism for an upstream SPI host to address the full 4-byte address space via 3-byte addressing.  Generally, we don’t support this type of extended addressing through the interposer and should an upstream SPI_Host send this opcode, we’d want to prevent it from affecting the backend EEPROM.
Test Matrix
The following SPI opcodes should have tests.

Opcode
FW Intercept
3b/4b mode
Address Translation
Notes
PR #

READ_ID
No
N/A
N/A
SPI_D Register.
cfrantz #17426

READ_SFDP
No
N/A
N/A
SPI_D RAM.
cfrantz #17452

READ_STATUS1
No
N/A
N/A
SPI_D Register.  WIP bit should be set by intercepted commands.
cfrantz #17429

WRITE_STATUS1
Yes
N/A
N/A
SPI_D Register.
cfrantz #17469

READ_STATUS2
No
N/A
N/A
SPI_D Register (status bits 15:8).
cfrantz #17429

WRITE_STATUS2
Yes
N/A
N/A
SPI_D Register (status bits 15:8).
cfrantz #17469

READ_STATUS3
No
N/A
N/A
SPI_D Register (status bits 23:16).
cfrantz #17429

WRITE_STATUS3
Yes
N/A
N/A
SPI_D Register (status bits 23:16).
cfrantz #17469

WRITE_ENABLE
No
N/A
N/A
Affects WEN bit in status.
cfrantz #17429

WRITE_DISABLE
No
N/A
N/A
Affects WEN bit in status.
cfrantz #17429

EN4B
No
N/A
N/A
Affects SPI_D notion of 3b/4b mode.
cfrantz #17429

EX4B
No
N/A
N/A
Affects SPI_D notion of 3b/4b mode.
cfrantz #17429

READ (1-1-1)
No
Yes
Yes
No dummy cycles.
a-will #17497

DREAD (1-1-2)
No
Yes
Yes

cfrantz #18292

QREAD (1-1-4)
No
Yes
Yes

cfrantz #18292

FAST_READ (1-1-1)
No
Yes
Yes
Dummy cycles. Traditionally, 8.
cfrantz #18292

READ4B (1-1-1)
No
N/A
Yes
Not supported on CW310

DREAD4B (1-1-2)
No
N/A
Yes
Not supported on CW310

QREAD4B (1-1-4)
No
N/A
Yes
Not supported on CW310

FAST_READ4B (1-1-1)
No
N/A
Yes
Not supported on CW310

PP
Yes
Yes
In software

cfrantz #17482

SE
Yes
Yes
In software

cfrantz #17469

BE32K
Yes
Yes
In software

cfrantz #18377

BE64K
Yes
Yes
In software

cfrantz #18377

PP4B
Yes
N/A
In software
Not tested.  Perform as a manual test.

SE4B
Yes
N/A
In software

cfrantz #18377

BE32K4B
Yes
N/A
In software

cfrantz #18377

BE64K4B
Yes
N/A
In software

cfrantz #18377

CE
Yes
N/A
N/A

cfrantz #17469

Notes:

#17572 added READ tests with address translation.
#17606 added READ tests targeting the mailbox.
#17615 enhances the SPI flash emulator to handle BE32K, BE64K, PP4B, SE4B, BE32K4B and BE64K4B opcodes.

The passthru filter write slots are full after #17615.
The passthru filter read slots have 2 entries available.

Not supported on CW310: The IS25WP016 EEPROM on the CW310 board does not support any 4B operations and these opcodes flow through the interposer to the EEPROM.  The can be tested by replacing the IS25WP016 part with a larger eeprom.

Manual testing
The spi_passthru_test can be placed into "spi flash emulator" mode by entering the string "SpiFlashEmulator" (with the quotes) at the OpenTitanTool console.  The test will respond with:
I00001 spi_flash_emulator.c:120] Configuring spi_flash_emulator.
I00002 spi_flash_emulator.c:124] Setting the EEPROM's QE bit via mechanism 2
I00003 spi_flash_emulator.c:127] Starting spi_flash_emulator.

At this point, one can issue any spi transaction via the opentitantool spi command hierarchy:
opentitantool --interace=<cw310|hyper310> spi sfdp
... SFDP table ...

@engdoreis / @luismarques - FYI, to avoid duplication while performing https://github.com/lowRISC/ot-discrete-eg/issues/10

@moidx - based on yesterday's notes it sounded like this had been completed?

Hi @cfrantz, please feel free to close if you are satisfied with the manual checks. I believe all other tests have been merged.

@a-will @cfrantz can you double check whether this can be closed?

I've re-run //sw/device/test:spi_passthru_test locally via the cw310 and hyper310 interfaces (the latter required to check dual and quad SPI modes).  Both passed.

Thanks @cfrantz!


Update builder to check mixins for toJson

updated _validJsonReturnTypeCore to also check a type's mixins for valid toJson methods

fixes #216

I'd love to have a test for this!
Could we get a test in here, @nickmeinhold ?

Will do, thanks!

Friendly ping, @nickmeinhold – or I may take a look

Thanks for the ping @kevmoo!  Sorry for the delay, the task was more than I expected due to being new to testing custom builders with build_test.  I got distracted but came back and spent some time on this yesterday and will work on it again today.  Please don't let me get in the way if you want it finished or closed though.  Thanks!

I've added a test, sorry again for the delay... starting to get my head around using build_test at least!

@nickmeinhold try this:
diff --git a/functions_framework_builder/lib/src/valid_json_utils.dart b/functions_framework_builder/lib/src/valid_json_utils.dart
index bf86a87..2f4f886 100644
--- a/functions_framework_builder/lib/src/valid_json_utils.dart
+++ b/functions_framework_builder/lib/src/valid_json_utils.dart
@@ -99,15 +99,12 @@ JsonReturnKind _validJsonReturnTypeCore(DartType type) {

   // Look for a `toJson` function that returns a JSON-able type
   if (type is InterfaceType) {
-    final toJsonMethod = [
-      type.getMethod('toJson'),
-      ...type.mixins.map((mixin) => mixin.getMethod('toJson'))
-    ].firstWhere(
-        (element) =>
-            element != null &&
-            element.parameters.every((element) => element.isOptional),
-        orElse: () => null);
-    if (toJsonMethod != null) type = toJsonMethod.returnType;
+    final toJsonMethod =
+        type.element.lookUpMethod('toJson', type.element.library);
+    if (toJsonMethod != null &&
+        toJsonMethod.parameters.every((element) => element.isOptional)) {
+      type = toJsonMethod.returnType;
+    }
   }

   return _validJsonType(type, true)

lookUpMethod is where we should go here!

Thanks @kevmoo!  Updated.  That's so much nicer.  Great to know about lookupMethod too!


feat: metrics deploy command

Fixes #610
Checklist

[x] Documented
[ ] Unit tested
[ ] Component tested
[ ] Driver tested

Thanks @radekdymacz !


Invalid image data for SVG images

SVG image is not working when I try to add

My workaround for this is to convert the SVG image to PNG format, using something like https://svgtopng.com


Add ability to filter notification event based on Labels

What this PR does / why we need it:
Which issue(s) this PR fixes:
Fixes #3230
Does this PR introduce a user-facing change?:

Enable filter notifications based on application/deployment's labels

Nice. Thank you.
/approve


make check fails on macOS Monterey (macos-12)

We're trying to update libmaxminddb for Homebrew at Homebrew/homebrew-core#111943. We encountered the following failure in make check:
  not ok 1 - No libs were found to test
  #   Failed test 'No libs were found to test'
  #   at ./external_symbols_t.pl line 53.
  1..1

Complete CI logs available at https://github.com/Homebrew/homebrew-core/actions/runs/3148372901.
The error for ARM Monterey can be found here, and on Intel Monterey here.
Any assistance would be appreciated.

Can you confirm that make check with 1.6.0 worked on Monterey? I don't know of any relevant differences, but it would narrow the possibilities.

It did, yes. We distribute binaries of 1.6.0 built on Monterey, and we run make check during every build of libmaxminddb.
Note, however, that the build environment from when we were able to build 1.6.0 on Monterey and the one where we are seeing failures now is not exactly identical: we've upgraded to Xcode 14 since then, and we've likely upgraded to a newer minor version of Monterey too. Our build of 1.6.0 was built with Xcode 13.1.
I mention this because we've seen other issues with Xcode 14 (e.g. iains/gcc-12-branch#6). The linked issue is a linker bug -- I'm not sure if that could have anything to do with the failing test.
I'm not aware of instances of minor version upgrades ever causing regressions.

Would it be possible to force a rebuild of 1.6.0 with the newer environment? I just reviewed the diff and I don't see anything that is obviously related to this issue. It seems much more likely to be an environment issue (e.g., some sort of automake change).

I was able to find a macOS user internally who reproduced the failure. It appears that it isn't specific to this release, but also happened with 1.6.0. I suspect previous builds by Homebrew had that test skipped due to missing test dependencies and upgrading Xcode caused those dependencies to be available.
We will likely just skip that test on non-Linux systems as it appears to assume a Linux-like environment and it is primarily beneficial as an author test rather than testing that the build was successful.

Thanks for the lightning-quick fix!


Feature/add formal labels to objects

Detail -> #128

This change is

Reviewed 11 of 11 files at r1.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable


1.3.4

1.3.4

Coverage decreased (-0.1%) to 97.82% when pulling f18c36edf2b67307b474f74d17f308f2c59a39c8 on development into 8a6a9635e36031c27f3ba6d8072dc0cb82235669 on master.


Integer conversion to unsigned

It is possible to assign negative json value to unsigned variable.
This is a possible patch
diff --git a/src/json.hpp b/src/json.hpp
index edda8ed..a8c85e5 100644
--- a/src/json.hpp
+++ b/src/json.hpp
@@ -2316,7 +2316,12 @@ class basic_json
         {
             case value_t::number_integer:
             {
-                return static_cast<T>(m_value.number_integer);
+                auto res = m_value.number_integer;
+                if(std::is_unsigned<T>::value && res < 0) {
+                    throw std::domain_error("can't assign negative value to unsigned type");
+                } else {
+                    return static_cast<T>(res);
+               }
             }

             case value_t::number_float:

It is possible that the value was unsigned in the json, and was converted to a negative value for storage in the json object.  It would have to be a really big unsigned number with the default storage size being int64_t, but it's still possible.  The json object would need to store additional data to know whether it was negative or not originally.

It would be better to check integer size and signedness in parser. Successfuly parsed json should contain valid data.
I forgot that NumberIntegerType can be changed, and even be unsigned, condition for conversion check should be like this:
if(std::is_unsigned<T>::value && std::is_signed<NumberIntegerType>::value && res < 0)

Another possibility is to remove static_cast and let the user handle conversions. But I'm not sure that it will not break API.
Anyway, silent incorrect conversion is not a good thing.

I think this also has the possibility to break existing programs, though at runtime rather than compile time.  Currently, if someone populates a json object with an unsigned integer value larger than the max size for NumberIntegerType, it will be encoded in the JSON string as signed.  Parsing that string and extracting the value as unsigned will currently produce the same result as the original input.  This change would make it throw an exception instead.

If it really ignores integer overflow and does not differentiate between signed and unsigned. At least this behavior should be noted in documentation.
For now i removed static_cast to get compiler errors and made validating wrapper, but considering above, it is possible that value would be in fact undefined in result of overflow or signedness conversion.
Simple example - some 3rd party app can send my app json with integer which need 128 bits, I expect deserialization of this value to fail, not to get invalid value.

@gregmarr, I might be missing something but why would a large unsigned value in the JSON be stored as a negative number in the object?
Wouldn't this (in parser::parse_internal() at 7880) cause it to be stored as a NumberFloatType:
// check if conversion loses precision
const auto int_val = static_cast<number_integer_t>(float_val);
if (approx(float_val, static_cast<long double>(int_val)))
{
// we would not lose precision -> return int
	result.m_type = value_t::number_integer;
	result.m_value = int_val;
}
else
{
	// we would lose precision -> return float
	result.m_type = value_t::number_float;
	result.m_value = static_cast<number_float_t>(float_val);
}
break;

My understanding, and I might be wrong, is that the parser casts from a NumberFloatType to an NumberIntegerType and back again and checks if there is a significant difference.  If the number was too large for the NumberIntegerType won't it therefore fail the loss of precision test and just be stored as a NumberFloatType, with the sign preserved?
@Furcube, what are you trying to do exactly? Normally it is perfectly legal to assign a negative value to an unsigned variable.  For example:
unsigned int val = -1;
std::cout << std::hex << val;

compiles without error, runs without exception, and simply produces FFFFFFFF i.e. the unsigned representation of -1.  This is because the compiler does an implicit conversion.
I might be misunderstanding however but if you are trying to do something like this (where val is a negative number in the object, say -1):
unsigned int val = doc["val"].get<unsigned int>();

Then I would expect it to work because internally the library has a function in the form of the following (only in a class and not just returning a literal but the actual value with a static_cast):
template<typename T>
T get() { return -1; }

Which if called in the form unsigned int val = get<unsigned int>(); is instantiated as unsigned int get() { return -1;} which ends up becoming effectively unsigned int val = -1;.  Again, I would not expect this to throw an exception.
I apologize in advance if I am way off with this.  I haven't been using the library long so I might be misunderstanding how it works.

@twelsby I wasn't referring to parsing, I was referring to creating a json object to be formatted as a JSON string:
basic_json(const CompatibleNumberIntegerType val) noexcept
    : m_type(value_t::number_integer),
      m_value(static_cast<number_integer_t>(val))
{}

The static cast causes the large positive number, such as uint64_t(-1), to be stored and then output as a negative number.

I use uint64_t for generated ID, and I've noticed that logged id differ from id in json. Additionally it will make it harder to interface with java app, where jackson can use BigInteger for large values.
As for overflow. It is not so bad, as it can be range checked outside of library - large numbers will go into NumberFloatType (double), which will allow to do range check.
For example:
		std::stringstream jstr;

	uint64_t expected = std::numeric_limits<uint64_t>::max();

	jstr << "{\"max\":" << expected << "}";
	json j = json::parse(jstr.str());
	uint64_t u_max = j.at("max");
	double d_max = j.at("max");

	std::cout << "expected: " << expected << std::endl;
	std::cout << "json: " << jstr.str() << std::endl;
	std::cout << "dump: " << j.dump() << std::endl;
	std::cout << "uint64_t max: " << u_max  << std::endl;
	std::cout << "double max: " << d_max  << std::endl;
	std::cout << "is more than max(int64_t)? " << (d_max > std::numeric_limits<int64_t>::max()) << std::endl;

with gcc 5.3 will produce
expected:<PHONE_NUMBER>3709551615
json: {"max":18446744073709551615}
dump: {"max":1.84467440737096e+19}
uint64_t max: 0
double max: 1.84467e+19
is more than max(int64_t)? 1

I can't get uint64_t from it, don't know why, but range check is working;

std::numeric_limits<uint64_t>::max can not be stored in a double without loss of accuracy, it has too many digits.

@gregmarr, @Furcube seems to be talking about parsing, or at least that is what his example does.  However I think the behavior you raise is certainly worthy of its own issue.
The loss of accuracy you also mention (which will also occur during parsing because all numbers are parsed initially as doubles so anything larger than 2^53 will have loss of accuracy) may or not be a problem as this behavior is in compliance with RFC7159, which allows implementations to set limits on the range and precision of numbers that are accepted and also recommends supporting double precision numbers for interoperability.  It would be nice to go all the way to 2^64 - 1 but is not a necessity.
@Furcube, when I run your example it doesn't execute the code path related to your fix but instead passes through the next switch case because m_type is set to value_t::number_float by parser::parse().
With both VS2015 and gcc 4.9.2 compiling for x64 the subsequent static_cast that occurs is actually performed by a cvttsd2si instruction.  In the event that this instruction is applied to an input that exceeds the maximum that can be stored in a signed 64 bit integer then it will evaluate to 0x80000000.  On VC2015 this is what is assigned to u_max and what gets printed out by your example i.e. the decimal equivalent of 0x80000000.  For reasons unknown gcc always clears the top bit of the result (by XORing with 0x80000000) and so will set u_max to 0 (the result you are getting).
The minimal example that replicates this behavior is:
uint64_t x = std::numeric_limits<uint64_t>::max();
double y = static_cast<double>(x);
uint64_t z = static_cast<uint64_t>(y);
std::cout << x << std::endl << y << std::endl << z << std::endl;

Here x is the original value, y is what gets stored and z is what you extract.  The output with gcc is:
18446744073709551615
1.84467e+19
0

The moral of the story is that if you parse a number that is larger than 2^53 then it will be stored as a double with reduced accuracy and if you then try and extract it to an uint64_t, you will get compiler dependent behavior, which will certainly not be the actual value stored.  As this is a consequence of storing large integer values as doubles the only way I can see to fix it is to not store such values as doubles to begin with.  This requires modification of the parse code (and obviously also the object creation code at the other end of the chain).
Incidentally, @nlohmann, I notice there has been issues with Visual Studio in the past but the current version compiles without error or warning in VS2015.  c++11 (and c99) support seems to be greatly improved.

@twelsby Which version of MSVC did you try? Currently MSVC 19.0.23506.0 fails to compile the unit tests, see https://ci.appveyor.com/project/nlohmann/json.

Here is one possible solution, admittedly a not very elegant brute force approach:
#include <iostream>
#include <cfloat>
#include <cmath>
#include <cstdlib>

// Modify the existing value_t enum
enum class value_t : uint8_t
{
    number_integer,
    number_unsigned,               // Add this
    number_float
} m_type;

// Modify the exiting json_value union
union json_value {
    double  number_float;
    uint64_t number_unsigned;      // Add this
    int64_t number_integer;
} m_value;

const char * m_start;

// Rewrite lexer::get_number()
void get_number()
{
    char * end;

    // Parse it as an integer
    if(*m_start != '-')  {
        // Unsigned
        m_value.number_unsigned = strtoull(m_start,&end,0);
        m_type = value_t::number_unsigned;
    }
    else  {
        // Signed
        m_value.number_integer = strtoll(m_start,&end,0);
        m_type = value_t::number_integer;
    }

    // Parse it as a double
    double test = strtold(m_start,&end);
    double int_part;
    double frac_part = std::modf(test, &int_part);

    // Test if the double or integer is a better representation
    if(frac_part != 0 ||
            (m_type == value_t::number_unsigned && int_part != m_value.number_unsigned) ||
            (m_type == value_t::number_integer && int_part != m_value.number_integer)) {
        m_value.number_float = test;
        m_type = value_t::number_float;
    }
}

template<typename T>
T get_impl(T*)
{
    switch (m_type)
    {
        case value_t::number_integer:
        {
            return static_cast<T>(m_value.number_integer);
        }

        // Add from here ------------------------
        case value_t::number_unsigned:
        {
            return static_cast<T>(m_value.number_unsigned);
        }
        // to here-------------------------------

        case value_t::number_float:
        {
            return static_cast<T>(m_value.number_float);
        }

        default:
        {
        }
    }
}

int main()
{
    const char * str[] = {
            "18446744073709551615",
            "9223372036854775807",
            "-9223372036854775808",
            "-123.456e13",
            "123.456E-25",
            "123.456e2"
    };

    for (int i=0; i < 6; i++)  {
        m_start = str[i];
        get_number();

        double dout = get_impl(static_cast<double*>(nullptr));
        uint64_t uout = get_impl(static_cast<uint64_t*>(nullptr));
        int64_t iout = get_impl(static_cast<int64_t*>(nullptr));

        std::cout << "In:" << str[i];
        std::cout << " Double:" << dout;
        std::cout << " Unsigned:" << uout;
        std::cout << " Signed:" << iout << std::endl;
    }
    return 0;
}

This produces the output
In:18446744073709551615 Double:1.84467e+19 Unsigned:18446744073709551615 Signed:-1
In:9223372036854775807 Double:9.22337e+18 Unsigned:9223372036854775807 Signed:9223372036854775807
In:-9223372036854775808 Double:-9.22337e+18 Unsigned:9223372036854775808 Signed:-9223372036854775808
In:-123.456e13 Double:-1.23456e+15 Unsigned:18445509513709551616 Signed:-1234560000000000
In:123.456E-25 Double:1.23456e-23 Unsigned:0 Signed:0
In:123.456e2 Double:12345.6 Unsigned:12345 Signed:12345

This is the output I would expect i.e. for:

The input is 2^64-1 so when extracted as a double it loses accuracy, but as a uint64_t it is exact.  As a int64_t it gives the wrong but expected result.
The input is 2^63-1 so when extracted as a double it loses accuracy, but as both an uint64_t and int64_t it is accurately represented.
The input is -2^63 so when extracted as a double it loses accuracy, while as a uint64_t it loses its sign, but as a int64_t it is accurately represented.
The input is a negative floating point number can be accurately represented as a double and as a int64_t but the uint64_t result is wrong (but expected).
The input is between 0 and 1 so can only be represented as a double.  The integer representations get truncated to 0.
The input is a floating point number that is accurately represented as a double but truncated at the decimal point for the integer types.

The downside of this approach is that it requires parsing the number twice, as an integer and as a double.  The upside is that it is no longer necessary to do the precision loss check as this is effectively handled by the above code.
I haven't looked at the object creation side but I would think that having the number_unsigned type probably makes that trivial to solve - although perhaps I am just being optimistic.

@nlohmann, yeah that one.  I didn't build the unit tests however and wasn't trying to see if everything worked.  Disregard then.

Extending the enum value_t to the element number_unsigned would also mean that it cannot be stored with uint8_t, as it would contain 9 elements. Beside that, your sketched changes could be feasible.

It's not a bitfield, so adding another value to the enum doesn't affect the required size.

I'll try it in the actual code and see how it goes.  Although if anyone has a better idea jump in.

Well it works well in testing so I have submitted a pull request.  With the existing unit testing the only errors related to type verification, which were expected.  Changing those to accept the new type and it passes.  I added extra (equivalent) unit tests for the new type (very tedious) and they also pass as well as tests that check the behavior in the specific cases discussed here.

@gregmarr, I understand that enum class value_t : uint8_t defines uint8_t as underlying type, so having more than 8 values would be a problem. And as the class has a member of type value_t, why would the required size of an object would not depend on the number of different enum values?
  Unless something funny is going on a uint_8 based enum should be able to store 256 possible values, assuming there is no need to combine them at once (e.g. OR them together).  If that were the case you would need to manually assign them values as the compiler will otherwise just number them them from 0 in the order in which they are listed.

Oh this is so embarrassing... I totally forgot the "8" in uint8_t stands for bytes... :flushed:

uint8_t is 8bit, enums are not bit based, they go like 0,1,2,3...
Anyway, uint8_t will be aligned in memory at least to 32bit, so there's no change in memory consumption if you do not specify #pragma pack. And packed structures can be bad for some architectures which don't support unaligned memory access.

FYI: I'll try to close as many issues as possible until the weekend and publish version 1.0.1 then before I can focus on the 2.0.0 release (I would really like to follow Semantic Versioning and treat the change in the public enum value_t as API breaking.

Fixed by merging #193. Thanks so much!!!


fix: fix typos in divider and radio group readmes

Link to relevant issue
n/a
Description of changes
This fixes two typos found in the documentation

@microsoft-github-policy-service agree


[Bug]: Native ORACLE export does not support global snapshots and file size limits, and these two options need to be hidden.

ODC version
ODC424
OB version
independent
What happened?
Native ORACLE export does not support global snapshots and file size limits, and these two options need to be hidden.

What did you expect to happen?
hidding it
How can we reproduce it (as minimally and precisely as possible)?
。
Anything else we need to know?
No response
Cloud
No response

pass


Define thorough operator integration test plan

Come up with a test/CI plan for making sure our recipes work on GKE (and with other GCP components)

Mike is working on it

At this point we have an idea of the test plan we want and I've shared a doc outlining the rough design for that. However a thorough plan is not a high priority for us right now. If this comes back up we will open a new issue to track implementing the tests.


bug(schematics): Cannot find module '@angular-devkit/core'

Bug Report or Feature Request (mark with an x)
- [X ] bug report -> please search issues before submitting
- [ ] feature request

Area
- [ ] devkit
- [X ] schematics

Versions

node 6.9.1
npm 5.4.2
Windows 10
Repro steps

If you globally install @angular-devkit/schematics and try to create a new schematic using
schematics @schematics/schematics:schematic --name=SomeSchematicName you will get the following error:
The log given by the failure

Error: Cannot find module '@angular-devkit/core'
    at Function.Module._resolveFilename (module.js:469:15)
    at Function.Module._load (module.js:417:25)
    at Module.require (module.js:497:17)
    at require (internal/module.js:20:19)
    at Object.<anonymous> (C:\......\node_modules\@schematics\schematics\schematic\factory.js:10:16)
    at Module._compile (module.js:570:32)
    at Object.Module._extensions..js (module.js:579:10)
    at Module.load (module.js:487:32)
    at tryModuleLoad (module.js:446:12)
    at Function.Module._load (module.js:438:3)

Desired functionality

No errors and a generated new schematics blueprint
Mention any other details that might be useful

the @schematics/schematics:schematic factory uses a dependency on @angular-devkit/core, but this dependency is not in the package.json

thnx guys  npm install @angular-devkit/core --save-dev , it worked for me

@merobal Thank you! Worked for me!

I struggled with the same problem. My project was generated using the v 1.6.0 of angular-cli.
npm update -g @angular/cli
editing my package.json changing the line
"@angular/cli": "1.6.0",
to
"@angular/cli": "^1.6.0",
npm update
did the trick.

Error: Cannot find module '@angular-devkit/core'

npm install @angular-devkit/core --save-dev

its working fine


Update dependency redis to v4.6.5

This PR contains the following updates:

Package
Type
Update
Change

redis
dependencies
minor
4.5.1 -> 4.6.5

Release Notes

redis/node-redis
v4.6.5
Compare Source
Enhancements

upgrade @redis/client from 1.5.5 to 1.5.6
upgrade @redis/search from 1.1.1 to 1.1.2

v4.6.4
Compare Source
Enhancements

upgrade @redis/client from 1.5.4 to 1.5.5

v4.6.3
Compare Source
Enhancements

upgrade @redis/client from 1.5.3 to 1.5.4

v4.6.2
Compare Source
Enhancements

upgrade @redis/client from 1.5.2 to 1.5.3

v4.6.1
Compare Source
Enhancements

upgrade @redis/client from 1.5.0 to 1.5.2

v4.6.0
Compare Source
Enhancements

upgrade @redis/client from 1.4.2 to 1.5.0
upgrade @redis/bloom from 1.1.0 to 1.2.0
upgrade @redis/search from 1.1.0 to 1.1.1

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Enabled.
♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

lgtm


refactor(client): use lowercase "conjunction" and "unit" in "create_job"

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 86.082%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
7985

Relevant Lines:
9276

💛  - Coveralls


Selection area should move selection word by word on a long press drag

On native iOS and Android when long pressing and then dragging the selection expands word by word. Before this change SelectionArea expanded the selection character by character on a long press drag.
Fixes #104603
Pre-launch Checklist

[x] I read the [Contributor Guide] and followed the process outlined there for submitting PRs.
[x] I read the [Tree Hygiene] wiki page, which explains my responsibilities.
[x] I read and followed the [Flutter Style Guide], including [Features we expect every widget to implement].
[x] I signed the [CLA].
[x] I listed at least one issue that this PR fixes in the description above.
[x] I updated/added relevant documentation (doc comments with ///).
[x] I added new tests to check the change I am making, or this PR is [test-exempt].
[x] All existing and new tests are passing.

in which version will this fix be included, gentlemen?


High CPU usage

Just starting and it has an excessively high CPU usage all the time and not even active

Thank you!


Add LLM token count callback.

This PR adds a new, public callback set_llm_token_count_callback. This callback calls a user function to calculate total LLM token counts for a chat completion or embedding and stores in on the corresponding LLM events.

Codecov Report
Attention: Patch coverage is 94.66667% with 4 lines in your changes are missing coverage. Please review.

Project coverage is 80.14%. Comparing base (b3489bf) to head (d38db85).
Report is 1 commits behind head on develop-ai-limited-preview-3.

Files
Patch %
Lines

newrelic/api/ml_model.py
75.00%
2 Missing and 2 partials :warning:

Additional details and impacted files
@@                       Coverage Diff                        @@
##           develop-ai-limited-preview-3    #1094      +/-   ##
================================================================
- Coverage                         81.86%   80.14%   -1.72%
================================================================
  Files                               192      192
  Lines                             21252    21308      +56
  Branches                           3711     3721      +10
================================================================
- Hits                              17397    17077     -320
- Misses                             2782     3184     +402
+ Partials                           1073     1047      -26

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


How to use azure functions that aren't 3.1

Can someone help me understand how to use azure functions that aren't 3.1. I see an issue #590 which speaks to this and it is closed, but when you follow the instructions here you get Unrecognized target framework "netcoreapp3.1".

Closing as duplicate of https://github.com/microsoft/vscode-azurestaticwebapps/issues/590. It's fixed in our main branch but has yet to be released. We'll drop a comment on that issue when we release the fix.

Fix has been released in version 0.10.0


can use this to action detection?

Need to detect whether the door is open or not on the mobile terminal. Can this feature be achieved?

I have no idea. Feel free to try.


Fix minor typo

I think the correct command is "make modules_prepare", not "make module_prepare"

thanks !


A way to use "background-size: cover;"?

Thanks for a great tool!
My question is if there is a way to avoid having to specify the size of the image in the markup? Instead I'd like to do that in the CSS by telling the image to cover its container if possible.
I run into this issue when I use media queries that allow multiple columns of images collapse into one single column (thus having the image spread across the screen).

Hello, you can do /0/0 to get the largest available resolution of an image (does not scale up above the default dimensions). However, I would recommend just using a large enough resolution that should fit most screens, or similar.

Thank you for your quick response! 0/0 works great.
Another (maybe off topic) question: is there a way to create more than one randomized selection for one page load? If I do the following I get two identical images, but I'd prefer two randomized (thus different):

You can do ?random=1, ?random=2 or add any other random parameter to avoid the browser caching the image and ending up with the same one

Wonderful! Thank you.


updated interface names for gojay

Not sure if any other changes needed, but this worked for me.

Hi, yes a few more changes needed to documentation and dep files. Merging this one and adding changes required. Thanks!


SP4: Demonstrate custom plot type

addresses #2413
addresses https://github.com/ScottPlot/ScottPlot.NET/issues/10
Graphic design is my passion 😜

https://scottplot.net/faq/custom-plot-type/


⚠ ClamAV has degraded performance

In c3abe0c, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 73 ms

Resolved: ClamAV performance has improved in 5c48aba.


Deactive automatic failure comments

Deactive automatic failure comments until we have a more stable CI.
Signed-off-by: Arnaud Porterie<EMAIL_ADDRESS>

LGTM


Write docs how to use variants

This is already implemented:
https://github.com/ongr-io/ApiBundle/blob/master/Resources/doc/variants.md


ENH: Add smriprep-docker wrapper

Hello @effigies! Thanks for updating this PR. We checked the lines you've touched for PEP 8 issues, and found:

In the file smriprep/__about__.py:

Line 11:80: E501 line too long (91 > 79 characters)

In the file wrapper/smriprep_docker.py:

Line 24:80: E501 line too long (91 > 79 characters)
Line 25:80: E501 line too long (81 > 79 characters)
Line 221:80: E501 line too long (81 > 79 characters)
Line 222:80: E501 line too long (80 > 79 characters)
Line 226:80: E501 line too long (84 > 79 characters)
Line 249:80: E501 line too long (93 > 79 characters)
Line 276:80: E501 line too long (80 > 79 characters)
Line 304:80: E501 line too long (96 > 79 characters)
Line 317:80: E501 line too long (82 > 79 characters)

Pretty sure the doc build has been fixed. I'm going to go ahead and merge this. If the build is still broken, I'll open a new PR.


SANSA-POI Integration

Added new clustering algorithms.

um, @Rajjat shall we close this PR without mergeing then since it is already included on the new PR (Develope clustering #10 )  you made.
Could you let me know, so we focus on only one PR.
Best,

OK,I see that you did it already by this commit f74a633 , so for that reason I will close this PR and will focus only on #10 .
Best,


Problem with spherical overdensity masses at z > 0

I've been doing some comparisons between Velociraptor in 3D FoF mode and the EAGLE FoF implementation and I think I might have found a bug.
At high redshift the EAGLE m200crit and EAGLE m200mean mass functions (both computed by Gadget) are very similar to each other. I think this is expected because the mean density is close to the critical density at high redshift. But Velociraptor exhibits the opposite behaviour - the m200mean mass function diverges from the m200crit mass function as z increases.
I think the problem might be with the calculation of the mean density. It's defined as
    opt.rhobg=3.*Hubble*Hubble/(8.0*M_PI*opt.G)*opt.Omega_m;

I think Omega_m here is the density parameter at z=0 because it gets read from the Omega0 header entry in the case if Gadget snapshots. Shouldn't it be the density parameter at the redshift of the snapshot?

Thanks for spotting this John. I'll fix this tomorrow unless you want to push the correction yourself.

I've been taking a quick look at fixing this. We'll need to correct the calculation of rhobg in the read routines and in the swift interface. The calculation of m200val and m500val in substructureproperties.cxx probably needs to be changed to use the same omega_m as rhobg too. I'm not sure which omega_m the BN98 virial overdensity calculation should be using.

I think I've fixed the issue in the expandedproperties branch but need to test it. Will do later today.

I just had a go at running this branch on the EAGLE 25 box and there's still something wrong - in fact now the m200m mass function at z=0 is very different from what the EAGLE code produces and both m200c and m200m look wrong at high redshift.
Looking at the latest commit in the expandedproperties branch, I think the problem is that the CalcBackgroundDensity function you modified is never called. Instead it's using the incorrect opt.rhobg calculation which is duplicated across all the read routines and the swift interface.

Oh, sorry, I see that you already removed the duplicated calculations in the expandedproperties branch. I was looking at master. Maybe we just need to add a call to CalcBackgroundDensity.

I think I'll also have to update the swift interface to make sure it is generalised but need to double check what Omega_i values are stored. I've pushed an update of rhobg. Can you check to see if densities and overdensity masses at high redshift are correct?

Bug fixed. Masses match EAGLE results (DM only).


[suggestion/request] non TFC dependency

HI, since the model is so pretty, i was wondering if it would be possible to make it non dependable from tfc and usable as an additional machine with crafttweaker configuration for recipe, obviously if not too problematic to do.

i've never tried modding minecraft, i've tought about it, but never had the time to learn it, like, how to set up the environment, i've never worked with java.
If i find the time to look into it i will let you know!
Looking into other mod source code it doesn't look too difficult to implement crafttweaker compat, but it might be cause i'm inexperienced and maybe there is something i missed

I also request non TFC dependence，Because TFC is not always selected when making the integration package, its compatibility is too difficult to consider，But I still love this module. I think it's a good idea to combine agriculture with the economic system of weaving machines. He should have more choices


Running deploy-local-cluster.sh failing - not picking up correct ansible_architecture

When running the deploy-etcd.yml playbook referenced by deploy-local-cluster.sh this fails with the error below.
It seems that the ansible_architecture is being incorrectly set (or rather not changed to amd64).
Running on ""Ubuntu 16.04.3 LTS"
TASK [etcd : Download tar file] ************************************************
fatal: [localhost]: FAILED! => {"changed": false, "dest": "/tmp/.ansible/files", "failed": true, "gid": 0, "group": "root", "mode": "0755", "msg": "Request failed", "owner": "root", "response": "HTTP Error 404: Not Found", "size": 4096, "state": "directory", "status_code": 404, "uid": 0, "url": "https://github.com/coreos/etcd/releases/download/v2.2.3/etcd-v2.2.3-linux-x86_64.tar.gz"}

No surprise, but this happens with ./deploy-cluster.sh as well. (Remote host is Ubuntu 14.04.2)

Temporary workaround for any other ansible neophytes like me reading this: added this to ansible/roles/etcd/tasks/override_facts.yml
# work around bug: https://github.com/kubernetes/contrib/issues/2699
- name: Override ansible_archecture
  set_fact:
    ansible_architecture: "amd64"

Thanks,
I then added the same task to
ansible/roles/kubernetes/tasks/override_facts.yml also as downloading
kubernetes binaries was failing for the same reason.
Then on to other problems ...
On 2 August 2017 at 18:39, Brett Higgins<EMAIL_ADDRESS>wrote:

Temporary workaround for any other ansible neophytes like me reading this:
added this to ansible/roles/etcd/tasks/override_facts.yml
work around bug: https://github.com/kubernetes/contrib/issues/2699

name: Override ansible_archecture
set_fact:
ansible_architecture: "amd64"

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes/contrib/issues/2699#issuecomment-319728792,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABywLR2rwpiyV0fjFnEl171qz7rjgUuBks5sUKZYgaJpZM4OrRJs
.


Arbitrum support

[Registry contract issue link]

closing as this will be an issue on the registry contract/subgraph repo


Antenna impedance matching: F2 unknown

The part named F2 in schematic and BOM has a value of 0. What would be the correct value here?
(also: since I can‘t find any info on this anywhere, do you know the impedance of the ESP32-C3 itself?)

May be i am wrong, but i think is a 0 ohm resistor.

F2 is just a bridge (0Ohm resistor), and for the C3T there isn't any matching network and impedance matching done. The C3 includes a PI-network and is properly tuned.


Near query not returning expected results

From @MayankBhatnagar89:
I am working on the automation of Node.js Near Query. Here I am performing a search on two words “Bush” and “Atlantic”
There are total of five json documents which I have inserted and three of them have the words Bush and Atlantic in them.
The only difference in them is the distance which is “1”, “3” and “6”.
Now when I do near query in which I have mentioned distance as 1 . Only one document should be returned which has got distance between Bush and Atlantic as “1” but all three has been returned.
I am mentioning the code below, please have a look into it.
Query :
it('should do near query', function(done){
db.documents.query(
q.where(
q.near(
q.term('Bush'),
q.term('Atlantic'),
1,                                               #distance as 1
true,
q.weight(1)
)
)).result(function(response) {
console.log(JSON.stringify(response, null, 4));
var document = response[0];
response.length.should.equal(1);
response[0].content.id.should.equal('0011');
done();
}, done);
});
Documents Inserted :
{
uri: '/test/query/matchDir/doc2.json',
collections: ['matchCollection1', 'matchCollection2'],
contentType: 'application/json',
content: {
title: 'The Bush article',
popularity: 4,
id: '0012',
date: '2006-02-02',
price: {
amt: 0.12
},
p: 'The Bush Atlantic article described a device called a Memex'                    #Here the distance is 1
}
},
{
uri: '/test/query/matchDir/doc1.json',
collections: ['matchCollection1'],
contentType: 'application/json',
content: {
title: 'Vannevar Bush',
popularity: 5,
id: '0011',
date: '2005-01-01',
price: {
amt: 0.1
},
p: 'Vannevar Bush wrote an article for The Atlantic Monthly'                          #Here the distance i6 6
}
},
{
uri: '/test/query/matchDir/doc3.json',
collections: ['matchCollection2'],
contentType: 'application/json',
content: {
title: 'For 1945',
popularity: 3,
id: '0013',
date: '2007-03-03',
price: {
amt: 1.23
},
p: 'For 1945, the thoughts expressed Bush in the Atlantic Monthly were groundbreaking'     #Here the distance is 3
}
},
{
uri: '/test/query/matchDir/doc4.json',
collections: [],
contentType: 'application/json',
content: {
title: 'Vannevar served',
popularity: 5,
id: '0024',
date: '2008-04-04',
price: {
amt: 12.34
},
p: 'Vannevar served as a prominent policymaker and public intellectual'
}
},
{
uri: '/test/query/matchList/doc5.json',
collections: ['matchList'],
contentType: 'application/json',
content: {
title: 'The memex',
popularity: 5,
id: '0026',
date: '2009-05-05',
price: {
amt: 123.45
},
p: 'The Memex, unfortunately, had no automated search feature policy'
}
}

@MayankBhatnagar89 thanks for discovering this. I suspect my recent commits aren't the culprit here, and that the near query wasn't working to begin with. In the nodejs-documents-query.js file on master, when I change the distance value here:
https://github.com/marklogic/node-client-api/blob/master/test-complete/nodejs-documents-query.js#L286
it has no impact on what results are returned. For example, if I change the distance to 1, the document that contains 'Bush' and 'Atlantic' 6 tokens away is still returned ('Vannevar Bush wrote an article for The Atlantic Monthly'). Can you confirm this (on the master branch)?
I will continue to investigate...

The test is failing because search queries are run unfiltered by default; also, the word positions index is not turned on.
The test should pass if you either add 'filtered' as a search option:
db.documents.query(
  q.where(
    q.near(
      q.term('Bush'),
      q.term('Atlantic'),
      1,
      true,
      q.weight(1)
    )
  ).withOptions({search:['filtered']}))

or turn on the word positions index for the database.

Hi Mike,
Adding 'filtered' search option to query is giving desired results.Hence closing the issue.
Thanks,
Mayank


Transaction valid_until can't compare to none type

http://<IP_ADDRESS>:8000/customers/1/payment_methods/1/transactions/
Again the user does not seem to matter on the transaction if he is the owner of the payment_method. All combinations produce the same thing.
/silver/silver/models/transactions.py in s_usable
          self.valid_until > timezone.now()

If the field valid_until is set we are ok, so I propose to make it not nullable.

Do you have a proper log?

Create a customer + a payment for the user then try and add a transaction without a valid_until from the admin. Unless filled in with a date this error will pop up. Forgot to screencapture.

Apparently on the master branch this is not happening anymore. Or the steps to reproduce are deeper than I thought. Closing for now.