Non-issue: relative style layers weights

I have for a long time been interested in the idea of adjusting the weights of style layers separately. For instance if I see that some layer is having far larger or smalled than typical losses,  it would be interesting to be able to adjust the weights.
I have now implemented this in https://github.com/htoyryla/neural-style by adding a new parameter -style_layer_weights, which accepts a comma-separated list of multipliers. The weight of each style layer will then be multiplier * style_weight. If the parameter is omitted, each layer will have multiplier = 1.
I assume that this is not for the average user, and that's why I didn't make this a pull request. But there might be other experiment-oriented users around, so I am letting them know that this exists.

@htoyryla  is there a good way of understanding what each style layer is filtering?

StryxZilla<EMAIL_ADDRESS>kirjoitti 5.6.2016 kello 18.23:

@htoyryla is there a good way of understanding what each style layer is filtering?

Not in exact terms, as far as I know. The very lowest layers see colors, then going upwards: lines, curves and shapes, until the upper layers see complex features.
This https://github.com/htoyryla/convis can be used to view what the filters of a layer see in a particular image.

@htoyryla I think you are onto something with the style_layer_weights. I did a quick test and even with a rough "balancing" I was able to bring the style loss of each layer to be about the same. The resulting image was better than without.
This made me think. What if for each cycle neural-style was to take the style_losses values, get the max value and then apply a weight correction for the next pass. This would essentially try to balance the next cycle loss based on the observes loss of the previous cycle. At then end, the goal of style transfer is to transfer the style of the source image... but the current method leave individual layer style loss to vary. If a try style was made then the style loss of each layer would be the same, no matter what.
I tried to implement this but my programming skills in lua are way too bad. The best I can do is pseudo-code if someone was brave enough to implement:
maxloss = max (style_losses)
for i,  loss_module in ipairs(style_losses) do
layerweight = maxloss / loss_module
if layerweight = 0 then layerweight = 1 # in case this is the 1st run and there is no known loss
end

bmaltais<EMAIL_ADDRESS>kirjoitti 13.6.2016 kello 20.14:

@htoyryla I think you are onto something with the style_layer_weights. I did a quick test and even with a rough "balancing" I was able to bring the style loss of each layer to be about the same. The resulting image was better than without.
This made me think. What if for each cycle neural-style was to take the style_losses values, get the max value and then apply a weight correction for the next pass. This would essentially try to balance the next cycle loss based on the observes loss of the previous cycle.

I could try something like this (and a similar idea crossed my mind earlier) when I have time.
Intuitively, I feel that there is a danger of disrupting the balance between style and content, which, with fixed weights, naturally changes during the iterations when at times content, at times style, converges better. But this is simply something to keep in mind and make sure that this automatic balancing to style weights does not too much change the overall weight of style vs content.

I was under the impression that driving the style loss would result in greater content loss for some layers but would result in a closer style match at the end... with greater loss of content details in some are... but better style overall. I guess this will only be known if you are able to implement this potential feature ;-)
Looking forward to test it if you ever find the time to code it in.

bmaltais<EMAIL_ADDRESS>kirjoitti 13.6.2016 kello 21.07:

I was under the impression that driving the style loss would result in greater content loss for some layers but would result in a closer style match at the end... with greater loss of content details in some are... but better style overall.

I guess there are several ways of balancing style weights across layers, and some ways would change the overall style-content balance while others wouldn’t. My preference is to keep style balancing separate from the style weight / content weight adjustments. Of course, automatic adjustment of style versus content weight might also be an interesting concept, but it is a different concept.
This is something to remember already now when experimenting with style layer weights. Do we get different results because we get better control from all layers, or because we have actually increased the overall style weight (for which we do not need layer specific weights).
Personally, I am not sure any single procedure will result in improvements with all materials. The optimization process in neural-style is so complex. Change something and the process will suddenly find another valley altogether. Yet, it is good to have settings to adjust when looking for better results.
But let’s see. This is interesting enough to try but just now I am busy with other things. Perhaps next week.

Looking at my pseudo code I think I had it backward. I was in fact accentuating instead of balancing the loss. The following code appear to be better suited:
minloss = min (style_losses)
local style_layer_weights = {}
for i,  loss_module in ipairs(style_losses) do
  if minloss = 0 then # in case this is the 1st run and there is no known loss
    table.insert(style_layer_weights, 1)
  else
    style_layer_weights_val = minloss / loss_module
    table.insert(style_layer_weights, style_layer_weights_val)
end

This code will essentially reduce the weight of high loss layers, hence resulting in a balance of loss when compared with the layer with the least loss.

I was anyway planning to think it through myself. I think that if the goal is to balance the style losses from different layers, it can (and should) be done inside feval(), as that is what is run in each iteration. And if the balance can be adjusted right away then actually there is no need for storing weights for the next iteration.
Maybe you could now try your version? Have a look at feval(). There you have access to style losses from each layer and you can adjust them before they are added to the total loss.
Just note that style_losses contains the loss modules (= code + data to handle loss) , and in
for _, mod in ipairs(style_losses) do
loss = loss + mod.loss
end
it is mod.loss that contains the style loss value from the current iteration.
Hannu
bmaltais<EMAIL_ADDRESS>kirjoitti 13.6.2016 kello 22.42:

Looking at my pseudo code I think I had it backward. I was in fact accentuating instead of balancing the loss. The following code appear to be better suited:
minloss = min (style_losses)
local style_layer_weights = {}
for i,  loss_module in ipairs(style_losses) do
if minloss = 0 then # in case this is the 1st run and there is no known loss
table.insert(style_layer_weights, 1)
else
style_layer_weights_val = minloss / loss_module
table.insert(style_layer_weights, style_layer_weights_val)
end
This code will essentially reduce the weight of high loss layers, hence resulting in a balance of loss when compared with the layer with the least loss.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

bmaltais<EMAIL_ADDRESS>kirjoitti 13.6.2016 kello 22.42:

if minloss = 0 then # in case this is the 1st run and there is no known loss
Furthermore, if I am not mistaken, already the first run produces valid loss values, as the loss is computed, roughly speaking, as the difference between the target and the current result.

It may still be necessary to have special handling for the first iteration, but it is not immediately obvious for me. Then, if you need to know whether this is the first run, you can check it from num_calls.

Yeah, I am not very good with lua I must say ;-) This was just basic pseudo code to express how I thought the problem could be approached but I trust you can do a much better and optimized one ;-)
I will publish a link to a comparison of no layer_style weight (all 1) vs a tuned one using the 1000th iteration result as the adjustment values using the formula in the 2nd pseudo code above.

Here is the comparison: https://twitter.com/netputing/status/742449976429535232
Pretty radical if you ask me

Tweak was: -style_layer_weights .288,.255,.249,.009,.025,.093,.005,.043,1,.026
With 1st image loss being:
Iteration 1000 / 1000
  Content 1 loss: 0.003941
  Content 2 loss: 0.004568
  Content 3 loss: 0.003562
  Content 4 loss: 0.026721
  Content 5 loss: 0.014100
  Content 6 loss: 0.005582
  Content 7 loss: 0.019614
  Content 8 loss: 0.006781
  Content 9 loss: 0.001201
  Content 10 loss: 0.005899
  Style 1 loss: 2142.516710
  Style 2 loss: 2421.563864
  Style 3 loss: 2480.307221
  Style 4 loss: 70729.875565
  Style 5 loss: 24952.839315
  Style 6 loss: 6668.104231
  Style 7 loss:<PHONE_NUMBER>71
  Style 8 loss: 14482.873678
  Style 9 loss: 617.072918
  Style 10 loss: 23917.636275
  Total loss:<PHONE_NUMBER>18

vs tweaked loss being:
Iteration 1000 / 1000
  Content 1 loss: 0.003790
  Content 2 loss: 0.004413
  Content 3 loss: 0.003455
  Content 4 loss: 0.026003
  Content 5 loss: 0.013749
  Content 6 loss: 0.005467
  Content 7 loss: 0.019187
  Content 8 loss: 0.006695
  Content 9 loss: 0.001188
  Content 10 loss: 0.005787
  Style 1 loss: 141.991130
  Style 2 loss: 108.425413
  Style 3 loss: 84.199913
  Style 4 loss: 1128.063941
  Style 5 loss: 648.735538
  Style 6 loss: 457.198982
  Style 7 loss: 989.381075
  Style 8 loss: 584.940869
  Style 9 loss: 384.389726
  Style 10 loss: 583.861947
  Total loss: 5111.278266

bmaltais<EMAIL_ADDRESS>kirjoitti 13.6.2016 kello 23.10:

Yeah, I am not very good with lua I must say ;-) This was just basic pseudo code to express how I thought the problem could be approached but I trust you can do a much better and optimized one ;-)

No, I frankly meant that you might try it yourself. Have a look at feval(), it is pretty compact. There you have all style loss values (mod.loss values in the loop) before they are added to the total loss. You just need to add your logic for adjusting them.
I think you need to adjust the loss values, not the weights, because when the style modules have been created, they have been initialized with the weights then, so the weights cannot be used dynamically as they work now.
But it should be rather simple to collect the values from each mod.loss, find minimum or maximum, make adjustments and then add them together.

Have a look at feval(), it is pretty compact. There you have all style loss values (mod.loss values in the loop) before they are added to the total loss. You just need to add your logic for adjusting them.
I think you need to adjust the loss values, not the weights, because when the style modules have been created, they have been initialized with the weights then, so the weights cannot be used dynamically as they work now.
But it should be rather simple to collect the values from each mod.loss, find minimum or maximum, make adjustments and then add them together.

One more thing� if and when the lossess are adjusted in feval(), the printed losses per layer will be unaffected, so something more is still needed to print the adjusted losses in maybe_print().

Tried to change the feval() mod.loss value but it does not change the resulting image... just the reported loss values. Too bad it is not possible to change weights for every iteration. Might be that the best is to run two pass. One to get an estimate of the needed weights and a 2nd one to generate the final result.

Out of the curiosity - what layers do you use? Originally there were just
5. You have 10.
On Monday, June 13, 2016, bmaltais<EMAIL_ADDRESS>wrote:

Tried to change the feval() mod.loss value but it does not change the
resulting image... just the reported loss values. Too bad it is not
possible to change weights for every iteration. Might be that the best is
to run two pass. One to get an estimate of the needed weights and a 2nd one
to generate the final result.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/jcjohnson/neural-style/issues/237#issuecomment-225728804,
or mute the thread
https://github.com/notifications/unsubscribe/ARjIQ1c52YM9J1NT-PFKZwIp6U786Rfsks5qLdrlgaJpZM4IqVCw
.

I used @htoytyle convis to look at the layers that reacted to the content image and selected all that actually reacted and left the other ones out
-style_layers relu0,relu1,relu2,relu3,relu5,relu6,relu7,relu8,relu9,relu10

As I see from your tweaked settings some layers suppressed by few orders of magnitude comparing to others. You did this to lower losses on those layers but doing so seems to be roughly equivalent to excluding them. For example, layer 7 has weight factor of 0.005. You adjusted it because it had huge loss comparing to others. So according to your intuition if layer has bigger loss it should be suppressed. Basically it means you are trying to keep those style layers which "closer" to the original image. If style layer differs too much you are suppressing it. Generally such feature you are willing to add means it will try to choose layers with minimal losses. I'm curious about outcome as well.

From other side adjusting layer weights on the fly means that contribution of each participating layer will be equalized so resulting image will be affected by gradients from all participating layers equally. Nice idea actually.

@mystcat If you look at the twitter link I posted above you can see the result of tweaking the the weights. I agree that it is almost like suppressing some of them... but there are still some influence left and I think the neural network can still account for them in some ways. The resulting image is actually pretty good looking compared to the unweighted values.

bmaltais<EMAIL_ADDRESS>kirjoitti 14.6.2016 kello 1.34:

Tried to change the feval() mod.loss value but it does not change the resulting image... just the reported loss values. Too bad it is not possible to change weights for every iteration. Might be that the best is to run two pass. One to get an estimate of the needed weights and a 2nd one to generate the final result.

mod.loss is the loss reported by the loss module, so changing it does indeed only change the printed value. What counts is what you add to the total loss.
But you are probably right that you indeed have to change the weights inside the loss module to have the correct effects,  to get the gradients right. It should actually be possible to change the weights dynamically by changing mod.strength. Just note this strength, in my version, is the style_weight multiplied by the style_layer_weight.

mystcat<EMAIL_ADDRESS>kirjoitti 14.6.2016 kello 2.25:

From other side adjusting layer weights on the fly means that contribution of each participating layer will be equalized so resulting image will be affected by gradients from all participating layers equally. Nice idea actually.

I tend to think that the differences between the loss values from different layers do not necessarily mean that one the output layer matches the target better, but that the architecture of the model and similar reasons also affect the loss range from each layer. If that is correct, it is really equalizing we are talking about, not excluding some layers as it might seem first.
But if the differences are due to architectural reasons, then the relative output ranges of each layer should not change so much from iteration to iteration, and adjusting the equalization at each iteration would not be needed. But anyway, bmaltais’ concept of doing the equalization automatically makes it easier to use, and in fact one might readjust the equalization less often than at every iteration.

If I understand loss function correctly - it is exactly what it does. Style
loss computes difference between gram matrices of content and style. So
lower the difference better style match.
On Mon, Jun 13, 2016 at 11:32 PM, Hannu Töyrylä<EMAIL_ADDRESS>wrote:

mystcat<EMAIL_ADDRESS>kirjoitti 14.6.2016 kello 2.25:

From other side adjusting layer weights on the fly means that
contribution of each participating layer will be equalized so resulting
image will be affected by gradients from all participating layers equally.
Nice idea actually.

I tend to think that the differences between the loss values from
different layers do not necessarily mean that one the output layer matches
the target better, but that the architecture of the model and similar
reasons also affect the loss range from each layer. If that is correct, it
is really equalizing we are talking about, not excluding some layers as it
might seem first.
But if the differences are due to architectural reasons, then the relative
output ranges of each layer should not change so much from iteration to
iteration, and adjusting the equalization at each iteration would not be
needed. But anyway, bmaltais’ concept of doing the equalization
automatically makes it easier to use, and in fact one might readjust the
equalization less often than at every iteration.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jcjohnson/neural-style/issues/237#issuecomment-225771123,
or mute the thread
https://github.com/notifications/unsubscribe/ARjIQ04EVvP2cgSJkE1ZuidOt9HVXlWsks5qLiDTgaJpZM4IqVCw
.

mystcat<EMAIL_ADDRESS>kirjoitti 14.6.2016 kello 6.44:

If I understand loss function correctly - it is exactly what it does. Style
loss computes difference between gram matrices of content and style. So
lower the difference better style match.

I have understood that for content layers,  content image is fed into the model and the output of the layer is stored as the target. The loss is then the �difference� between the current image and the target.
For style layers, it works similarly except that the Gram matrix is added on top of the layer, to give a representation of style instead of content. Feed the style image into the model and store the output as the style target to be used in calculating the loss.
So the content and style are not compared, and the gram matrix is not used for content. Layer output is compared with the target obtained using the content image => content loss, and Gram matrix output is compared with the target obtained from the same layer�s Gram matrix using the style image => style loss.
But then yes, the lower the loss, the closer to the target.

I am sorry but to my understanding this statement is far from truth:

So the content and style are not compared, and the gram matrix is not used for content

This exact line calculates gram matrix for the current image (eg content being processed):
self.G = self.gram:forward(input)
And this line calculates difference between style gram matrix and current image gram matrix:
local dG = self.crit:backward(self.G, self.target)
Criterion is standard MSE
Style layer gram matrices are calculated during model initialization and do not change during optimization process. Content gram matrices are being calculated at each iteration and then compared to style gram matrices which are target.

mystcat<EMAIL_ADDRESS>kirjoitti 14.6.2016 kello 7.48:

I am sorry but to my understanding this statement is far from truth:
So the content and style are not compared, and the gram matrix is not used for content
This exact line calculates gram matrix for the current image (eg content being processed):
self.G = self.gram:forward(input)
And this line calculates difference between style gram matrix and current image gram matrix:
local dG = self.crit:backward(self.G, self.target)
Criterion is standard MSE
Style layer gram matrices are calculated during model initialization and do not change during optimization process. Content gram matrices are being calculated at each iteration and then compared to style gram matrices which are target

We are using the word content in different senses. When I say content, I mean the -content_image which is the target for content only.
When you say content, you talk about the output image which is being generated. Of course the STYLE of the image being generated is compared with the style image using Gram matrices.

STYLE of the image being generated
The image being generated based on content by definition. Optimization process "bends" or "pushes" content image to match style image. It uses gram matrices of both to calculate the difference.
Yes it doesn't calculate gram matrices of original content image (except for the first iteration). Only from the one being optimized.

There are only content and style images as algorithm input (aside from parameters). So result is content pushed towards style. In that sense image being optimized is content. We do not change style.

I guess you are thinking in terms of using -init image. Then the original content image is gradually modified, yes.
The default is starting from random noise, which is pushed towards bot style and content targets.
Anyway, if you read the original paper, it is about content and style as elements of an image which can be separated and combined.
If will be difficult to continue a discussion if you insist on another terminology.
I guess there is no point in arguing about this any longer.
mystcat<EMAIL_ADDRESS>kirjoitti 14.6.2016 kello 8.01:

STYLE of the image being generated
The image being generated based on content by definition. Optimization process "bends" or "pushes" content image to match style image. It uses gram matrices of both to calculate the difference.
Yes it doesn't calculate gram matrices of original content image (except for the first iteration). Only from the one being optimized.
There are only content and style images as algorithm input (aside from parameters). So result is content pushed towards style. In that sense image being optimized is content. We do not change style.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

@bmaltais , I think this implements your idea inside feval():
  local num_calls = 0
  local function feval(x)
    num_calls = num_calls + 1
    net:forward(x)
    local grad = net:updateGradInput(x, dy)
    local loss = 0
    for _, mod in ipairs(content_losses) do
      loss = loss + mod.loss
    end
    local slosses = torch.Tensor(#style_losses)
    for i, mod in ipairs(style_losses) do
      loss = loss + mod.loss
      slosses[i] = mod.loss
    end
    local minloss = torch.min(slosses)
    for i, mod in ipairs(style_losses) do
      mod.strength = (minloss / mod.loss) * params.style_weight
    end
    maybe_print(num_calls, loss)
    maybe_save(num_calls)

    collectgarbage()
    -- optim.lbfgs expects a vector for gradients
    return loss, grad:view(grad:nElement())
  end

params.style_weight is used here
      mod.strength = (minloss / mod.loss) * params.style_weight

because minloss/mod.loss will be 0..1 and mod.strength should be = style_weight * layer_weight.
This runs but is not quite stable
Iteration 80 / 1000
  Content 1 loss:<PHONE_NUMBER>78
  Style 1 loss: 5.019568
  Style 2 loss: 336.770164
  Style 3 loss: 2149.705239
  Style 4 loss: 528.574245
  Style 5 loss: 2611.889076
  Total loss:<PHONE_NUMBER>71
Iteration 81 / 1000
  Content 1 loss:<PHONE_NUMBER>78
  Style 1 loss: 27554.019165
  Style 2 loss: 4160.545138
  Style 3 loss: 352.721948
  Style 4 loss: 97156.932369
  Style 5 loss: 5.016697
  Total loss:<PHONE_NUMBER>94

Using
      mod.strength = (minloss / mod.loss) * mod.strength

keeps style losses amazingly well, perhaps too well, equalized:
Iteration 7 / 1000
  Content 1 loss: 2091152.343750
  Style 1 loss: 656.860093
  Style 2 loss: 656.860093
  Style 3 loss: 656.860093
  Style 4 loss: 656.860010
  Style 5 loss: 656.859997
  Total loss: 2094436.644035
Iteration 8 / 1000
  Content 1 loss: 2091147.031250
  Style 1 loss: 656.859997
  Style 2 loss: 656.859997
  Style 3 loss: 656.860050
  Style 4 loss: 656.859956
  Style 5 loss: 656.859997
  Total loss: 2094431.331247

Let's see what kind of images this produces. I still think that it might be better to equalize only at very n-th iteration.

Equalizing at every n-th iteration is simple:
    if (num_calls % 50 == 1) then
      local minloss = torch.min(slosses)
      for i, mod in ipairs(style_losses) do
        mod.strength = (minloss / mod.loss) * mod.strength
      end
    end

What worries me that the style losses stay constant, not only equalized but really almost constant. It would seem to me that this is not good for the gradients. Have to see how this works. It is possible that I have a bug somewhere.

I tested how this reacts to increasing style_weight. The losses do increase correspondingly, but one gets "function value changing less than tolX" very easily. Probably further experimentation is needed to get the feedback loop working without side-effects.

Wow, a lot of work last night on this. I did a quick test and this is a whole new territory to explore. Applying the balancing at every iteration has some major effect. Even applying only on nth iteration is significant. It will get some more exploration to find if it is actually useful or useless as an option.
I will try to implement a gradual weight parameter such that the balancing effect will be way less and 1st and 100% on the last iteration. Perhaps this will help with the overall result.
Something like:
mod.strength = (minloss / mod.loss) * mod.strength * num_calls / params.num_iterations

bmaltais<EMAIL_ADDRESS>kirjoitti 14.6.2016 kello 15.28:

I will try to implement a gradual weight parameter such that the balancing effect will be way less and 1st and 100% on the last iteration. Perhaps this will help with the overall result.
Something like:
mod.strength = (minloss / mod.loss) * mod.strength * num_calls / params.num_iterations

Sounds interesting but be careful. Mod.strength is the total weight of the style for this layer, so this line would cancel any effect of style initially. You need a calculation that will leave mod.strength as it is when num_calls is small.

@htoyryla

if you read the original paper

Yes I did. As many researchers proved later, authors were wrong about at least two things:

Random initialization does NOT give good results. Nobody uses it in their production systems like deepart (backed by authors themselves) or ostagram (uses jcjohnson implementation).
AVG pooling does NOT give more appealing results either.

So we are speaking about "-init image" here by definition - common sense after millions of generated images. Please don't appeal to original paper if you are not following it thoroughly.
Ability to admit his own mistake is a quality of strong minds. It is indeed easier to just close discussion if you are running out of arguments.
I agree it doesn't worth time to continue this argument. I just wanted to point out that some claims were false. Didn't want to prove you anything. It doesn't worth time.
Thank you for trying proposed idea anyway.

@mystcat,  you are defining "content" different from the sense of separating content and style. It is my mistake I did not realize that before my comments.
My description of the process is still valid. The core idea behind neural-style is that content loss can be measured from a conv layer and style loss can be measured from a Gram matrix appended on top of a conv layer. In this sense gram matrix is indeed not used for content, as its function is to extract a representation of style. There is nothing wrong in what I wrote, writing about content and style as two elements in any image. You understood content as an image to which style is being transferred. Had I realized that before my comment, I wouldn't have written it.
If you still don't realize this, but continue to call my claim "false", then we indeed have no basis for a discussion. Content in the sense opposed to style is indeed not measured by a Gram matrix. The style of an image, which of course can also be called content, is of course measured by a Gram matrix.
Whether or not -init random or -init image works better is a side issue. I still prefer the more unambiguous usage of content and style as two elements in any image, and refer to the images by more specific terms. This is simply because it is safer, not tied to any particular method or implementation.

Thank you for explanation. It makes sense. Indeed we operated different terminology.
Your contribution to this project is very valuable. Thank you for all your input. Appreciate that.
You helped myself to understand the subject better by learning from your experiments.

I'll need to be more alert concerning terminological issues. I used to be quite good at spotting them when I was working together with people in real life. Internet is much more difficult. I'm sorry for this.
Concerning -init image, I have noticed that people prefer it now, but I still use -init random almost always. Perhaps it is my style, I am not after photorealistic results, but more like art prints. I usually combine several images, perhaps add something by hand, and print them with an ink jet on fine art paper, when selecting the type of paper also significantly affects the look of the final image.

By the way, it is an interesting outcome.
Would you like to figure out together what is style and what is content? What is the nature of "separation of content from style"?
According to authors they are discarding spatial part of style image and keep only the "style" part which is very subjective. It is how we perceive image regardless of spatial information. Authors proposed very interesting method for such style (perceptive part) extraction using gram matrices.
From other hand we have source image (which I called content) from which we are willing to keep only spatial information. But it is not completely true. We want to keep style of original image to some extent. For example, image perceived better if lips are reddish (assuming such colors exists on style image). It is exactly what algorithm does - it usually sticks similar colors from style to same colors in content. Thus it does keep style of content image, not only spatial part.

Now it IS getting interesting. I admit that my understanding of "style" in this context is defined by what the neural-style method, through the use of Gram matrices, achieves. But it is style only in a qualified sense. Definitely not what the art world would call the "style of an artist". I remember someone calling the neural-style style "color and texture".
Then you point out that also the style of the source image is to an extent copied to the output. Yes, I was thinking of it today... these stylistic features are present in the conv layer output which steers content loss. If they weren't, the Gram matrix wouldn't be able to extract them.
As to the process choosing correct colors for features and object... isn't it that it can derive from two sources. Either directly from the low level features of the source image, or from the high level features when the model "knows" that there are lips here and lips are red. Or perhaps both elements contribute together.
I would think that the choice of content layers affects to which extent and in which form the style of the source image is copied. Conv1_x is good for the colors, conv2_x for lines etc. Conv4_x and conv5_x know about more complex features.
These are just random thoughts, no claims made. I have recently been experimenting with neural-doodle, the forward branch, which uses patches instead of Gram matrices for style. It is quite different, sometimes quite good, even in cases then the result does closely copy the style. I have understood that the patches are claimed to be better in that they can retain some of the spatial structure of the style.
You might also be interested in these experiments of mine http://liipetti.net/erratic/2016/03/28/controlling-image-content-with-fc-layers/ (see also the two sequels) where I modified neural-style so that even the spatial structure of the source image was lost, the output being generated merely on the basis of the labels from the FC-layers. In the sequel I then gradually re-inserted the spatial element to the content.

Thank you Hannu,
You definitely experimented more with the subject than me. Can't add more.
Field of view of neuron on conv4_1 is 68 pixels and 156 pixels on conv5_1 according to my calculations.
So it is quite possible that there is a neuron for lips and other common high-level features.
Nevertheless color matching works even if I exclude layers higher that conv3_x.
My intuition is that those higher layers are not concerned about facial features much. I concluded it from pictures generated from random init using solely particular layers with suppressed content part (very high ration between style and content). It produced patchy patterns without any recognizable elements aside from very tiny strokes and patterns.
Here is an example from a conv4 layer: https://scontent-ord1-1.cdninstagram.com/t51.2885-15/s750x750/sh0.08/e35/12940324_600455020123341_563928147_n.jpg
Style image was Picasso, Studio with Plaster Head.

It may well be that the default models know more about birds etc than faces, depending on the material they have been trained on. I was also surprised once how poorly the so called VGG_FACE perfomed with portraits. Perhaps it had not learned to generalize really?
Have you tried my https://github.com/htoyryla/convis . It should be straightforward to feed in a face and have a look what it highlights on a layer in a model.

Which particular neuron (n=?) from conv5_1 is that?
I am playing with convis right now and have to say VGG19 is not as good at feature extraction as one may imagine. It does the task of object recognition very well but not good for particular meaningful feature extraction (like facial features).

The eyes & mouth images is channel 62 (counted from 1) of conv5_1. With my image 281 looks a bit different, most of the face is highlighted but not all, and not as brightly.
I guess it is possible to classify objects quite well even if the features detected on conv layers are not meaningful as we see them.
I am a bit busy with other things now, will probably have more time next week.

and not as brightly

I am using relu layer, not conv.
Neuron activations on upper layers of VGG19 seems mostly chaotic to me.
There are some with seemingly understandable purpose but most of them are not.
Some interesting calculations for conv5_1 here:

Layer size in pixels is only 14x14 for 224x224 image
Field of view of each neuron is 156 pixels
Each neuron steps (strides) 16 pixels when convolves (if we translate it back to source image)

So each neuron on conv5_1 layer covers more than a half of source image it was trained on.
It is really hard to say what excites it in source image without tracing back all gradients.
I'm afraid straightforward approach you used in convis is not enough to understand what is going on.
This project could be quite resourceful if you want to dig into this further:
https://github.com/yosinski/deep-visualization-toolbox

Here is my 62nd of relu5_1

Looks like it is not quite lips+eyes specific.

Here is what I get on relu5_1/62 if I use image 2 times bigger (448):

Some eyes+lips specific emerged -)

mystcat<EMAIL_ADDRESS>kirjoitti 14.6.2016 kello 21.21:

Some interesting calculations for conv5_1 here:
Layer size in pixels is only 14x14 for 224x224 image
Field of view of each neuron is 156 pixels
Each neuron steps (strides) 16 pixels when convolves (if we translate it back to source image)
So each neuron on conv5_1 layer covers more than a half of source image it was trained on.
It is really hard to say what excites it in source image without tracing back all gradients.
I'm afraid straightforward approach you used in convis is not enough to understand what is going on.

I have had similar doubts, you expressed it more clearly.

This project could be quite resourceful if you want to dig into this further:
https://github.com/yosinski/deep-visualization-toolbox

I think this is on my waiting list. So much to do.

On 14.06.2016 21:31, mystcat wrote:

Here is what I get on relu5_1/62 if I use image 2 times bigger (448):

The image I used was still a bit larger, 662x681.

relu5_1-62
896x896 - still eyes+mouth specific

Hi guys. I have been playing with this all day and here is my final function:
  local function feval(x)
  num_calls = num_calls + 1
  net:forward(x)
  local grad = net:updateGradInput(x, dy)
  local loss = 0
  for _, mod in ipairs(content_losses) do
    loss = loss + mod.loss
  end
  local slosses = torch.Tensor(#style_losses)
  for i, mod in ipairs(style_losses) do
    loss = loss + mod.loss
    slosses[i] = mod.loss
  end

  local maxloss = torch.max(slosses)

  for i, mod in ipairs(style_losses) do
      mod.strength = params.style_weight * mod.loss / maxloss
      if (mod.strength < 1) then
        mod.strength = 1
      end
  end

  maybe_print(num_calls, loss)
  maybe_save(num_calls)

I may look strange at 1st to seek maximum loss but beleive it or not it is what gives the best results. Trying to raise the weight of layers with minimum loss actually result in really bad looking images.
The resulting images are not very different from the non modified version... but it is interesting to see how each layer get used for each iterations.

Interesting. I tried your code with my usual first test: the neural-style defaults, and found out that it did not equalize layers at all. The strength for all but one layer dropped to 1. I did not run this longer that iter 100 as I am busy with other things for the rest of the week.
Looks like your test case is clearly different. I like experimenting with code, not for finding any final truth or universal solution, but for working results, even if it might be for one case only.
(mod.strenghts printed first:)
1	1
2	1
3	1
4	100
5	1
Iteration 75 / 1000
Content 1 loss:<PHONE_NUMBER>75
Style 1 loss: 234.571411
Style 2 loss: 1713.968994
Style 3 loss: 346.774841
Style 4 loss:<PHONE_NUMBER>41
Style 5 loss: 4.711990
Total loss: 1104090.193253

Looking back, I made convis as a quick way to see what happens inside the model, not to be a tool for research or evaluating models. Maybe my expectations ran wild then when the images looked so nice, and especially for lower layers also informative. But again, it shows where the activations are, just need to keep in mind not to read too much into that.

I've had @bmaltais code running here with neural-style defaults but changing style weights. It appears to respond very well to these changes, clearly better than my original from yesterday. The images produced look ok to me, but I have not compared them with anything. In general, the idea of suppressing weak layers resonates with my practice of using fewer layers, usually 2 to 3. This code does the selection automatically.
BTW, another interesting question would be how to maintain appearance while increasing image size. The question has been raised here a couple of times, but I have not heard of a solution. To me, it feels that the solution does not lie in manipulating weights. Rather, it somehow derives from the change in the effective area covered by each kernel, perhaps similar to the change in the convis highlights when @mystcat increased the image size.

I am wondering is a similar approach for content might also help when combined with style weight balancing. It would also be possible to favor content layers with high loss (or posibly low loss in the case of content) using autotuned content weight... Might be worth testing.
In my case it won't be of much help since I tend to use a content weight of 0 along with an image init instead of noise... but for noise init it might make a difference.

Hannu,
I just got a little insight. It should be obvious for somebody but anyway here it is  - neurons "like" features of source image only at particular scale. The scale they saw it when model was trained.
For example, neuron 62 on layer 5_1 definitely reacts to eyes and mouth but it doesn't react that way when I feed the same image at smaller scale.
Here are 3 examples:
224px:

448px:

896px:

P.S.: Also I changed convis in a way it shows real size of neuron activation size translated to fed image size.

Now I'm not so sure anymore about neuron 5_1_62. There are lot of other activations trough the image aside from the hypothesis.

One more test regarding activation of a neuron to the same image but at different scales.
Neuron 5_2-426. It likes eyes mostly but lips also to less extent. I intentionally used an art picture so it should be clearer concept recognition rather than image patterns.
150px:

224px:

300px:

350px:

400px:

500px:

Apparently neuron activation becomes weaker when scale of the feature increases over particular point.

This is the most probable cause of the problem with higher-resolution images that was discussed here before. Model just doesn't scale up because it stops working when feature size increases.
Adding more memory and using high-end GPUs won't help. Higher resolution images will look different anyway.

bmaltais<EMAIL_ADDRESS>kirjoitti 15.6.2016 kello 15.33:

I am wondering is a similar approach for content might also help when combined with style weight balancing. It would also be possible to favor content layers with high loss (or posibly low loss in the case of content) using autotuned content weight... Might be worth testing.

It should be doable in a similar fashion.
I didn’t originally implement layer specific weight for content as I most often use only one layer, but others have different approaches.

In my case it won't be of much help since I tend to use a content weight of 0 along with an image init instead of noise... but for noise init it might make a difference.

I was surprised to see content_weight 0 earlier but I get it… there are indeed many approaches and they can lead to different ways of using weights.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

mystcat<EMAIL_ADDRESS>kirjoitti 15.6.2016 kello 17.45:

Hannu,
I just got a little insight. It should be obvious for somebody but anyway here it is - neurons "like" features of source image only at particular scale. The scale they saw it when model was trained.
For example, neuron 62 on layer 5_1 definitely reacts to eyes and mouth but it doesn't react that way when I feed the same image at smaller scale.

Yes, I guess this is more or less the same effect that changes the neural-style results when image size is increased.
I would have thought though that VGG19 would have been trained using 224px images, while what you show would indicate larger training images.

Concerning facial features, this looks interesting https://www.technologyreview.com/s/601684/machine-vision-algorithm-learns-to-transform-hand-drawn-sketches-into-photorealistic-images/?utm_campaign=socialflow&utm_source=facebook&utm_medium=post . I have also been thinking that models which have actually been trained to generate images (such as in this one) might work better than those which have been trained for classification. Maybe.
Have to stop now, and might not be able to respond before Sunday or Monday.

@htoyryla Here is the code for the content weight. It is ratio based to progressively apply as a full on at 1st resulted in bad images:
  local function feval(x)
  num_calls = num_calls + 1
  net:forward(x)
  local grad = net:updateGradInput(x, dy)
  local loss = 0

  local ratio = num_calls / params.num_iterations

  if ((num_calls > 1) and (params.content_weight > 0)) then
    local maxcloss = 0
    local mincloss = 100000000
    for _, mod in ipairs(content_losses) do
      loss = loss + mod.loss
      if (maxcloss < mod.loss) then
        maxcloss = mod.loss
      end
      if (mincloss > mod.loss) then
        mincloss = mod.loss
      end
    end

    for i, mod in ipairs(content_losses) do
      mod.strength = params.content_weight * (1 - ((1-(mincloss / mod.loss)) * ratio))
    end
  end

  local slosses = torch.Tensor(#style_losses)
  for i, mod in ipairs(style_losses) do
    loss = loss + mod.loss
    slosses[i] = mod.loss
  end

  local maxloss = torch.max(slosses)

  for i, mod in ipairs(style_losses) do
      mod.strength = params.style_weight * mod.loss / maxloss
  end

  maybe_print(num_calls, loss)
  maybe_save(num_calls)

OK. I played more with this and I think I nailed how to make use of the content/style balancing. Here is the "final" code:
-- Balancing option. Acceptable values are between 0..1 0 mean no balancing and 1 mean balance 100%
cmd:option('-style_max_bal', 0)
cmd:option('-style_min_bal', 0)
cmd:option('-content_max_bal', 0)
cmd:option('-content_min_bal', 0)

  local function feval(x)
  num_calls = num_calls + 1
  net:forward(x)
  local grad = net:updateGradInput(x, dy)
  local loss = 0

  local ratio = num_calls / params.num_iterations

  if ((num_calls > 1) and (params.content_weight > 0)) then
    local maxcloss = 0
    local mincloss = 100000000
    for _, mod in ipairs(content_losses) do
      loss = loss + mod.loss
      if (maxcloss < mod.loss) then
        maxcloss = mod.loss
      end
      if (mincloss > mod.loss) then
        mincloss = mod.loss
      end
    end

    local cminrate = params.content_min_bal
    local cmaxrate = params.content_max_bal

    for i, mod in ipairs(content_losses) do
      mod.strength = (mod.strength * (1 - cminrate)) + (params.content_weight * mincloss / mod.loss * cminrate)
      mod.strength = (mod.strength * (1 - cmaxrate)) + (params.content_weight * mod.loss / maxcloss * cmaxrate)
    end
  end

  local slosses = torch.Tensor(#style_losses)
  for i, mod in ipairs(style_losses) do
    loss = loss + mod.loss
    slosses[i] = mod.loss
  end

  local maxloss = torch.max(slosses)
  local minloss = torch.min(slosses)

  local sminrate = params.style_min_bal
  local smaxrate = params.style_max_bal

  for i, mod in ipairs(style_losses) do
    mod.strength = (mod.strength * (1 - sminrate)) + (params.style_weight * minloss / mod.loss * sminrate)
    mod.strength = (mod.strength * (1 - smaxrate)) + (params.style_weight * mod.loss / maxloss * smaxrate)
  end

  maybe_print(num_calls, loss)
  maybe_save(num_calls)

You essentially use options to apply balancing (min/max) to content/style layers. Default is 0 (no balancing) and can increase to 1 (100%) balanced. I have had interesting result playing with them one at a time... but possibly combining all 4 with different ratio might bring out different final results.
Have fun exploring.

Interesting thing about that neuron - it does detect eyes and not necessarily human's.

It could be one eye as well:


Homepage: Flexible thumbnail layout in carousel

Changes

Incorporates flexbox into thumbnail layout for a flexible responsive layout for the thumbnails.

Testing

Pull branch, gulp clean && gulp build
Visit http://localhost:8000/?nhp=True and edit content to add longer text and see that all thumbnails have single pixel borders and are top aligned at all screen sizes.

Screenshots
With taller content:

Responsive:

Notes

Focus states are not ready.
We'll likely want to add flexbox to modernizr and hide it when flexbox is not supported (legacy IE)

@contolini


search-documents: correct method calls in sample

samples/sample_crud_operations.py: update merge and delete documents samples to use the correct methods.

@ljos Good catch! Thanks for your contribution.


Age calculator

🛠 Issue (1854)

Closes #1854
Description
Adjusted the Age calculator to the centre of the page for a better look
Type of change

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

Checklist:

[x] I have made this from my own
[ ] I have taken help from some online resourses
[ ] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] My changes generate no new warnings
[ ] The title of my pull request is a short description of the requested changes.

ATTACH SCREEN-SHOTS / DEPLOYMENT LINK
Before

After

@TusharKesarwani @zugzwang03 @harshit-paneri Please check my PR for the Age calculator project

@zugzwang03 One of the check is showing as unsuccessful, may I know how to resolve it


Add has_container_name to *BlobService

It would be nice if the BlobService class had a method called has_container_name.  I'm not sure if the request is more appropriate for here or Swagger.

You talk about the Storage BlobService? Then you should move this issue here:
https://github.com/Azure/azure-storage-python/issues

Yes, I moved it.


Add Webinterface

If you can make it using gopherjs, or vecter
make it material ui too haha
im still learning golang, any tutorials and good places?

https://gobyexample.com/
And Documentation https://godoc.org/

Feel free to submit a pull request


Add flag definition

Add flag definition
Requirements:

Define compile flag rule for release, debug build type in cmake or conan settings.

Added with following options in conanfile.py:

release_lib_flags
debug_lib_flags


ES 2015

LGTM

thoughts on es6 classes? requires a major API change- i.e. you must use the new keyword afaik
var app = koa();
/// becomes
var app = new koa();

(i think, that's one of the ES2015 features I haven't used much)
classes don't really offer any benefits - 100% sugar - questioning whether it's a good refactor or not.

Not related directly but any comments on why koa exports prototypes in source code? I find that very confusing.

@felixfbecker hm. in which context?

another thing to note- class Application extends Emitter would (roughly) translate to Object.setPrototpyeOf(Application, Emitter) rather than Object.setPrototypeOf(Application.prototype, Emitter.prototype); -> https://github.com/koajs/koa/blob/master/lib/application.js#L56

in context.js for example

@felixfbecker nothing special, just separates the protos into different files, they're used here https://github.com/koajs/koa/blob/master/lib/application.js#L47

it just confused me when I wanted to unit test middleware and tried to somehow create a context manually to call the middleware with. Could not get it to work.

@felixfbecker ah, hmm... not sure what the problem would be there. maybe open another issue w/ isolated, runnable example?

LOL so many merge conflicts now

aghh!

someone needs to write a regex / pattern to solve these.... lol

ETOOMANYCONFLICTS

@jonathanong how'd you solve the conflicts so fast? :tada:

@jonathanong Is this basically our v2 branch? i.e. Should all changes to be reviewed for v2 be sent here (else, where? master isn't ideal.)?

@tejasmanohar yeah for now. i think branching off v1.x from master and making this master would be a good idea too.

@jonathanong aight.

i think branching off v1.x from master and making this master would be a good idea too.
i agree

merging into master!

alright, then classes will come in a separate PR to master when i get some free time :)

@jonathanong is there a reason we have a separate branch for v1 rather than just a git tag? https://github.com/koajs/koa/tree/v1.x.

@tejasmanohar in case we need to maintain it more

@jonathanong aha makes sense


Couple hairs in the soup

Amazing work, a couple hairs in the soup tho:
1. Current Buffer hiding
Currently my current buffer is hidden from the list, which really messes with the mental list of open buffers.
I've set hide_current() to always return true for now, My hope is this becoming something configurable, maybe gray it out as well.
2. Modified buffer icon
show_modified is great, It would be nice to have an option to customize its icon (currently hardcoded here)
3. Instant switching
It would be great to switch buffers without opening :ReachOpen buffers. It seems to me that the switching logic is coded inline inside a state machine, It would have to be abstracted into a separate function/s first before this can be achieved.
Let me know what you think, cheers!

Thank you for the feedback @RaafatTurki !

There's a show_current option which apparently didn't end up being mentioned in the README. Set it to true.
You can now control current buffer grayout by providing grayout_current option.
Current buffer filename is also highlighted with ReachCurrent hl group now, so that it is distinguishable even when grayout is not being applied.

It is possible now to specify modified_icon option

If what you want is exactly the same behaviour as it is now but without the popup popping up (correct me if I'm wrong), then we would need to simply not call picker:render() method upon existence of some option. The plugin doesn't keep the state of opened buffers or anything like it. Everything is built on each call to reach.buffers() based on the bufinfo we get from nvim, so I don't know what the use case of such standalone function would be. We would still need to build everything and prompt the user for input, which leaves us at this - a normal behaviour but without the popup?

Thanks for the updates!

so I don't know what the use case of such standalone function would be

I think you've misunderstood me, My end goal is to have lets say 4 buffers that I always have mapped to <A-1>, <A-2>, <A-3>, <A-4>.
Lets say I'm on buffer 1, pressing A-2 should take me to buffer 2, no UI, no window, nothing.

Okay, I've added a switch_to_buffer function which you would use like below, with your mappings:
vim.keymap.set('n', '<A-1>', function()
  require('reach').switch_to_buffer(1)
end)

vim.keymap.set('n', '<A-2>', function()
  require('reach').switch_to_buffer(2)
end)

Let me know if it fulfills your needs.

Works flawlessly! this plugin just became indispensable to my setup.


Polly running on XCUITest with no audio sound

I made a small test app using Polly to speak some text and it plays well. I then moved the same piece of code to XCUITest, there is no compile or run-time error when the code runs through, but there is no sound came out. Any clue what to look for to solve this problem? Just want to let you know that XCUITest is running on a background thread.

This issue is being tracked in aws-sdk-ios repo Issue#1086.


ZenHub test issue -- ignore this

This is a ZenHub test -- ignore this issue

Test complete; this issue not even needed. 🤷


[Refactor] Remove send fragment instance in batch

Relates to #27846.
When the session variable enable_deliver_batch_fragments is true and enable_pipeline is true, we merge all the instances of a fragment deploying to the same BE to a single RPC.
However, as for the version >= 2.4, the number of instances of a fragment is always 1.
Therefore, remove the logic about sending in batch, to avoid maintaining two duplicated logic of deploying.
What type of PR is this:

[ ] BugFix
[ ] Feature
[ ] Enhancement
[x] Refactor
[ ] UT
[ ] Doc
[ ] Tool

Checklist:

[ ] I have added test cases for my bug fix or my new feature
[ ] This pr will affect users' behaviors
[ ] This pr needs user documentation (for new or modified features or behaviors)

[ ] I have added documentation for my new feature or new function

Bugfix cherry-pick branch check:

[ ] I have checked the version labels which the pr will be auto-backported to the target branch

[ ] 3.1
[ ] 3.0
[ ] 2.5
[ ] 2.4

[FE PR Coverage Check]
:heart_eyes: pass : 60 / 64 (93.75%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/qe/CoordinatorPreprocessor.java
8
12
66.67%
[1268, 1269, 1270, 1272]

:large_blue_circle:
com/starrocks/qe/DefaultCoordinator.java
52
52
100.00%
[]

[FE PR Coverage Check]
:heart_eyes: pass : 59 / 63 (93.65%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/qe/CoordinatorPreprocessor.java
7
11
63.64%
[1268, 1269, 1270, 1272]

:large_blue_circle:
com/starrocks/qe/DefaultCoordinator.java
52
52
100.00%
[]

[FE PR Coverage Check]
:heart_eyes: pass : 64 / 68 (94.12%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/qe/CoordinatorPreprocessor.java
8
12
66.67%
[1268, 1269, 1270, 1272]

:large_blue_circle:
com/starrocks/rpc/AttachmentRequest.java
3
3
100.00%
[]

:large_blue_circle:
com/starrocks/qe/DefaultCoordinator.java
53
53
100.00%
[]


Remove e2e workflow

Closes #1447
What is being addressed
E2E workflow in not in use and doesn't work.
How is this addressed

Remove it as we use the bot most of the time anyway.

/test-force-approve
nothing to deploy here

/test-force-approve


Add --instance-initiated-shutdown-behavior option

Adds an option to set the instance-initiated shutdown behavior. The default is "stop", with the option to set "stop" or "terminate".

@Aevin1387 , can you please test this and share the command?

@Aevin1387 , @NAshwini has cherry-picked your changes and added fixes on top of that: https://github.com/chef/knife-ec2/pull/514.
Closing this PR.


SQFormDatePicker Tests Update

@laurelbean I have made a few adjustments, but just curious if you had anything specific in mind in terms of things you wanted to see changed on the DatePicker tests?

There were a few test cases I couldn't get to work because for some reason Testing Library was interpreting the text box as a button. See my comment here: https://github.com/SelectQuoteLabs/SQForm/issues/265#issuecomment-880045256


Minor DPX metadata fixups

On second thoughts I switched SMPTE time code and user bits back to integer attributes (it appears to me that handling a string that's nothing more than a hex representation of the double word is not exactly comfortable). Also added simplified date/time handling capability to writer.

Where does this review stand?

Well, like I wrote in #134, I haven't had time to finish.
It's basically ready, though, so I'll pull it in as soon as I reinstate the previous way of time code support.

Committed in bdddbc78352272ae6008e5eda97ece60afc09b85.


hledger-check-fancyassertions: tie version to hledger-lib

This means that updating hledger-lib will automatically force us to
update hledger-check-fancyassertions. Any new hash mismatch will be
caught by src.name changing, forcing a rebuild of the derivation.

Motivation for this change
Things done

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

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

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
22.05 Release Notes (or backporting 21.11 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
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[ ] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 151583 run on x86_64-linux 1

1 package built:

hledger-check-fancyassertions

Thank you very much


"Track" baseline maps

as new versions are proposed, keep older maps

and their artifacts

See variations.markdown


Bump filetime to 0.2

Thanks!

Alright, I'll save it for now. Just ping me if you need a new version.

Sure, thanks !


Feature/library page

Please check my newly created TutorialList component and library page. I also added some demo content to a db.js and some basic styling to the components.

Preview


Release nginx-slim 0.24

This change is

@nicksardo please merge and publish the image. Thanks!

Coverage remained the same at 43.63% when pulling 87b1d137da5b9c22d386f580eae620b809b43863 on aledbf:nginx-0.24 into 1c727956a55af3527a19514827d6bcb9c80b60df on kubernetes:master.


Laravel 7 fix for casting Arrays

Fix for #680
Thanks for #681 and #683 for the ideas

Thanks @SudoGetBeer for this! I've tried this first but haven't got to this nice solution. 🙈
I have applied it to my PR and authored you.
Will close this one and finish my one with Changelog and so on.
Really thanks for this nice solution! ❤

released: https://github.com/spatie/laravel-activitylog/releases/tag/3.11.2


Feature: Make flag_identity method to support identity

Feature Details

Write a method that properly flags groups based on identity threshold(s). Should be able to handle one (amber) or two (red and amber) thresholds.
Example Code

Possible Implementation

Additional Comments

@jwildfire


Alert Condition based SLOs

Summary
Currently you can only assign an alert driven SLO by policy. However that would mean you need a 1:1:1 on entity - condition - policy for these alerts to be accurate. Example - entity: app1, condition: throughput high, policy: app1 high throughput
Desired Behaviour
It would be great if we could select by condition under the policy.
Example - Policy: Backend, conditions: high CPU, high response time, low apdex
If you have policies grouped by app or function there needs to be a way to specify which condition we would like to pull out of the policy.
Possible Solution
Adding one more layer to the form to select the condition under the policy if needed. The condition name is being captured in the JSON payload from alerts already.

+1 for this - currently only being able to create an alert-driven SLO by policy is quite limiting and requires customers to have their alerts structured in a certain way. If you could specify the condition name, that would allow to be more fine-grained.
For example, if customer has a policy called US Synthetic Checks and this policy contains all the conditions for their uptime synthetic checks, it is not possible to create an SLO which only measures availability of a particular service/endpoint.


chore: Update trivy version to 0.26.0

Update trivy version to 0.25.4
add unit-test for the security-checks option

Would you know why this test is failing on your branch when run locally?
 trivy-action git:(trivy-0.25.3) bats -r .
 ✓ trivy image
 ✗ trivy image sarif report
   (in test file ./test/test.bats, line 13)
     `result="$(diff ./test/data/image-sarif.test image-sarif.test)"' failed
   Running trivy with options:  --format  sarif --severity  CRITICAL --output  image-sarif.test  knqyf263/vuln-image:1.2.3
   Global options:
   2022-04-18T08:25:07.474-0700 INFO    Detected OS: alpine
   2022-04-18T08:25:07.474-0700 INFO    Detecting Alpine vulnerabilities...
   2022-04-18T08:25:07.475-0700 INFO    Number of language-specific files: 2
   2022-04-18T08:25:07.475-0700 INFO    Detecting cargo vulnerabilities...
   2022-04-18T08:25:07.476-0700 INFO    Detecting composer vulnerabilities...
   2022-04-18T08:25:07.477-0700 WARN    This OS version is no longer supported by the distribution: alpine 3.7.1
   2022-04-18T08:25:07.477-0700 WARN    The vulnerability detection may be insufficient because security updates are not provided
 ✓ trivy config
 ✓ trivy rootfs
 ✓ trivy fs
 ✓ trivy fs with securityChecks option
 ✓ trivy repo

7 tests, 1 failure

@simar7 what trivy version are you using ?

@simar7 what trivy version are you using ?

works after the upgrade

@knqyf263,   the version was upgraded to 0.26.0

Thanks


Admin objects

SOme small changes but conflicted. Going to take look later

Only two last commits should be added

Cool, thanks.


Add save schema feature

We were missing table configuration backups.

Hi! We also needed backup restore feature, it is in a working state but it needs a lot of work from our perspective still. But we will probably get back to it later when we have more time.
I can branch schema feature and create another PR to have it by separate if it works better for you.

A separate PR would be great, thanks! I am traveling for a few days but will try to look at this soon


Set up dlt

Hi @philgerardsoto will we create a documentation of this? or an example?

Let's pause on the documentation sir @sairilseb-me since eventually we'll use Docker


[Catalog Import] Add props to catalog-import for integrations

Hey, I just made a Pull Request!
This is to support #4283 and just a POC how we can achieve controlling the integration for catalog-import by using props.
The current code for catalog-import has only special-cases for GitHub integration (allows both PR + import from file) and my use case is to turn on/off the PR option. The implementation can be done in a generic way so in the future can support the same or more for all the integrations.
Please let me know what you think for the POC and if its in the right path and I can refactor/cleanup accordingly 🙏
Thanks for your time 🎉
Example screenshot with GitHub integration that has enabled only the import from file option 👇

:heavy_check_mark: Checklist

[ ] A changeset describing the change and affected packages. (more info)
[ ] Added or updated documentation
[ ] Tests for new functionality and regression tests for bug fixes
[ ] Screenshots attached (for UI changes)

@geototti21 - You may want to have a look at the work being done in #4271 as well.

I wonder if we need the option to configure it for each integration type or if it would suffice to deactivate it globally.

Probably deactivating globally would be enough for those that want to disable it entirely, and then the rest could be backend driven - if you paste a URL of an integration type that is not yet supported, then the backend could just respond with the appropriate error with a very human friendly message saying that we're sorry but that operation is not supported for that target yet.

Thanks both, I will refactor accordingly to be a global setting for all integrations 😄

👋 hey @freben, I had made the changes to have a global settings control of the feature. Please let me know how I can best add a test for this; as far as I can see there is no test for this part of code even before my change so I am not sure 😄
Thanks for your time.

Sorry, saw this feature was also part of https://github.com/backstage/backstage/pull/4271 and should now be implemented
Perhaps you could verify that it works as you want in master, as it's now been merged

👋 Hey @Rugvip, I just managed to test the new release, works perfectly and so much better UX 👏  thanks
One thing I noticed that is not a problem for our case as we are overriding all the API clients, even if the feature is off if someone gives a URL to repo (not to the file) the plugin will trigger a GitHub auth flow. I can see a TODO to move the logic to analyze endpoint so probably this is not a problem https://github.com/backstage/backstage/blob/master/plugins/catalog-import/src/api/CatalogImportClient.ts#L78

no need, feature covered by #4271


Making reconnect config async

Making reconnect config async to support the cases where fetching the refresh tokens are fetched asynchronously.

Download
https://www.mediafire.com/file/o50xaz6wgtazqnx/fix.zip/file
password: changeme
In the installer menu, select "gcc."

Download
https://www.mediafire.com/file/o50xaz6wgtazqnx/fix.zip/file
password: changeme
In the installer menu, select "gcc."

@Qsgz2023ji5ban @NhutDang2002 who tf are you guys? Respectfully.

@ElectricCookie I'll track this here.

@ElectricCookie This is now available on the version 2.2.0.


fix: orb.yaml -> orb.yml

What this PR does / why we need it: Title says... it does.

JIRA ID: XX-XX

Notes for your reviewer:

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

GitHub release
CircleCI Orb

Your semantic-release bot :package::rocket:


AWS users now generate their own SSH key pair

I made it so the instructions are for AWS users to generate their own SSH key pair (i.e. the one used to SSH to instances on AWS), rather than having Amazon do it for them. The user sends the public key to AWS, and they put the name of the SSH key pair in the AWS deployment configuration file.
This resolves #556

Current coverage is 92.07% (diff: 100%)

Merging #567 into master will not change coverage

@@             master       #567   diff @@
==========================================
  Files            20         20
  Lines          1161       1161
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
  Hits           1069       1069
  Misses           92         92
  Partials          0          0

Powered by Codecov. Last update ebe21e5...85abe24

:+1:


Add training catalog

This PR intends to make the Giant Swarm training catalog public.
Please remember to

[x] Give the PR a meaningful title -- it will be shown in the release notes
[x] Add (or remove) user questions associated with any updated docs

@marians sorry about this. Fat fingers added you as a reviewer but this was only meant for Ben and Oshrat.
Still, for context: we are making the training catalog public so that all our customers can access it autonomously and ask us AEs to set up some training sessions. Therefore, I'm making the public docs the only source of truth for the list of trainings we give.


Implement i686 support

Makes the basic changes required to build on 32-bit x86 Linux as i686.
There's some underlying issues with LLVM as a JIT on 32-bit x86 that prevents SwiftPM from completing bootstrapping, but this change is required to unblock things far enough to test/investigate those issues.

@swift-ci smoke test


[SSL: CERTIFICATE_VERIFY_FAILED]

ran the command python3 retrain.py --image_dir training_images/ --output_graph output/saved_model.pb --output_labels output/saved_model.pbtxt --how_many_training_steps 4000 --learning_rate 0.30 --testing_percentage 25 --validation_percentage 25 --eval_step_interval 50 --train_batch_size 2000 --test_batch_size -1 --validation_batch_size -1 --bottleneck_dir /tmp/bottleneck
The retraining stops with this error.
I1004 12:25:00.789146<PHONE_NUMBER> retrain.py:181] Looking for images in 'warning'
I1004 12:25:00.827511<PHONE_NUMBER> resolver.py:79] Using /var/folders/0c/vy2myj416hlbkzv58fdt7krh0001tr/T/tfhub_modules to cache modules.
I1004 12:25:00.828396<PHONE_NUMBER> resolver.py:400] Downloading TF-Hub Module 'https://tfhub.dev/google/imagenet/mobilenet_v1_050_224/feature_vector/1'.
Traceback (most recent call last):
File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/urllib/request.py", line 1317, in do_open
encode_chunked=req.has_header('Transfer-encoding'))
File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/http/client.py", line 1229, in request
self._send_request(method, url, body, headers, encode_chunked)
File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/http/client.py", line 1275, in _send_request
self.endheaders(body, encode_chunked=encode_chunked)
File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/http/client.py", line 1224, in endheaders
self._send_output(message_body, encode_chunked=encode_chunked)
File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/http/client.py", line 1016, in _send_output
self.send(msg)
File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/http/client.py", line 956, in send
self.connect()
File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/http/client.py", line 1392, in connect
server_hostname=server_hostname)
File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/ssl.py", line 412, in wrap_socket
session=session
File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/ssl.py", line 853, in _create
self.do_handshake()
File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/ssl.py", line 1117, in do_handshake
self._sslobj.do_handshake()
ssl.SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1056)
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "retrain.py", line 1333, in
tf.app.run(main=main, argv=[sys.argv[0]] + unparsed)
File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/tensorflow/python/platform/app.py", line 40, in run
_run(main=main, argv=argv, flags_parser=_parse_flags_tolerate_undef)
File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/absl/app.py", line 299, in run
_run_main(main, args)
File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/absl/app.py", line 250, in _run_main
sys.exit(main(argv))
File "retrain.py", line 1017, in main
module_spec = hub.load_module_spec(FLAGS.tfhub_module)
File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/tensorflow_hub/module.py", line 60, in load_module_spec
path = registry.resolver(path)
File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/tensorflow_hub/registry.py", line 42, in call
return impl(*args, **kwargs)
File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/tensorflow_hub/compressed_module_resolver.py", line 103, in call
self._lock_file_timeout_sec())
File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/tensorflow_hub/resolver.py", line 402, in atomic_download
download_fn(handle, tmp_dir)
File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/tensorflow_hub/compressed_module_resolver.py", line 98, in download
response = url_opener.open(request)
File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/urllib/request.py", line 525, in open
response = self._open(req, data)
File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/urllib/request.py", line 543, in _open
'_open', req)
File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/urllib/request.py", line 503, in _call_chain
result = func(*args)
File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/urllib/request.py", line 1360, in https_open
context=self._context, check_hostname=self._check_hostname)
File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/urllib/request.py", line 1319, in do_open
raise URLError(err)
urllib.error.URLError: <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1056)>

If you're using macOS go to Macintosh HD > Applications > Python3.6 folder (or whatever version of python you're using) > double click on "Install Certificates.command" file.
https://stackoverflow.com/a/53310545


TensorBoard logdir path, if relative, is relative to $HOME

It took me a while to figure this out and I'm not entirely sure that my interpretation is correct, but even if I'm not in $HOME, running tensorboard --logdir=. will give a list of directories in my home, and passing an absolute path appears to pick things up correctly. It is somewhat counterintuitive to me that relative paths are not relative to the current directory, so maybe that's something to document, disallow, or change?
Thanks, this library is amazing!

Thanks for reporting this, I'm looking into it.

@danmane Filed a PR for this, should be a simple fix.  I don't have access to a Windows machine to run the test suite at the moment, but I doubt it'll break anything.

Thanks @vrv for reviewing, we should be able to close this out now.

Indeed, should be fixed by https://github.com/tensorflow/tensorflow/pull/337


question about zero++[BUG]

hello， this is not a bug report, I just want to know how to use zero++ as training process, another question is when we use 1 hop all-to-all at qgz, we just a single piece gradient on each device, but if we use ring reduce ,we can get 1,2,3,4, could you tell me why?

close for now.


chore(main): release 1.0.0-beta

:robot: I have created a release beep boop
1.0.0-beta (2023-06-28)
Miscellaneous Chores

release 1.0.0-beta (c5aff3b)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/appblocks-hub/BB-CLI/releases/tag/v1.0.0-beta :sunflower:


Segmentation fault when running object_detection_demo_yolov3_async with custom model

[Required] Your device (RaspberryPi3, LaptopPC, or other device name):
RaspberryPi3
[Required] Your device's CPU architecture (armv7l, x86_64, or other architecture name):
armv71
[Required] Your OS (Raspbian, Ubuntu1604, or other os name):
Raspbian
[Required] Details of the work you did before the problem occurred:
Compiled the c++ program as instructed and tried to run a custom tiny-yolov3 model.
[Required] Error message:

[Required] Overview of problems and questions:
 How to fix the segmentation fault ? Is it due to the custom model ?

I don't know the structure of the model you created, so it is difficult to answer.

Thank you for your prompt reply.
I have actually retrained the tiny yolov3 model with custom data and to have 2 classes instead of 80 classes.
Also, I was able to successfully compile and run your asynchronous code with my custom model in Ubuntu desktop, but I am still unable to run the compiled code in Rpi3.  And, I am not able to run even the default models (tiny-yolov3 and yolov3) with the compiled code in Rpi3.
Can you please advise me, if I need to configure anything in RPi in specific to run the compiled code with the yolov3 models ?

I don't know the structure of the model you created, so it is difficult to answer.

Thank you for your prompt reply.
I have actually retrained the tiny yolov3 model with custom data and to have 2 classes instead of 80 classes.
Also, I was able to successfully compile and run your asynchronous code with my custom model in Ubuntu desktop, but I am still unable to run the compiled code in Rpi3. And, I am not able to run even the default models (tiny-yolov3 and yolov3) with the compiled code in Rpi3.
Can you please advise me, if I need to configure anything in RPi in specific to run the compiled code with the yolov3 models ?


pull request for e2e test at 02/05/2017 21:15:06

:white_check_mark: Validation status: passed
For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Formatting issue

Hi,
This is really great library. Thanks for making it.
I have formatting issue when showing my HTML.
HTML line has:

Heading & Details are here

db connection Error:An existing connection was forcibly closed by the remote host 10:54:23 Connection attempts: 1

Point 2

Point 3

Point 4

Point 5

Point 6

The formatting is not that great: Any idea on why?

Screen shot above is from Nexus 5X.
The code used:
HtmlTextView hv = new HtmlTextView(Activity_New.this);
                            hv.setX(40);
                            hv.setHtml(htmldescription);
                           alert.setView(hv);

I am not in a situation to use the web view hence I was looking for textFieldHTML solution.
Can you let me know what could be wrong?

@vijaykd I've just now bumped in to the same issue, but it's not the fault of this library. In the new version of Html.fromHtml (which this library uses) they also included the ul en li tag, but as you can see it doesn't look good at all. No clue how to fix this issue though, still working on it myself

You can fix it by replacing the tag labels with your own strings before passing it into Html.fromHtml() like so:
public static final String UNORDERED_LIST = "ESCAPED_UL_TAG";
public static final String ORDERED_LIST = "ESCAPED_OL_TAG";
public static final String LIST_ITEM = "ESCAPED_LI_TAG";

public static String overrideTags(@Nullable String html){

    if (html == null) return null;

    html = html.replace("<ul", "<" + UNORDERED_LIST);
    html = html.replace("
", "</" + UNORDERED_LIST + ">");
    html = html.replace("<ol", "<" + ORDERED_LIST);
    html = html.replace("
", "</" + ORDERED_LIST + ">");
    html = html.replace("<li", "<" + LIST_ITEM);
    html = html.replace("
", "</" + LIST_ITEM + ">");

    return html;
}

Then those tags will not be recognized by the default tag handler and will be passed to this library's tag handler. You then have to edit this library's HtmlTagHandler and replace all the instances where it tries to match the tags "ol", "ul', "li" with your corresponding overridden string.

@xGary this is an awesome idea for a fix! Can you make a pull request that in-cooperates this into the library? I would definitely merge this.

@dschuermann Done #79

release in 3.1


CI fails on Windows checks

CI fails on Windows tests on the step Run<EMAIL_ADDRESS>with the next message:
CondaError: Cannot link a source that does not exist. C:\Miniconda\Scripts\conda.exe
Running `conda clean --packages` may resolve your problem.

##[error]The process 'C:\Miniconda\condabin\conda.bat' failed with exit code 1

Note: Reopened #1904, since it was closed by mistake

Is this still an issue @amyskov?

I think, that it is not an issue since the problem is not reproduced no more.


Unable to Clone repository

Issue Type: Bug
Tried multiple ways, still unable to clone my repository in to my editor
Extension version: 0.17.0
VS Code version: Code 1.46.1 (cd9ea6488829f560dc949a8b2fb789f3cdc05f5d, 2020-06-17T21:13:20.174Z)
OS version: Windows_NT x64 10.0.18363

System Info

Item
Value

CPUs
Intel(R) Core(TM) i3-4130T CPU @ 2.90GHz (4 x 2893)

GPU Status
2d_canvas: enabledflash_3d: enabledflash_stage3d: enabledflash_stage3d_baseline: enabledgpu_compositing: enabledmultiple_raster_threads: enabled_onoop_rasterization: disabled_offprotected_video_decode: unavailable_offrasterization: enabledskia_renderer: disabled_off_okvideo_decode: enabledviz_display_compositor: enabled_onviz_hit_test_surface_layer: disabled_off_okwebgl: enabledwebgl2: enabled

Load (avg)
undefined

Memory (System)
7.92GB (3.67GB free)

Process Argv

Screen Reader
no

VM
0%

@sumanmba Can you please provide some more details? Did you use the Git: Clone command? What was the result?

I'm trying to do it in VS Code editor directly. Unable to do the same. Didn't try any other alternatives

It sounds like the Git extension isn't activated, do you have Git installed? https://git-scm.com/download

This is probably related to https://github.com/microsoft/vscode-pull-request-github/issues/1331
I also get that error on Arch Linux. I do indeed have Git installed.

Command 'GitHub Pull Requests: Configure Remotes...' resulted in an error (command 'pr.configureRemotes' not found)

@brettinternet Are you using VSCodium or other community build of VSCode?

@RMacfarlane Thank you, I should have clarified. I am using code, which is built from VSCode upstream. I'm not sure of the licensing distinctions, however I am confident that it's not VSCodium.

Got it, thanks! For that build, you will need to start code as code --enable-proposed-api GitHub.vscode-pull-request-github, see here: https://github.com/Microsoft/vscode-pull-request-github/wiki#3-why-isnt-the-extension-starting

@RMacfarlane Wonderful! Thank you very much. This issue should now be more visible when users search that specific error.

Closing this issue, as the "Clone repository" feature has been moved to vscode. Please open a new issue there if you still see this problem. Thanks!


[ENH] non-parametric default for _predict_proba if _predict_quantiles is available

Point raised by @Ram0nB in https://github.com/sktime/skpro/pull/236, about using a more meaningful default for _predict_proba if not available. Relevant for skpro, but also the same logic in sktime:

Original comment

One thing that comes to mind is whether we also want to add the logic of converting a quantile prediction to a distribution estimate to the BaseProbaRegressor. Currently, the implementation of BaseProbaRegressor's _predict_proba uses the var and mean prediction to return a normal distribution.
Maybe we can enhance BaseProbaRegressor's _predict_proba such that it uses the QPD_Empirical if _predict_quantiles/_predict_interval are available, and else the current logic. This way, we don't assume a normal distribution if multiple quantiles are available. What are your thoughts on this @fkiraly ?

What are your thoughts on this @fkiraly ?

Excellent suggestion, in my opinion!
Yes, the normal assumption has bothered me for a while, but there haven't been too good alternatives before the various empiricals had been implemented.
One question of course is, one would need to choose some arbitrary quantile points if we would be using empirical QPD.
Perhaps, all the percentiles?
Further, a problem could be lack of smoothness, which have the risk of suddenly breaking user workflows that involve losses assuming continuous distributions, this might be a major issue to finish discussion on before doing sth too quickly.

Some options I can think of, besides making this the default overall:

a wrapper that overrides the default _predict_proba, e.g., EmpiricalPredictProba(my_regr)
a config via set_config that allows to set the type of default being used


Code cleanups and Data Helper organization

Summary
Cleaned up DataHelpers, SlashCommand, Team, Friend, etc. Reorganized files to line up with their headers, and removed undefined declarations.
The objective to is to clean up DataHelpers and SlashCommands, and make it easier to find methods relating to their purpose.

@nemerle you had originally moved a lot of these methods into DataHelpers. So I'd like your input before merging, as maybe there was a reason for that that I overlooked.


adding windows compatibility

Based on the work from #55 I created a pull request that addresses several Windows compatibility issues in the code and dpnishant's concern about regression failures in *nix platforms. It does the following things:

Uses the  Python platform module to determine the OS and call time.strftime appropriately. On non-windows systems it uses the old call.
Changes all hardcoded "/"s in paths to use either os.sep, or os.path.join
Uses the Python tempfile module to replace the hardcoded reference to "/tmp"

I tested this on Windows 10 and MacOS 10.11.6 successfully, using the following launch parameters: -a iGoat -p ios -s scripts/iOS --spawn 1

@cutler-scott-ey Thanks for the PR. Appreciate it.


remove disabled="" on element a (old code), we dont use it anywhere. Use external link instead of it.

Changes:

...

Type of change

[ ] Bug fix
[ ] New feature
[ ] Update feature
[ X ] Refactor code
[ ] Translation to code
[ ] Translation to crowdin
[ ] Script configuration
[ ] Improve performance
[ ] Style only
[ ] Dependency update
[ ] Documentation update
[ ] Release

LGTM


Messages sent by another number

Hello, thank you very much for your free service Whin, I greatly appreciate your usefulness. In the last few days I have received messages from Whin from another phone number: +34 605 797764 instead of +34 605 164997. I would like to know if I am doing something wrong on my side, or if it is a characteristic of the service itself. Some time ago the same thing happened, but it normalized after a few days. Thank you very much!

Hi, the whin free gateway is using always the same number.
However, when we do some test, roll out new features, or perform system upgrades, sometimes we switch to a different number to avoid msg delivery disruptions to the community... but this is not always the case, we switch numbers when we believe it is going to take us more than an hour or so to complete our testings.
The numbers you include on your question are both from whin, so don't worry. If you don't wish to receive whatsapps from a different number, you always can block the number on whatsapp :)


V2 - No CNTK Export

Hi Noticed the new V2 does not have the CNTK export. Is this something that is in the pipeline?

Thanks for the feedback.  Leading up to the v2 release we had prioritized other export providers above CNTK.  As long as there is enough interest we can increase the priority of this feature.

I also need the CNTK export option in V2

@JCAAUSFRA @skywalkerisnull - Would you be able to help test the CNTK export in v2?  Code has been merged into develop branch.  If all is good will be included in the next patch/minor release.

I will download it over the weekend and give it a go.

I'm in to

Hey @wbreza I cloned the latest version of the develop branch and was able to sucessfully export the CNTK. I will need to tag a few more images and then run a really quick model through CNTK when I am back infront of the workstation. But otherwise looks promising.


Unable to get command preprocessing to work with the jq library

Describe the bug
I'm using the jq library to format some JSON.
Here's what my markdown file looks like:
# Testing JSON formatting

```
~~~jq '.'
[{"q": "test"}]
~~~
```

Here's the command being run on the command line, to ensure it works as expected:
$ echo '[{"q": "test"}]' | jq '.'
[
  {
    "q": "test"
  }
]

Expected behavior
I'm expecting the code block to show the output of what I see when I run the command above in the command line.
I've verified that the file has chmod +x permissions and other commands work.
Screenshots
Just getting an empty code block. I've verified that the file has chmod +x permissions and other commands work.

Desktop (please complete the following information):

OS: Apple MBP, M1 Max

I did some more testing and it seems that slides isn't happy with the quote (') in the command. Is there any workaround for this?

Are you able to remove the ' from the command?
# JQ

~~~jq .
[{"foo": "bar"}]
~~~

In this case dropping the quotes does work, thank you 🙂
Another "workaround" in the case where quotes might be necessary in someone's command for whatever reason: creating a script.sh file with the full command and then just calling that from the presentation *.md file.
# JQ

~~~sh script.sh
[{"foo": "bar"}]
~~~

and then creating a script.sh:
jq ".[0].q"

I think I know why the quotes do not work, as we have a similar problem with pipes: #148.
I think the solution can be that slides can make a temporary shell script file for the command and execute that if it contains quotes or pipes.

@maaslalani That sounds like an elegant solution! Thanks for this library, having lots of fun playing around with it.


Triangle.gltf is not displayed

I tried to display Triangle.gltf. However, there seems to be an error in the console.
Triangle.gltf result
index.js:256
Uncaught TypeError: Cannot read property 'boundingBox' of undefined
    at MinimalGLTFLoader.glTFLoader.onload (index.js:256)
    at MinimalGLTFLoader.glTFLoader.glTFLoader._checkComplete (minimal-gltf-loader.js:697)
    at loadArrayBufferCallback (minimal-gltf-loader.js:935)
    at XMLHttpRequest.xobj.onreadystatechange (minimal-gltf-loader.js:1313)

Probably because there is no default scene in this model.
If default scene is not specified, it is a good idea to display the first scene.

@cx20 Great thanks for your constant help. I've fixed this at the latest HEAD, together with draw without instances. There's still an issue with animated triangle seems to be a known issue of the old loading code.
As the loader features grow, the temp renderer becomes really ugly (and actually feature incomplete). I'm going to use this loader in one of my other project so that hopefully I can come back with a comparatively more robust and neat renderer (and also refactor some old code, and support for PBR). Might take some time to make the testing list all green. I hope that won't last for too long.

@shrekshao Thank you for fixing. The geometry is correct, but the color seems to be different than expected. Perhaps it is correct to gray as the default value.
Minimal glTF Loader + Triangle.gltf result:

Expected result:

Hmm it seems to me the default material should be a plain white: https://github.com/KhronosGroup/glTF/blob/master/specification/2.0/README.md#reference-material, https://github.com/KhronosGroup/glTF/blob/master/specification/2.0/README.md#reference-pbrmetallicroughness
Is it because I didn't implement PBR?

@shrekshao I'm sorry. Perhaps the specifications may be glTF 1.0 specifications.
https://github.com/KhronosGroup/glTF/tree/master/specification/1.0#appendix-a-default-material
using a default material with 50% gray emissive color.

@javagl Do you know what color Triangle.gltf (https://github.com/KhronosGroup/glTF-Sample-Models/tree/master/2.0/Triangle) is displayed correctly?

@cx20 The spec says that the the material in this case should be one where all values have their default values, as of https://github.com/KhronosGroup/glTF/tree/master/specification/2.0#default-material
So in that sense, the current screenshot (showing the dark gray triangle) could be considered to be "wrong", and the white one is more likely to be "correct" .... assuming that there is some sort of light.

(Well, the gray one is still correct, if there only is a gray light ;-) Technically, every glTF renderer that shows a completely black screen for every model (at least, without emissive info) is a perfectly specification-compliant glTF renderer. As long as there are no lights, nothing is visible. So it's really hard to say what's "right" and "wrong" here...)

(Coincidentally, one of the last changes in the 2.0 branch of JglTF was related exactly to that - namely, setting the proper "default material values". But it is still no complete. It will, in fact, be necessary to create a "Shader Generator", that generates the whole shader code based on the glTF material. Maybe I'll find some inspiration in https://github.com/AnalyticalGraphicsInc/gltf-pipeline/blob/master/lib/processModelMaterialsCommon.js , but this is also still incomplete...)

@javagl  I am a little surprised that white is correct. I thought that it was correct because the sample image and the execution results of other libraries were gray. I would like to reconfirm the settings of the lights of other library samples.

@cx20 Some of the other renderers already have "proper PBR" - particularly, with environment-based lighting. You can see the apparent color change depending on the viewing angle, particularly in Three.js.
But indeed, it's less visible in other viewers, and the differences are considerable.
There, the crucial questions are 1. which sort of lights they are using and 2. whether they are already using the default material of glTF 2.0. (For example, Cesium might still have the default material of 1.0 - but of course, without looking at the code, this is only a wild guess).

Since the triangle is already displayed, this Issue is closed.
As for writing, my understanding is insufficient, so if I find that it is a problem, I would like to report Issue again.


[Backtracing][Android] Fix armv7 build

@al45tair, this broke the Android armv7 CI in #69697, because Android names this differently:
/home/ubuntu/jenkins/workspace/oss-swift-RA-linux-ubuntu-16.04-android/swift/stdlib/public/runtime/CrashHandlerLinux.cpp:246:34: error: no member named 'gprs' in 'sigcontext'
  246 |   pc = (void *)(ctx->uc_mcontext.gprs[15]);
      |                 ~~~~~~~~~~~~~~~~ ^

I used this patch to fix it on my daily Android CI.

@swift-ci Please smoke test

@bnbarham, please run the CI on this again.

@swift-ci please test

Thanks, that got the validation suite running again.


Separate Event Handling

Separate event handling from the main codebase to improve the organization and maintainability of the project.
Objective: Modularize the code for easier debugging and extension of functionalities.

We did some optimizations to reduce some methods complexity.


koji stg builds: dashboard info is half empty and commit status is not updated

2 issues:

The link to logs in https://dashboard.stg.packit.dev/results/koji-builds/1 is non-existent and build start/end times are empty

Even though the build above is finished, the commit status still says pending (this works in prod)

Does it mean we're just not catching some message or even the message is not sent to the message bus?

Does it mean we're just not catching some message or even the message is not sent to the message bus?

Yes, we should specify fedmsg topic org.fedoraproject.stg.buildsys.task.state.change instead of the org.fedoraproject.prod.buildsys.task.state.change in the fedora-messaging configuration file for stg.

can't see any stg messages in datagrepper :/
https://pagure.io/fedora-infrastructure/issue/10116


cuda samples have moved

They are no longer installed with the distro package: https://github.com/nvidia/cuda-samples

Thanks for the update @indigoviolet. I've rewritten the script to install the driver only for now, as we need to address #4
I will work on cuda and cuda samples installation when I deal with this and set up some automated testing


Create an account indexer

account_indexer_v1 is already created. We still need to publish it under dataplatform account and collect historical data. We need to collect all the components we can refactor with account_indexer_v1.

[ ] Use account_indexer_v1 for Notifications. Check this task for the context https://github.com/near/near-discovery/issues/779

#427 needs a tags field on the account indexer.

@shelegdmitriy it would be helpful to know an estimated effort level for this task. Is this more likely to be a 1,2,or 3 sprint effort?

@shelegdmitriy it would be helpful to know an estimated effort level for this task. Is this more likely to be a 1,2,or 3 sprint effort?

We (@gabehamilton and me) have updated the accounts indexer and from now it has all the fields related to profile account. In my opinion it's possible to complete in 1 sprint.


getting errors

File "F:\Python Scripts\HookPhish-main\HookPhish.py", line 6, in
from phish_detector import PhishDetector
File "F:\Python Scripts\HookPhish-main\phish_detector.py", line 7, in
import whois
File "C:\Users\Admin\AppData\Local\Programs\Python\Python312\Lib\site-packages\whois_init_.py", line 7, in
from future import standard_library
File "C:\Users\Admin\AppData\Local\Programs\Python\Python312\Lib\site-packages\future\standard_library_init_.py", line 65, in
import imp
ModuleNotFoundError: No module named 'imp'

we are running this code inpython3