Custom model's build() method is not called automatically

System information

Have I written custom code (as opposed to using a stock example script provided in TensorFlow):
Yes
OS Platform and Distribution (e.g., Linux Ubuntu 16.04):
MacOSX 10.13.6
Mobile device (e.g. iPhone 8, Pixel 2, Samsung Galaxy) if the issue happens on mobile device:
No
TensorFlow installed from (source or binary):
Binary
TensorFlow version (use command below):
tf.version.VERSION: '2.0.0-dev20190301'
tf.version.GIT_VERSION: 'v1.12.0-9345-g4eeb2714f4'
Python version:
3.6.8
Bazel version (if compiling from source):
N/A
GCC/Compiler version (if compiling from source):
N/A
CUDA/cuDNN version:
N/A
GPU model and memory:
N/A

Describe the current behavior
When creating a custom model with a build() method (e.g., if one of the model's layers has a size that depends on the input shape, such as a reconstruction layer), the model cannot be trained unless I explicitly call build() with a tf.TensorShape(). Moreover, I cannot specify an input_shape.
Describe the expected behavior
I expect the custom model to be built automatically the first time it is called (e.g., by the fit() method).
Code to reproduce the issue
import numpy as np
import tensorflow as tf
from tensorflow import keras

X_train = np.random.randn(1000, 8)
y_train = np.random.rand(1000, 1)

class ReconstructingRegressor(keras.models.Model):
    def __init__(self, output_dim, **kwargs):
        super().__init__(**kwargs)
        self.hidden = keras.layers.Dense(30, activation="elu")
        self.out = keras.layers.Dense(output_dim)

    def build(self, batch_input_shape):
        n_inputs = batch_input_shape[-1]
        self.reconstruct = keras.layers.Dense(n_inputs)
        super().build(batch_input_shape)

    def call(self, inputs):
        Z = self.hidden(inputs)
        reconstruction = self.reconstruct(Z)
        reconstruction_loss = tf.reduce_mean(tf.square(reconstruction - inputs))
        self.add_loss(0.1 * reconstruction_loss)
        return self.out(Z)

model = ReconstructingRegressor(1)
#model.build(tf.TensorShape([None, 8])) # <= works if I add this line
model.compile(loss="mse", optimizer="nadam")
history = model.fit(X_train, y_train, epochs=2) # <= AttributeError (see below)

Other info / logs
Here is the stacktrace:
AttributeError                            Traceback (most recent call last)
<ipython-input-1-3cb185747474> in <module>
     27 #model.build(tf.TensorShape([None, 8])) # <= works if I add this line
     28 model.compile(loss="mse", optimizer="nadam")
---> 29 history = model.fit(X_train, y_train, epochs=2) # <= ERROR!

~/.virtualenvs/tf2/lib/python3.6/site-packages/tensorflow/python/keras/engine/training.py in fit(self, x, y, batch_size, epochs, verbose, callbacks, validation_split, validation_data, shuffle, class_weight, sample_weight, initial_epoch, steps_per_epoch, validation_steps, validation_freq, max_queue_size, workers, use_multiprocessing, **kwargs)
    804         steps=steps_per_epoch,
    805         validation_split=validation_split,
--> 806         shuffle=shuffle)
    807
    808     # Prepare validation data.

~/.virtualenvs/tf2/lib/python3.6/site-packages/tensorflow/python/keras/engine/training.py in _standardize_user_data(self, x, y, sample_weight, class_weight, batch_size, check_steps, steps_name, steps, validation_split, shuffle, extract_tensors_from_dataset)
   2501       else:
   2502         cast_inputs = x_input
-> 2503       self._set_inputs(cast_inputs)
   2504     else:
   2505       y_input = y

~/.virtualenvs/tf2/lib/python3.6/site-packages/tensorflow/python/training/tracking/base.py in _method_wrapper(self, *args, **kwargs)
    454     self._setattr_tracking = False  # pylint: disable=protected-access
    455     try:
--> 456       result = method(self, *args, **kwargs)
    457     finally:
    458       self._setattr_tracking = previous_value  # pylint: disable=protected-access

~/.virtualenvs/tf2/lib/python3.6/site-packages/tensorflow/python/keras/engine/training.py in _set_inputs(self, inputs, outputs, training)
   2773             outputs = self.call(inputs, training=training)
   2774           else:
-> 2775             outputs = self.call(inputs)
   2776           # Reset to the previously saved value. If `call()` had `add_metric`
   2777           # or `add_loss`, then `_contains_symbolic_tensors` will have been set

<ipython-input-1-3cb185747474> in call(self, inputs)
     19     def call(self, inputs):
     20         Z = self.hidden(inputs)
---> 21         reconstruction = self.reconstruct(Z)
     22         reconstruction_loss = tf.reduce_mean(tf.square(reconstruction - inputs))
     23         self.add_loss(0.1 * reconstruction_loss)

AttributeError: 'ReconstructingRegressor' object has no attribute 'reconstruct'

Thanks for the bug report! I was able to reproduce this issue, looking into it now

This should be fixed in the latest nightly build

Has it been fixed? I still get an error in a specific case when using add_loss on a model.
For example, as illustrated in this question.


Cannot run quad example on macOS, it says "You need to enable the native API feature (vulkan/metal) in order to test the LL"

Short info header:

GFX version: master@c4470d0298b9965bda01726a1c72996da068e3b1
OS: macOS Mojave 10.14.5
GPU: Intel Iris Plus 655 (Macbook Pro 13" 2018 with touchbar)

I have installed XCode and try to run
cargo run --bin quad --features metal
However it always says

You need to enable the native API feature (vulkan/metal) in order to test the LL

Hi @zheli! This issue could be caused by running cargo run --bin quad --features metal from the gfx directory instead of the gfx/examples directory.
Is your working directory set to examples? For example, you should cd examples first as mentioned in the examples readme.
We could probably update the warning message to help with this in the future, if you'd like to send a pull request :)

Thx @grovesNL! Can't believe I made this simple mistake, haha. Completely missed the step to switch to gfx/examples folder. It works now!


Improve log during restore PVs and PVS for VolRep to reflect the core error

During restore PVs and PVCs for VolRep we are not reflecting the real errors, but printing more general ones. This PR is fixing the problem, now we are able to see, for example, if failure is due to error in restoring k8s resources or due to error in restoring PV/PVCs.
Fixes: https://github.com/RamenDR/ramen/issues/1452

@nirs the real problem is not in PV/PVC restore, but in underline failure (for example, Kube objects group recover error), but inside function restorePVsAndPVCsFromS3 we were suppressed the real error and printed general error. My fix is adding real error message to be propagated to the top


Assess performance, spawn new github issues to address issues found.

We've gotten a request to improve the performance of the package. Working on getting more specifics, but a basic review of the code with an eye on performance is likely in order. I'm guessing there's a pretty easy to identify list of things that will help speed up processing.

I will take a look but I agree that there are some low hanging fruit that would probably streamline the code substantially

I don't know whether you've made any progress on this, but I certainly have some ideas. Not sure why you split of the metrics into separate functions, but most of the dl and dh functions are very efficiently calculated using a matrix approach. For example:
library(RcppRoll)
library(matrixStats)
library(EflowStats)
library(lubridate)
data('sampleData')
qfiletempf <- sampleData
water.year <- function(x){
  yr <- year(x)
  ifelse(month(x, label = FALSE) > 9, yr + 1, yr)
}

rangeStats <- function(x, date, intervals = c(1, 3, 7, 30, 90), fun = c('mean', 'median')){
  fun <- match.arg(fun)
  if(is.unsorted(date)){
    i    <- order(date)
    x    <- x[i]
    date <- date[i]
  }
  n <- length(x)
  roll_wrap <- function(i, x){
    roll_mean(x, i, fill = NA, align = 'right')
  }
  yr    <- water.year(date)
  roll  <- vapply(intervals, roll_wrap, numeric(n), x = x)
  sroll <- split.data.frame(roll, yr)
  ret <- vapply(sroll, function(x) colRanges(x, na.rm = T), numeric(2 * length(intervals)))
  ret <- t(ret)
  colnames(ret) <- t(outer(c('min', 'max'), intervals, function(x, y) paste0(x, y, 'day') ))
  ret.center        <- switch(fun,
                              mean = colMeans(ret, na.rm = T),
                              median = colMedians(ret, na.rm = T))
  ret.center.scaled <- ret.center / median(x, na.rm = T)
  ret.sds           <- colSds(ret, na.rm = T) / colMeans(ret, na.rm = T) * 100
  ret <- cbind(center               = ret.center,
               variability          = ret.sds,
               center.median.scaled = ret.center.scaled)
  ret
}

system.time(ret <- rangeStats(qfiletempf$discharge,qfiletempf$date))

nms <- cbind(c(paste0("dl",1:5), paste0("dh", 1:5)),
             c(paste0("dl",6:10), paste0("dh", 6:10)),
             c('dl11', NA, 'dl12', 'dl13', NA, 'dh11', NA, 'dh12', 'dh13', NA))
mine <- round(structure(as.numeric(ret), .Names = nms)[!is.na(nms)], 2)
system.time(yours <- c(dl1(qfiletempf), dl2(qfiletempf), dl3(qfiletempf), dl4(qfiletempf), dl5(qfiletempf),
           dh1(qfiletempf), dh2(qfiletempf), dh3(qfiletempf), dh4(qfiletempf), dh5(qfiletempf),
           dl6(qfiletempf), dl7(qfiletempf), dl8(qfiletempf), dl9(qfiletempf), dl10(qfiletempf),
           dh6(qfiletempf), dh7(qfiletempf), dh8(qfiletempf), dh9(qfiletempf), dh10(qfiletempf),
           dl11(qfiletempf),dl12(qfiletempf),dl13(qfiletempf), dh11(qfiletempf), dh12(qfiletempf), dh13(qfiletempf)))
mine - yours

It's much more efficient to combine the calculations and avoid the overhead of calculating each one separately. The code is also much more compact and maintainable. Calculating 200 years of flow statistics becomes quite fast:
> y <- seq(from = as.Date('1800-10-01'), by = '1 day', length.out = 365*200)
> x <- rnorm(365 * 200)
> system.time(rangeStats(x, y))
   user  system elapsed
   0.18    0.00    0.19

Obviously, an approach like this would mean rewriting some of your other package infrastructure so I didn't bother to open a pull request.


hifile: <IP_ADDRESS> -> <IP_ADDRESS>, add update script; maintainers/ymstnt: update name

hifile:

Update hifile to <IP_ADDRESS>
Changelog: https://www.hifile.app/changelog
Added automatic update script

other:

maintainers/ymstnt: updated name to lowercase, to reflect GitHub name changes

Things done

Built on platform(s)

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

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

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

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

[x] Fits CONTRIBUTING.md.

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

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-ready-for-review/3032/4683

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

x86_64-linux

:white_check_mark: 1 package built:

hifile


⚠ GreatPosterWall has degraded performance

In 8f88357, GreatPosterWall ($GPW) experienced degraded performance:

HTTP code: 200
Response time: 1668 ms

Resolved: GreatPosterWall performance has improved in fd80371.


Fixed capability version matcher for cases with 3 or more levels

Covered cases for versions like V1_4_2, V2_0_0, etc. Previously such versions was ignored by regexp. Now it looks for V(d) plus optional pattern (_d), so cases like V1, V1_1_1_1 are covered.
Signed-off-by: kopaihorodskyi

@bstasyszyn I see you were working on it before, could you check it, please?


[FEATURE]: Embed TikTok videos

You can see a example in Iframely.

Hey, I added it into the latest version - 1.1.1. If you face any problems with it or have any feedback, you can reopen the issue.

Ok, I found a bug.
In Reading View the video looks great:

But when I switch to Live Preview the video is cropped:

Thanks for the report! It also gave me the idea of caching the sizes so embeds that are resizeable should be resized faster after the first time it loads. I'll make a new update after confirming the bug in Issue 5


Change jsonData in _iterPost to setdefault

Update jsonData continuation key setting to setdefault in case continuation does not exist as a key already, fixing KeyError
Also sorry if noob, still learning. Finally back into python after a year and a half of bathing in SQL for a different position

This will set the continuation on jsonData, but only if it wasn't already there. So it won't update on subsequent iterations... I think.
The setdefault won't matter in the assignment, so I'm guessing it broke on lastResults instead.
Perhaps...?
jsonData['continuation'] = self.lastResults.get('continuation', False)

This will set the continuation on jsonData, but only if it wasn't already there. So it won't update on subsequent iterations... I think.
The setdefault won't matter in the assignment, so I'm guessing it broke on lastResults instead.
Perhaps...?

jsonData['continuation'] = self.lastResults.get('continuation', False)

That's probably more correct. I did notice .get was used above but not on that line. I would test it myself, but I was at work and didn't have the time to figure out how to test a library for the first time lol

You're correct, set default would work the first time to set continuation as a key in jsonData, but it would NOT update subsequent values.
Maybe something like
if 'continuation' in jsonData: jsonData['continuation'] = results['continuation'] else set default
Sorry if bad formatting, on mobile
Maybe tomorrow I'll figure out how to test the change on my personal laptop. It'd be a good exercise

Updated my change to not dumbly use setdefault since that will only set the value the first time (assuming the key isn't already there) and then only retrieve the value for that key on subsequent loops.
There's probably a more "python-ey" way to implement the change, but this seems to work well, at least from my rudimentary testing in a virtualenv
I will leave you to your own testing though (and advise you to do it, considering I'm still a beginner)


Enable deep watch to update on dataset change

Issue:

Chart is not updated when dataset is modified

Close to duplicate to #14 but this fit my prior PR and I added demos to show that it works.
I do not experience the issue described in the vue2 version of apexcharts at https://github.com/apexcharts/vue-apexcharts/issues/145
So I would say that this is safe

Benefits: Two methods of updating the chart, either by replacing the list sent as prop or by modifying the

Gif showing that there are not unnecessary extra re-renderings using deep watcher.

Notice how "Series updated, trigger chart.value.updateSeries" is not called twice in a row
Notice that toggling the first item on and off is working as expected using the legend

Please correct me if I am wrong, maybe I did not fully understand the bug described in the link above.

Thanks for doing a thorough test.
Looks like toggling the legend is not causing the re-renders, so the deep watch is safe here.

@junedchhipa Should I do a NPM version update in package.json as well? Or is there another method to trigger a npm package update?


Change copy and break up long form into sections

Steps to Reproduce: log in as client -> click "My Applications" -> Click "View Application"
Issue: Appending "Please Enter Your" to every form field label is redundant and overwhelming
Resolve by: Not appending "Please Enter Your"
Issue: super long forms require a lot of scrolling and is very overwhelming - it's very easy to lose your place while filling it out
Resolve by: breaking up forms into multiple pages / sections - a quick-and-dirty rule could be 5 questions per page?

The longer form problem may also be something that @leonna26 could consider accounting for in the Figma design?


Added new arguments to exclude some checks globaly

Hi Liam,
please consider my PR to add new argument to disable/ignore provided checks globally in whole project. Idea is to turn off/skip checks which generate False Positive findings for particular repository
Possible scenarios where this can help:

GEN003 finds issues in standard K8S secret manager resources
Disable other unused Cloud Providers

Thanks

Awesome, thanks for the PR :rocket:


Does MatchZoo work for Chinese dataset?

Describe the Question
Do this framework work for Chinese data set and relevant task, like Chinese sentence semantic text similarity?
Describe your attempts

[ ] I walked through the tutorials
[ ] I checked the documentation
[ ] I checked to make sure that this is not a duplicate question

You may also provide a Minimal, Complete, and Verifiable example you tried as a workaround, or StackOverflow solution that you have walked through. (e.g. cosmic radiation).
In addition, figure out your MatchZoo version by running import matchzoo; matchzoo.__version__. If this gives you an error, then you're probably using 1.0, and 1.0 is no longer supported. Then attach the corresponding label on the issue.

#656 #163 #185

I hope things are working well for you now. I’ll go ahead and close this issue, but I’m happy to continue further discussion whenever needed.


guess_score_name fails for arrays that store score-matches pairs

Issue
Reading scores from JSON fails when they are composed of score-matches pairs because the score name can't be guessed. For example, score_names of cosine greedy scores will consist of a tuple with 2 elements 'CosineGreedy_score', 'CosineGreedy_matches', but guess_score_name will raise an error whenever a length of score_names is other than 1.
Possible Solution
Adding an additional if statement to guess_score_name to account for score_names with 2 elements.

It turned out I hadn't properly familiarized myself with matchms 0.18.0 API. This issue occurred when I tried to use create_network from scores with two arrays without realizing create_network now accepts a layer name as an argument.


Add Pi Zero 2 W

- What I did: Added Pi Zero 2 Wireless machines and firmware package
- How I did it:  Used the existing Pi3 machines configurations
Connects-to: https://github.com/agherzan/meta-raspberrypi/issues/929

Can one of the admins verify this patch?

Hi @agherzan, should we switch to inheriting the pi3 machines in the pi0-2w instead? Also, should there be both 32 and 64 bit versions?

@acostach I'm fine with providing both but @kraj has a good point. The new machine only differ in dtb and Bluetooth firmware, right? So I'd say include the respective rpi3 ones and tweak the changes.

Thanks for reviewing this @agherzan @kraj , I've updated the branch according to your suggestions.
The Pi we have seems to only work with the bcm43436-sdio firmware so I've included both and updated the kernel to 5.10.78 to include the dts wifi changes https://github.com/raspberrypi/linux/commit/f71d77d11ea3a0cc391030b6c4eb5a0b22e9e787

I'll give it a spin tonight and merge if everything looks good.

@agherzan-ci ok to test

Perfect, thank you Andrei

Thanks @agherzan for merging this. Can it be backported to honister also?

Sure @floion . I'll handle this soon.

On a second check, it is already in honister. Is there something I'm missing?


chore: define creator for executable transaction

This change is

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#686  👈
#668 : 1 other dependent PR (#517 )
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @ArniStarkware and the rest of your teammates on  Graphite

crates/starknet_api/src/executable_transaction.rs line 214 at r1 (raw file):

            deploy_account_tx.calculate_transaction_hash(chain_id, &deploy_account_tx.version())?;
        Ok(Self { tx: deploy_account_tx, tx_hash, contract_address })
    }

There are two calculations done by this method:

calculation of the contract address.
calculation of the transaction hash.

Do they belong inside of a new method?
Code quote:
    pub fn new(
        deploy_account_tx: crate::transaction::DeployAccountTransaction,
        chain_id: &ChainId,
    ) -> Result<Self, StarknetApiError> {
        let contract_address = calculate_contract_address(
            deploy_account_tx.contract_address_salt(),
            deploy_account_tx.class_hash(),
            &deploy_account_tx.constructor_calldata(),
            ContractAddress::default(),
        )?;
        let tx_hash =
            deploy_account_tx.calculate_transaction_hash(chain_id, &deploy_account_tx.version())?;
        Ok(Self { tx: deploy_account_tx, tx_hash, contract_address })
    }

I think the validation code shouldn't be in the constructors:

It makes it hard to create testing instances and makes the tests unnecessary longer
It is CPU-bound and might cause the executor to get stuck in async code (not sure if this is a real issue)

Actually, I don't think it is correct to call the functions new as all the members are public so users don't need the functions to create instances.
A better approach IMO is to rename them tovalidate and change them to a method (work on &self).

Merge activity

Sep 8, 4:31 AM EDT: @ArniStarkware started a stack merge that includes this pull request via Graphite.


Performance: Require BufRead instead of just Read for inputs.

PTAL?

This PR changes the decoder from pulling fixed size 32KB chunks of input data to having the caller push arbitrary sized chunks of data into the decoder. The default for BufReader is 8KB, so that'll likely be a common choice for users who don't have the full image data already loaded into memory.
From testing locally on the QOI benchmark suite, I'm seeing a 1-2% performance regression with BufReader<&[u8]> over a plain &[u8]. I don't expect anyone would actually use that type, but BufReader<File> is probably pretty common and may approximate it.
I wonder if the performance gains you've seen on this were caused by avoiding the 32KB allocation+memset on very small images? If so, we could think about changes to control the size of the buffer based on the image size (likely by switching away from internally using a BufReader, and instead having a standalone buffer for reading IDAT chunks)

This PR changes the decoder from pulling fixed size 32KB chunks of input data to having the caller push arbitrary sized chunks of data into the decoder. The default for BufReader is 8KB, so that'll likely be a common choice for users who don't have the full image data already loaded into memory. That makes me a bit nervous since it adds a performance parameter out of our control and means there will be edge cases around small buffers that are hard to handle

I wonder if adding a benchmark that uses BufReader would lower the risk a little bit?  For example, we could add one additional benchmark testcase: noncompressed-128x128-with-default-bufreader.png.  WDYT?

From testing locally on the QOI benchmark suite, I'm seeing a 1-2% performance regression with a (default sized) BufReader<&[u8]> over a plain &[u8]. I don't expect anyone would actually use that type, but BufReader<File> is probably pretty common and may approximate it.

I think your experiment supports merging this PR:

Your experiment shows that an extra BufReader<...> leads to a performance regression (you say that when you compare BufReader<&[u8]> vs &[u8] the version with BufReader is slower by 1-2%)
Your experiment does not approximate what would happen for BufReader<File> (since there is no BufReader<...> in &[u8]).  For such approximation, I think that you can try comparing BufReader<u8> with 32kB of buffer (the old default) vs BufReader<u8> with 8kB of buffer (the new default from std).

I wonder if the performance gains you've seen on this were caused by avoiding the 32KB allocation+memset on very small images?

I think the data from the commit message suggests the opposite - the performance gains were much more pronounced for bigger images.  I speculate that this is because the savings come from avoiding copying all of the image data, rather than coming from the initial, fixed-size data or memset.  According to the commit message the savings looked as follows:

noncompressed-8x8.png:

[-2.2881% -1.4801% -0.4110%] (p = 0.00 < 0.05)
[-7.5687% -7.2013% -6.8838%] (p = 0.00 < 0.05)

noncompressed-128x128.png:

[-12.495% -12.132% -11.760%] (p = 0.00 < 0.05)
[-10.597% -10.230% -9.8399%] (p = 0.00 < 0.05)

Sorry, I should have been more clear. The performance regression I found only happens with this PR but not on the main branch. That was what concerned me.
Running a different experiment, I tried making this patch to the benchmarks:
--- a/benches/decoder.rs
+++ b/benches/decoder.rs
@@ -48,7 +48,7 @@ fn bench_file(c: &mut Criterion, data: Vec<u8>, name: String) {
     group.throughput(Throughput::Bytes(info.buffer_size() as u64));
     group.bench_with_input(name, &data, |b, data| {
         b.iter(|| {
-            let decoder = Decoder::new(data.as_slice());
+            let decoder = Decoder::new(std::io::BufReader::new(data.as_slice()));
             let mut decoder = decoder.read_info().unwrap();
             decoder.next_frame(&mut image).unwrap();
         })

I then ran each benchmark against the main branch and again against this PR:
decode/kodim17.png
                        time:   [+1.6160% +1.8703% +2.1665%] (p = 0.00 < 0.05)
                        thrpt:  [-2.1206% -1.8359% -1.5903%]

decode/kodim07.png
                        time:   [+1.3616% +1.6080% +1.9906%] (p = 0.00 < 0.05)
                        thrpt:  [-1.9517% -1.5826% -1.3433%]

decode/kodim02.png
                        time:   [+2.9415% +3.2626% +3.5050%] (p = 0.00 < 0.05)
                        thrpt:  [-3.3863% -3.1595% -2.8574%]

decode/kodim23.png
                        time:   [-0.3615% +0.5706% +1.3460%] (p = 0.21 > 0.05)
                        thrpt:  [-1.3281% -0.5674% +0.3629%]

decode/Lohengrin_-_Illustrated_Sporting_and_Dramatic_News.png
                        time:   [+6.5478% +6.8271% +7.1205%] (p = 0.00 < 0.05)
                        thrpt:  [-6.6472% -6.3908% -6.1454%]

decode/Transparency.png time:
                        time:   [+1.7512% +2.0166% +2.3704%] (p = 0.00 < 0.05)
                        thrpt:  [-2.3156% -1.9768% -1.7211%]

decode/generated-png:noncompressed-8x8.png
                        time:   [-0.0576% +0.1127% +0.2824%] (p = 0.20 > 0.05)
                        thrpt:  [-0.2816% -0.1125% +0.0576%]

decode/generated-png:noncompressed-128x128.png
                        time:   [+21.104% +21.693% +22.380%] (p = 0.00 < 0.05)
                        thrpt:  [-18.287% -17.826% -17.427%]

I'll also note I'm somewhat biased here. This API change would have some ripple effects for parts of the main image crate's API, probably requiring that crate to either unconditionally wrap PNG input streams in a BufReader or require all users of all decoders to adhere to the BufRead trait bound. If possible, I'd rather find a way to avoid that without sacrificing performance

@fintelia - could you please upload your benchmarking setup to a github repo + point out the hashes of the before/after commits?  This would help me understand what is being compared in your experiment.
Is it maybe like this?:

Before: origin/master (i.e. f80dfe93bc67e7a515aea9216af2a9feeeb696df) + benches/decoder.rs changes from your comment above (resulting in 2 BufReaders: first 8kB buffering and then 32kB buffering)
After: this PR (i.e. f24d4ffe43ce929dfcc1759d419e20aca37203c5) +  benches/decoder.rs changes from your comment above (only 1 BufReader with 8kB buffer)

This API change would have some ripple effects for parts of the main image crate's API, probably requiring that crate to either unconditionally wrap PNG input streams in a BufReader or require all users of all decoders to adhere to the BufRead trait bound.

Yes, this is true.  I think I'd prefer to require all users of image::codecs::png::PngDecoder to adhere to the BufRead trait bound (but not necessarily "all decoders").
I am also biased - the speed of decoding of in-memory PNGs is most important to me, because this is the form of PNG input in Chromium's //ui/gfx and in Chromium's Blink (in fact, if you squint your eyes, then blink::SegmentReader::GetSomeData is a little bit like BufReader::fill_buf, although there is no equivalent of BufReader::consume and blink::PngImageReader has to track "consumption" by managing the position argument / read_offset_ field).

I think that understanding the performance impact of this PR is important, so let's continue the discussion here.  At the same time, maybe the 2 PRs at https://github.com/image-rs/image-png/pull/429 and https://github.com/image-rs/image-png/pull/428 are less controversial and maybe this is where we can focus the review efforts for now?
Landing those other 2 PRs first may be desirable to:

Magnify the impact of the BufReader changes (and make it more easily measurable/detectable) by landing the other improvements first.  This should help to magnify any negative as well as positive impact.
Bundle the breaking changes together, as you've suggested elsewhere

BTW, one additional argument for not merging this PR yet is that so far Chromium has not landed any code that uses the png crate.  Hopefully this will happen soon, but I can understand the desire to prioritize the experience of existing consumers of the png crate (over the hypothetical, future experience of aspirational consumers - like Chromium).
Still, I am curious about the benchmarking results above, and would like to debug and understand them better.  (Although as I said before, this seems lower priority than discussing the other 2, less controversial PRs.)

For full transparency, let me share some recent observations.  I have rebased this PR on top of the latest changes, but when rerunning the benchmarks I've realized that for some testcases (e.g. noncompressed, 2048x2048 image, split across 64kB IDAT chunks) I observe a significant regression. The binary size and the number of instructions goes down<PHONE_NUMBER> instructions =><PHONE_NUMBER> instructions - 3% improvement), but the stalled backend cycles increase from 5.37% backend cycles idle to 40.61% backend cycles idle (which translates into a regression of the overall runtime). I think that getting rid of the intermediate BufReader means that decompression can consume much bigger chunks of input at a time (whole IDAT - 64kB, instead of the size of the intermediate BufReader - 32kB) and I am guessing that this change is somehow negatively impacting hardware-driven memory prefetching.  I don't yet understand what is happening exactly, what actions we can take, and what it means for this PR.

Any chance your CPU has a 64KB L1 cache? The current approach does three copies with size=32KB: input -> BufReader -> out_buffer -> data_stream, which should stay inside the L1 cache.
This PR changes it to two copies input -> out_buffer -> data_stream, but in the process makes the copy size depend on the underlying image's IDAT sizes. Which with 64KB IDATs means that the working set for each copy becomes 128KB

Let me convert this PR to a "draft", so that it won't get accidentally merged before we understand the performance impact better.  There are multiple factors at play, so I think that (instead of continuing the discussion here) I'll try to post something to https://github.com/image-rs/image-png/discussions/416.


Not listed option on whitelist

Any chance to create some kind of whitelist plus an Not listed, value?

Hey @andresmijares  - I don't quite follow. There's both a blacklist and whitelist option to let you pinpoint what countries get included. Does one of those work for you?

yeah! both work perfect but, I have an use case that goes as follows:
US
CAN
ARG
Not Listed
I need to catch that Not listed as well, does it support this case? :)
Ty for ur answer!


add support for fullPage

Hi @zhangheli, sorry for the delay! Thanks for your contribution, it has now been merged. A new release will hopefully be done soon, after we do some dependency maintenance.


SeparatedValuesFeeder enhancement

should support quote characters
should support header columns to be used for feed fields naming
maybe should be implemented on opencvs?

Header columns are mandatory since 1.0.0

Reimplemented in 1.1.0 based on opencsv.
Optional escape character supported.


Automated cherry pick of #7302: fix clone clean pending usage

Cherry pick of #7302 on release/3.0.
#7302: fix clone clean pending usage

/lgtm

/approve


Issues swapping between diff algorithms after changing it for the first time

After changing the diff algorithm, it starts to behave weirdly when trying to change it a 2nd time
This is on firefox 113.0.1
https://gyazo.com/66e5115dd98a76707c9d2feca68b1e2c

I tried to reproduce this but can't :/ if anyone else can, that'd be great to know


Add E2E tests

Codecov Report
Patch and project coverage have no change.

Comparison is base (180b96c) 100.00% compared to head (a7422cb) 100.00%.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff            @@
##              main       #28   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files            1         1
  Lines           40        40
  Branches         9         9
=========================================
  Hits            40        40

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


Performance evaluation of reference & Neptune implementations

Did quite a few measurements before concluding we should try to get the Neptune Rust implementation working.  The reference implementation was at least 100X too slow, and Neptune on several CPUs which is only about 10X slower than what we currently use.  There may be some Merkelization tricks we can in some longer term sense to make it less of a problem for our upload speeds.

an update from Charles


Fix flakes in idempotency test

Fixes https://github.com/istio/ztunnel/issues/888

In response to a cherrypick label: new pull request created: #1044


Wrong cast in buffer allocation (fixes #1367)

Thank you for your contribution. That's merged, polished, and backported now.


Redirecting to signup.php?error=C1

Every time I try to create an account, it reloads the page and shows no errors. What should I do?

Thanks for your interesting in my very first project!
I have written it for years ago, I don't have time to recheck it but you should take a look in the class/class.user.php and the signup.php file, it should be related to SQL problem, may be with your database config!

Yeah....  that's what we call a error 40 aka. human error

Hmm it's been a long time since the last time I have maintained this repo.  Maybe I will get back to it soon, with improved source code and feature!

Same here, error C1 : Request not fulfilled. Please try again later.


Draft model error when predicting at max context

Currently, when doing speculative sampling, the draft model's "lookahead" is not bound by cache_size, resulting in an error if we try to predict past it.
For example, if model ctx len is 4096 (and therefore cache_size too), assuming a num_speculative_tokens = 5, when the generation reaches 4092 tokens, it tries to predict 5 with draft model, and gives error in the 4097 one:
  File "example.py", line 199, in extract
    chunk, eos, _ = self.generator.stream()
  File "/usr/local/lib/python3.10/dist-packages/exllamav2/generator/streaming.py", line 143, in stream
    next_token, eos = self._gen_single_token(self.settings)
  File "/usr/local/lib/python3.10/dist-packages/exllamav2/generator/streaming.py", line 313, in _gen_single_token
    token, eos = self._gen_single_token_speculative(gen_settings, prefix_token)
  File "/usr/local/lib/python3.10/dist-packages/exllamav2/generator/streaming.py", line 332, in _gen_single_token_speculative
    logits = self.draft_model.forward(draft_sequence_ids[:, -1:], self.draft_cache).float().cpu()
  File "/usr/local/lib/python3.10/dist-packages/torch/utils/_contextlib.py", line 115, in decorate_context
    return func(*args, **kwargs)
  File "/usr/local/lib/python3.10/dist-packages/exllamav2/model.py", line 550, in forward
    assert past_len + q_len <= cache.max_seq_len, "Total sequence length exceeds cache size in model.forward"
AssertionError: Total sequence length exceeds cache size in model.forward

This should be fixed for a while now, and in any case the new generator has a new draft implementation.


Question about OS-default configurations

Just a clarification for me here.
Do I see this correctly, that the module does not include the OS' default configuration that you'd get when you just install rsyslog? I see that /etc/rsyslog.conf and /etc/rsyslog.d is replaced (if you not set purge_config_files to false), but the configuration from these files isn't prevailed.
So if we'd want to use the module on our network, we'd have to include all the defaults for the different OSes we're managing ourselves, right?

Replying to this old comment to confirm, for anyone else confused by this (like me): this module does indeed not provide any default configuration. Nothing generic and nothing OS-specific. It will, however, delete any default configuration that was put in place by the package manager and leave you with a non-functioning, unable-to-start rsyslog service.
Nothing in the README indicates this would be the case. On the contrary, the README explicitly states that just doing include rsyslog::config will "get you basic configuration for Rsyslog on your system". This is false. Instead it deletes any files in /etc/rsyslog.d and reduces /etc/rsyslog.conf to a single IncludeConfig directive.
So to people new to this module (if any): be sure to define the rsyslog configuration you expect before deploying this module, and maybe turn off purging of config files.

Just got bit by this when trying to migrate from @saz's module to this one.  This is some serious Neckbeard stuff.  Rsyslog is hard enough to grok, outright removing sane defaults is pretty horrible behavior.

@peelman that is your opinion. IMHO it is actually a good thing, most defaults that I have seen so far don't do at all what I want.
I agree the docs could be better, but I like that it keeps the default OS config unless you do actually include rsyslog::config. And it is not that trivial, eg debian12 still ships a default config in the old format :(
But as usual merge requests are always welcome :)

@peelman that is your opinion. IMHO it is actually a good thing, most defaults that I have seen so far don't do at all what I want. I agree the docs could be better, but I like that it keeps the default OS config unless you do actually include rsyslog::config. And it is not that trivial, eg debian12 still ships a default config in the old format :(
But as usual merge requests are always welcome :)

Have you tried submitting a merge request to the rsyslog folks with your preferred defaults that may be more useful?

This statement is a factual lie.  It in fact does the opposite.


solidity-coverage path is wrong because it references node_modules folder

Hello,
Node.js version: 9.11.2
npm version: 5.6.0
FIle: etherlime/cli-commands/etherlime-test/test.js
Line: https://github.com/LimeChain/etherlime/blob/master/cli-commands/etherlime-test/test.js#L6
Code sample:
let App = require('./../../node_modules/solidity-coverage/lib/app');

Package shouldn't be referenced by its path to node_modules, e.g.:
File path: node_modules/etherlime/cli-commands/etherlime-test/test.js
Referenced relative path: ./../../node_modules/
The above will look for node_modules @ etherlime folder which will not exist always.
Proposal:
let App = require('solidity-coverage/lib/app');

Thank you @vlad0 for helping. We will merge it soon


How long should I wait for the result generated after I perform the train.py?

I perform the train.py and I have adjusted  'prepro' parameter to false .By the way, I am new to machine learning, and I have run the train.py for 5 days.  Now, I have already run for 200K steps, and I wonder how long will the program finish?
Thanks for answering my question.

Which dataset did you use? I use the LJ Speech Dataset, and I have run for 2 days and half and is still running. Have your training finished now?


Add support for Meson build system

Many projects nowadays switched to the Meson build system (see their GitHub repository). Would be awesome to have the support out of the box.
Also related to https://github.com/facebook/infer/issues/1071 (since Meson can generate Ninja files).

Hi, we are not actively looking at this, but leaving the task open for other the chime in.

I've got a few projects written with the Meson buildsystem that I'd like to try, and it's super hard trying to build parts of them with Make just to try this. Meson integration would unlock a ton of big projects too! Thanks.


Negative filtering

Adds the excludes select component to support negative filtering
https://issues.redhat.com/browse/COST-2773

Codecov Report

Merging #2513 (e464b39) into main (d60491e) will increase coverage by 0.00%.
The diff coverage is 100.00%.

:exclamation: Current head e464b39 differs from pull request most recent head 87a77ac. Consider uploading reports for the commit 87a77ac to get more accurate results

@@           Coverage Diff            @@
##             main    #2513    +/-   ##
========================================
  Coverage   71.71%   71.72%
========================================
  Files         427      427
  Lines        7878     7880     +2
  Branches     1813     1679   -134
========================================
+ Hits         5650     5652     +2
  Misses       2225     2225
  Partials        3        3

Impacted Files
Coverage Δ

src/api/queries/query.ts
43.85% <ø> (ø)

src/locales/messages.ts
100.00% <ø> (ø)

src/store/featureFlags/featureFlagsActions.ts
100.00% <ø> (ø)

src/store/featureFlags/featureFlagsReducer.ts
76.92% <ø> (ø)

src/store/featureFlags/featureFlagsSelectors.ts
100.00% <100.00%> (ø)

Continue to review full report at Codecov.

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


400 Bad Request: malformed Host header for /v2/catalog

I tried running the broker as a docker container from the docker image available at frodenas/cf-containers-broker.
I ran the image using the command:
sudo docker run -d --name cf-containers-broker --publish 80:80 --volume /var/run:/var/run --volume /home/ubuntu/docker/cf-containers-broker/config:/config --volume /home/ubuntu/docker/cf-containers-broker/log:/app/log  frodenas/cf-containers-broker

However, I get this error while trying to query /v2/catalog.
Docker::Error::ClientError in V2::CatalogsController#show
400 Bad Request: malformed Host header

Here are the app logs:
Started GET "/v2/catalog" for <IP_ADDRESS> at 2016-09-22 09:45:16 +0000
Processing by V2::CatalogsController#show as JSON
  Request: {"headers":{"REMOTE_ADDR":"<IP_ADDRESS>","REQUEST_METHOD":"GET","REQUEST_PATH":"/v2/catalog","PATH_INFO":"/v2/catalog","REQUEST_URI":"/v2/catalog","SERVER_PROTOCOL":"HTTP/1.1","HTTP_VERSION":"HTTP/1.1","HTTP_X_BROKER_API_VERSION":"2.10","HTTP_X_VCAP_REQUEST_ID":"dc45b8a1-298d-4aff-6c90-0d90723c2e1d::d6a35a9d-d776-4f05-ab9f-6b48432c391a","HTTP_ACCEPT":"application/json","HTTP_AUTHORIZATION":"[PRIVATE DATA HIDDEN]","HTTP_USER_AGENT":"HTTPClient/1.0 (2.7.1, ruby 2.3.1 (2016-04-26))","HTTP_HOST":"<IP_ADDRESS>","SERVER_NAME":"<IP_ADDRESS>","SERVER_PORT":"80","QUERY_STRING":"","SCRIPT_NAME":"","SERVER_SOFTWARE":"Unicorn 5.0.0"},"body":""}
Completed 500 Internal Server Error in 7ms

Docker::Error::ClientError (400 Bad Request: malformed Host header):
  app/models/docker_manager.rb:249:in `validate_docker_remote_api'
  app/models/docker_manager.rb:20:in `initialize'
  app/models/plan.rb:66:in `new'
  app/models/plan.rb:66:in `build_container_manager'
  app/models/plan.rb:26:in `initialize'
  app/models/plan.rb:11:in `new'
  app/models/plan.rb:11:in `build'
  app/models/service.rb:11:in `block in build'
  app/models/service.rb:11:in `map'
  app/models/service.rb:11:in `build'
  app/models/catalog.rb:13:in `block in services'
  app/models/catalog.rb:13:in `map'
  app/models/catalog.rb:13:in `services'
  app/controllers/v2/catalogs_controller.rb:5:in `show'

  Rendered /usr/local/lib/ruby/gems/2.1.0/gems/actionpack-4.2.4/lib/action_dispatch/middleware/templates/rescues/_source.erb (5.5ms)
  Rendered /usr/local/lib/ruby/gems/2.1.0/gems/actionpack-4.2.4/lib/action_dispatch/middleware/templates/rescues/_trace.html.erb (2.1ms)
  Rendered /usr/local/lib/ruby/gems/2.1.0/gems/actionpack-4.2.4/lib/action_dispatch/middleware/templates/rescues/_request_and_response.html.erb (0.7ms)
  Rendered /usr/local/lib/ruby/gems/2.1.0/gems/actionpack-4.2.4/lib/action_dispatch/middleware/templates/rescues/diagnostics.html.erb within rescues/layout (15.2ms)

Any help is appreciated.

I was playing with the docker image today and experienced the same issue.


Tessera migration error

Tessera version: 0.9
using quorum-example/7nodes example, trying to migrate constellation to tessera, run ./stop.sh to stop the cluster, and use following script to do db migration:
**#!/bin/bash
set -u
set -e
for i in {1..7}
do
DDIR="qdata/c$i"
rm -f /home/zhou/go/src/github.com/quorum-examples/examples/7nodes/qdata/c$i/db$i*
rm -f "$DDIR/tm.ipc"
java -jar /home/zhou/go/src/github.com/tessera/data-migration/target/data-migration-0.9-SNAPSHOT-cli.jar -storetype dir -inputpath /home/zhou/go/src/github.com/quorum-examples/examples/7nodes/qdata/c$i/storage/payloads -dbuser sa -dbpass  -exporttype h2 -outputfile /home/zhou/go/src/github.com/quorum-examples/examples/7nodes/qdata/c$i/db$i
done**
then restart the cluster with tessera: ./istanbul-start.sh tessera
Got this error: Internal Exception: org.apache.commons.dbcp.SQLNestedException: Cannot create PoolableConnectionFactory
I don't know why there are too much connections, so I reboot the machine to clear them. Then restart the cluster again, both geth and tessera started, and seems tessera has connected to each other:
➜  7nodes git:(master) ✗ netstat -an|grep 9001
tcp6       0      0 <IP_ADDRESS>:9001          :::                    LISTEN
tcp6       0      0 <IP_ADDRESS>:9001          <IP_ADDRESS>:44998         ESTABLISHED
tcp6       0      0 <IP_ADDRESS>:44996         <IP_ADDRESS>:9001          ESTABLISHED
tcp6       0      0 <IP_ADDRESS>:9001          <IP_ADDRESS>:44922         ESTABLISHED
tcp6       0      0 <IP_ADDRESS>:9001          <IP_ADDRESS>:44996         ESTABLISHED
tcp6       0      0 <IP_ADDRESS>:9001          <IP_ADDRESS>:44948         ESTABLISHED
tcp6       0      0 <IP_ADDRESS>:9001          <IP_ADDRESS>:37252         ESTABLISHED
tcp6       0      0 <IP_ADDRESS>:44948         <IP_ADDRESS>:9001          ESTABLISHED
tcp6       0      0 <IP_ADDRESS>:9001          <IP_ADDRESS>:45026         ESTABLISHED
tcp6       0      0 <IP_ADDRESS>:44998         <IP_ADDRESS>:9001          ESTABLISHED
tcp6       0      0 <IP_ADDRESS>:44922         <IP_ADDRESS>:9001          ESTABLISHED
tcp6       0      0 <IP_ADDRESS>:45026         <IP_ADDRESS>:9001          ESTABLISHED
tcp6       0      0 <IP_ADDRESS>:37252         <IP_ADDRESS>:9001          ESTABLISHED
tcp6       0      0 <IP_ADDRESS>:9001          <IP_ADDRESS>:44962         ESTABLISHED
tcp6       0      0 <IP_ADDRESS>:44962         <IP_ADDRESS>:9001          ESTABLISHED*
but blocknumber was parked at 2, and tessera log shows below:
Call: SELECT ENCODED_PAYLOAD, TIMESTAMP, HASH FROM ENCRYPTED_TRANSACTION WHERE (HASH = ?)
bind => [1 parameter bound]
Query: ReadAllQuery(referenceClass=EncryptedTransaction sql="SELECT ENCODED_PAYLOAD, TIMESTAMP, HASH FROM ENCRYPTED_TRANSACTION WHERE (HASH = ?)")
07:31:10.218 [jersey-server-managed-async-executor-1] ERROR c.q.t.a.e.DefaultExceptionMapper - Exception [EclipseLink-4002] (Eclipse Persistence Services - 2.7.3.v20180807-4be1041): org.eclipse.persistence.exceptions.DatabaseException
Internal Exception: org.h2.jdbc.JdbcSQLException: Column "TIMESTAMP" not found; SQL statement:
SELECT ENCODED_PAYLOAD, TIMESTAMP, HASH FROM ENCRYPTED_TRANSACTION WHERE (HASH = ?) [42122-197]
Error Code: 42122
I don't know if anyone else has succeed in migrating from constellation to tessera, and there better have a official sample.

Hey.
There was an issue with the migration with version 0.8 (current release), where a new column that had been added wasn't included in the migration.
We have a solution we are testing right now (https://github.com/jpmorganchase/tessera/pull/671), but if you need this before it is merged, then you can treat the migration as a 2-step process.

Run the initial migration as you have done already.
Run the 0.7 -> 0.8 migration script included in the DDL folder. For H2, you want this script.

If you're building 0.9 from master the data-migration tool now included the timestamp column. This is an unreleased feature but if you do prefer having early access then you're more then welcome to try it out. Any feedback you have will is welcome.

I you don't want to build there is also a snapshot jar published as part of a ci build
https://oss.sonatype.org/content/repositories/snapshots/com/jpmorgan/quorum/data-migration/0.9-SNAPSHOT/data-migration-0.9-20190328.175742-32-cli.jar


Log targets append context message on every occasion

The collect function of the \yii2\log\Target class does a context message append just before exporting. However it does this after the messages have been filtered and it does not filter again.
What happens is every single log target gets this application info-level contextmessage appended, even though the categories and/or except rules this target has tell it not to include them.
It's being done regardless of anything:
$this->messages[] = [$context, Logger::LEVEL_INFO, 'application', YII_BEGIN_TIME];
This way I can't set up log targets that exclude these messages and thus every log target get's polluted by this even though I tell them not to.

If you do not want such message for a particular target, you can simply configure its logVars to be an empty array.


Question about OSC terror phases

Having some trouble understanding how the phase indication in OSC works (partly due to terrors not giving one with phases)
Is it 0 for no phases, and 1 for if it has phases plus further phases, or does it work differently?
(Mostly asking about the first terror, but if the other two terrors display differently let me know)

Is for Faker and Bliss, it is >0 when transformed.

Ah, so to confirm, if it was sonic for example, it starts on 0, but when he becomes faker, it becomes 1?

Yes

Alright, this should help, thanks for your time!


Uninstrument Node.pickableProperty in exchange for Node.inputEnabledProperty

This is a sub/side issue from https://github.com/phetsims/scenery/issues/1116.
@arouinfar noted the need to change client guides and overrides as part of this process. What fun!
On hold until #1116 is read to work for PhET-iO.

Node.inputEnabledProperty is not optionally instrumentable. So this issue is no longer on hold for https://github.com/phetsims/scenery/issues/1116, but I ran into https://github.com/phetsims/scenery/issues/1164, and I don't want to continue on this until that is solved.

Some points for this issue as a list:

[ ] Uninstrument pickableProperty from Node
[ ] Convert all usages of pickablePropertyPhetioInstrumented to -> inputEnabledPropertyPhetioInstrumented
[ ] Part of this work should be to look through instrumented usages of pickableProperty and make sure that we are now setting inputEnabled instead. This is from https://github.com/phetsims/scenery/issues/1116#issuecomment-773554757
[ ] Update all the Client guides that contain pickableProperty stuff
[ ] Update all the overrides files that contain pickableProperty stuff
[ ] Confirm in some studio instances that there are no more pickableProperties

We decided we didn't want to publish another PhET-iO simulation with pickableProperty, and instead want to use inputEnabled now. Marking as blocking.

At PhET-iO meeting today, we determined that Gravity and Orbits will not need to have pickableProperty removed. So we will just do this on master.

Now that #1116 and https://github.com/phetsims/scenery/issues/1175 have been committed to, we can mark this off hold.

Questions for the future:

Should we be able to pass in a pickableProperty, even though it will never be PhET-iO instrumented? That isn't currently supported in Node by anything (in other words: the only TinyForwardingProperties are those which support PhET-iO instumentation). For example, you can't pass in a Property to be a Node's opacityProperty. So should pickableProperty be converted back (downgraded) to a TinyProperty, which can't be overridden (like opacity), or should we still allow setPickableProperty( myProperty )

Initial work has been done. Co-assigning @arouinfar to review https://github.com/phetsims/phet-io-client-guides/commit/c96920e0c93a7bbbe5730ea5998f8245f6bb4146
From here I will watch CT and report issues. @samreid can you review, and discuss the questions above?

There are cases where instrumentation was relying on pickableProperty, like in
https://github.com/phetsims/ph-scale/blob/c7bfbd28343a7766dbab588074902178d65ddc09/js/common/view/graph/GraphIndicatorNode.js#L179-L184
@pixelzoom will want to review his sims to make sure these get changed also.

@zepumph it looks like find/replace all worked for client guides. I read through https://github.com/phetsims/phet-io-client-guides/commit/c96920e0c93a7bbbe5730ea5998f8245f6bb4146 and everything looks really good. Since this isn't something we'll be cherry-picking into release branches, I don't think we'll need to make any further changes to client guides. Thanks for taking care of the edits! Not sure if there is anything else left for this issue, so back to you @zepumph.

@pixelzoom will want to review his sims to make sure these get changed also.

Tracking in sim-specific issues, as linked above.

Over to @samreid for review.

Should we be able to pass in a pickableProperty, even though it will never be PhET-iO instrumented?

Here are some Properties that look like they can be passed in (I'm searching for setTargetProperty)

visibleProperty
pickableProperty
enabledProperty

PhET-iO instrumentation seems independent from whether you should be able to pass in a Property.  It seems like it would round out the API to be able to pass in a pickableProperty, even if we use that rarely.  It looks like pickableProperty is listed in the mutation keys, and the setter seems wired up properly, so I don't understand why it isn't already possible to pass in a pickable property.  If it really is not currently supported, what are the drawbacks of adding support for that?

I noticed that there aren't getters for *PhetioInstrumented boolean options. Should there be? I think "no", but maybe?

I think if someone called myNode.enabledPropertyPhetioInstrumented and got back a falsy value of undefined, it could be confusing and difficult to debug, so it would be nice to add the getters.


Fails to match valid Authorization header

Per https://tools.ietf.org/html/rfc2617#section-1.2, the Authorization header can have Bearer or bearer but the current regex only matches one case.

https://github.com/30x/microgateway-plugin-sso-proxy/issues/17

BEARER and BeArEr are also valid - the string is case-insensitive.


Need a function for generating random unitary matrix with a given fixed trace

Need a function for generating random unitary matrix with a given fixed trace

randPermutation(n::Int, fix = 0::Int)

Generate a random permutation matrix.  If fix = x, randPermutation(n,x) will have atleast x fixed points


add option to always show placeholder: placeholderAlwaysVisible to ui-select-match

In tagging use case, it is useful sometime when you still want to display the placeholder even when something is selected.

@ptgamr  We are not keen on adding a plethora of directive attributes to the components. I would love to see a PR that refactors the the directives away from having a million attributes and instead accepting a config object.

Changes to dist need to be undone, and this looks like it'd need tests.

This can probably be written as a separate directive:
app.directive('placeholderAlwaysVisible', function() {
  return {
    require: 'uiSelect',
    link: function($scope, $element, attrs, $select) {
      $select.getPlaceholder = function () {
        return $select.placeholder;
      }
    }
  }
});

Hello, I have the same request, also tried making separate directive just as you shown before, but it doesn't seem to be workring.
Here is my controller
.directive('alwaysShowPlaceholder', function () {
    return {
      restrict: 'A',
      require: 'uiSelect',
      link: function ($scope, $element, attrs, $select) {
        console.log($select);
        console.log($select.getPlaceholder);
        $select.getPlaceholder = function () {
          return $select.placeholder;
        }
      }
    };
  });

and html
<ui-select ng-if="permissionGroup.inEditMode"
                   multiple
                   class="separate-rows"
                   theme="bootstrap"
                   always-show-placeholder
                   ng-model="permissionGroup.permissions">
          <ui-select-match >{{$item.displayText}}</ui-select-match>
          <ui-select-choices repeat="permission in PermissionArray | filter:$select.search">

          </ui-select-choices>
        </ui-select>

and the resulting output is:
Object {...}
undefined

which make me think  that we don't have access to the underlying functions or they are not initialized at that moment, so after they initialize they overwrite our implementation.
I would really appreciate if you would help me with that problem.

Plunkr? I suggest maybe also trying to adjust directive priority

Thank you for the quick response, here is the plunkr with priority property set and also executed on post link stage:
http://plnkr.co/edit/pe8v5ZeWXfloYfqE4AVd?p=preview

.getPlaceholder() is defined in uiSelectMultipleDirective's controller: $selectMultiple
So you can't override it in uiSelectDirective's controller: $select

And because of this switching template logic: https://github.com/ptgamr/ui-select/blob/cb2c5611450ea5bf5fa806416c180af9273a2755/src/uiSelectDirective.js#L21 , it's not easy to override this behavior...

@user378230 I can suggest to move getPlaceholder to $select, so user can easily override the behavior if needed to.
I'm happy to update the PR if this way is the correct way to go.

@ptgamr that sounds like a good idea, can you update single select to use getPlaceholder (it should always return placeholder for single select but its good to allow users to override getPlaceholder for single select if they like.


Update README: Change Localhost Port to 5173

Description:
The current README suggests that the application runs on http://localhost:3000, but based on the project setup or default Vite configuration, it should be http://localhost:5173 instead.
Suggested Fix:
Update the README file to change all references of http://localhost:3000 to http://localhost:5173.
Steps to Reproduce:

Run the application locally as instructed in the README.
Notice that the server runs on http://localhost:5173 instead of http://localhost:3000.

Additional Context:
Updating the README will help avoid confusion for new contributors and users running the application locally.

Please assign this issue to me under hacktoberfest

i cant assign issues but you can fix it whenever you want

ok


appparts: borrowed partition invoke should return error if unexpected processor kind

Context
https://github.com/voedger/voedger/blob/a033484412a33c33b78a36e0da8e427ef1b62c73/pkg/appparts/impl_app.go#L213
TODO
Invoke() should return error if definition type kind (query, command, sync or async projector, job) is not match borrowed processor kind.

done in https://github.com/voedger/voedger/pull/2519


User guide v1.3

Codecov Report

Merging #192 into master will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master     #192   +/-   ##
=========================================
  Coverage     82.71%   82.71%
  Complexity     1049     1049
=========================================
  Files           150      150
  Lines          3107     3107
  Branches        376      376
=========================================
  Hits           2570     2570
  Misses          444      444
  Partials         93       93

Continue to review full report at Codecov.

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