Forward mode

This probably isn't ready to be pulled into the master branch yet, but I thought I'd submit a pr in case you want to track progress.
TODO:

[x] Implement the rest of the numpy grads
[x] Tests for remaining grads
[x] Write a jacobian_vector_product convenience wrapper
[x] Update the hessian_vector_product wrapper to use forward mode
[x] Ensure that nodes with only forward mode grads don't refer to their parents (so that garbage collection can work)
[ ] Implement a jacobian matrix product

Whoa, is is great!
I wonder how much mileage we can get out of adding forward-mode tests to combo_check.  I suggest adding a check to see if the forward gradient is implemented, and if so, test it along a randomly-chosen input dimension without calling to_scalar on the output.  This way we get most of the necessary tests for free.
I suppose we really should be using some sort of code coverage tool too, since right now we can silently forget to add tests.

Yeah, this is awesome! We probably also want to compute hessian differently, like forward_mode_jacobian(jacobian(fun)) or something.
Also, I think this forward-mode defines a derivative operation (with respect to a scalar parameter), but we should consider defining a Jacobian-matrix product operation and thus allowing the loop over input dimensions to happen with each primitive (rather than just as an outer loop as in jacobian). That could be a huge speed win, both in avoiding autograd overhead and in leveraging more numpy to avoid Python overhead. It may be that those Jacobian-matrix products are hard to implement for all primitives, but it would be great for some primitives to support it, even if not all do. (We should think about adding a matrix-Jacobian product operation for reverse-mode too!)

Agreed! (see the bottom item of my TODO list)
On Tue, 3 Jan 2017 at 17:31, Matthew Johnson<EMAIL_ADDRESS>wrote:

Yeah, this is awesome! We probably also want to compute hessian
differently, like forward_mode_jacobian(jacobian(fun)) or something.
Also, I think this forward-mode defines a derivative operation (with
respect to a scalar parameter), but we should consider defining a
Jacobian-matrix product operation and thus allowing the loop over input
dimensions to happen with each primitive (rather than just as an outer loop
as in jacobian). That could be a huge speed win, both in avoiding
autograd overhead and in leveraging more numpy to avoid Python overhead. It
may be that those Jacobian-matrix products are hard to implement for all
primitives, but it would be great for some primitives to support it, even
if not all do. (We should think about adding a matrix-Jacobian product
operation for reverse-mode too!)
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/HIPS/autograd/pull/175#issuecomment-270156544, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AOjgu7JEsElJubtDNcKeL3gcLBEwPzWxks5rOnfogaJpZM4LY52z
.

I'm wondering if we need a way to make a product vspace, for things like the jacobian, whose vspace should be the product of the input vspace with the output vspace...

Also someone at NIPS was telling me it's possible to calculate Hessians 'in one go' with a single reverse pass, the method is outlined here http://www.di.ens.fr/~rgower/pdf/HighOrderReverseAD. I imagine this would be faster for us than the multi pass approach but implementation requires defining the Hessian of each primitive, which could be tedious.

Re: defining Hessian 'pullback' functions for primitives, as in my comment about implementing matrix-Jacobian products, a key advantage of autograd over other tools is its flexibility and simple implementation. I think it would be great to have a clean way to add Hessian operations to primitives, even if we only implement it for a few (as the need arises) and as long as the implementation is small and modular.

I realised my implementation was pretty naive, because I payed no attention to what order forward gradients were calculated within each primitive call... I think things are now correct but I had to use this orderedset thing for the active_progenitors. How do you guys feel about introducing this extra dependency? If necessary I can try to work out another way to do it that isn't too clunky.
I've also added forward mode tests to combo_check, which seems to cover a lot of things.

@j-towns - that seems like a slightly esoteric dependency which doesn't appear to be very actively maintained or supported - e.g. no (windows) wheels, no conda packages.
If you need a sorted set you may be better off using sortedcontainers or the higher level sortedcollections which seem to have a bit of momentum behind them.
https://www.youtube.com/watch?v=7z2Ki44Vs4E

One option would be to use an OrderedDict and have everything point to None.

I'm wondering whether to do some renaming of things in core.py. Currently, for example, the active reverse mode progenitors are in a set called active_progenitors and the forward mode ones in active_forward_progenitors, and this seems a bit unbalanced. So maybe I should add 'reverse' to things that pertain specifically to reverse mode, as I've included 'forward' in the names of things which are specific to forward mode.
Another possibility would be to do this using shorthands 'fwd' and 'rev' or 'rvs' to keep things concise.

I'm gonna close this for the time being, until we have a solid use case.

Calculating the generalized Gauss-Newton matrix (useful in various kinds of second-order optimization) is orders of magnitude more efficient with forward-mode autodiff. Currently this is only possible in Theano.

Hey @jekbradbury, thanks for the heads up. Is that because you need to calculate a 'tall' jacobian matrix?

Yes. It's described on pages 13-14 of http://citeseerx.ist.psu.edu/viewdoc/download?doi=<IP_ADDRESS>6.9240&rep=rep1&type=pdf. The R-operator evaluates the Jacobian-vector product and is equivalent to forward-mode autodiff.
While the Hessian-vector product Hv for a function f(theta) has a concise implementation without the R-op (it's grad(dot(v, grad(f))), although that takes twice as much computation as grad(Rop(f, v))), the (generalized Gauss Newton)-vector product Gv for a function f(g(theta)) needs the R-op/jvp (it's grad(dot(theta, grad(dot(Rop(g, v), grad(f))))) or grad(dot(theta, Rop(f, Rop(g, v)))).)

Awesome, well this is enough motivation for me to get this released.
I think I'm gonna move the forward mode code into its own package and release it as an 'extension' to Autograd.
Hopefully I can get that done by next week.

I have this use case as well (which I may have mentioned before): in K-FAC (which can be interpreted as a GGN method) once the search direction is selected the method described in the paper uses exact GGN-vector products to evaluate the exact Fisher information matrix on a subspace to set stepsizes and momenta. That calculation really depends on forward-mode for the same reason, namely that you fundamentally want a JVP.
I agree with the idea to put it out as an extension. Looking forward to it!

Ah yeah I now remember you mentioned this to me quite a while back. I've been meaning to read the James Martens + Roger Grosse stuff for ages. There are some boneheads in my group working on related methods who really should have pointed this out to me (I'll have to have them punished).
Anyway thanks. It's good to know the forward mode code will be useful for something!

Hey @j-towns, what's the best way for someone to use your forward mode code right now? I've gotten several requests from people who want to play with it.

All you need to do is check out + install this branch of Autograd: https://github.com/j-towns/autograd/tree/forward-mode-new-core. Then you'll be able to do things like
In [1]: from autograd import jacobian_vector_product

In [2]: import autograd.numpy as np

In [3]: def f(x):
   ...:     return x**2 + 1
   ...:

In [4]: jvp = jacobian_vector_product(f)

In [5]: x = np.array([1., 2., 3.])

In [6]: v = np.array([4., 5., 6.])

In [7]: jvp(x, v)
Out[7]: array([  8.,  20.,  36.])

and the hessian_vector_product also has an optional kwarg to use the slightly more efficient mixed forward and reverse modes.
The branch is a bit behind master so doesn't include the recent memory bugfixes etc. But should be perfectly functional.

I've started developing the new extension package over here. There's a few more things to do before it's usable, I'll post on here again when it's ready.

OK it's ready (that was an exercise in surgical copy-pasting). Please let me know of any issues you run into, there are likely to be bugs since this is brand new.
If anyone fancies writing a GGN/K-FAC example that would be awesome 😎.

@mattjj I think implementing a cached version of jacobian_vector_product won't be too tricky and would allow mixed mode cached hvps like the ones you implemented recently, not sure how much performance improvement this would give but there should be some.

That would be great!
On an email list, some DeepMind people pointed out a way to implement GGN-vector products with reverse mode and stop_gradients/getval, essentially exploiting the fact that the GGN matrix looks like the Hessian except with a term set to zero (which we can achieve by calling getval to make something look like a constant). Here's my current sketch of an implementation, though I bet it can be improved.
Regarding purely reverse-mode vs mixed-mode strategies, I suspect that the story for GGN-vector products might end up being similar to the story for HVPs: namely, there should at least be significant memory savings (~2x), though it's less clear if there are any FLOP savings to be expected. I'm still a bit confused on those issues. However, the code in that gist is currently doing two forward passes on f, which I think means it's more expensive in FLOPs too.
If we wanted to do GGN products in the inner loop of an optimization algorithm, like in K-FAC or HF, I suspect that the savings from a mixed-mode implementation would be very much worthwhile. Having that available is a distinct advantage for autograd right now.

Re reverse-mode vs mixed-mode strategies, I realised a little while ago (to my disappointment) that, in an idealised implementation, there isn't a difference in memory usage between hvps with mixed mode vs reverse mode.
In an idealised implementation, both use 2x the memory of calculating the gradient. I think the FLOPS would also be the same or very similar.
In our real, non idealised implementation mixed mode does seem to perform better in both memory and speed, by a modest factor (around 1.5x). I think this is for two reasons. Firstly in forward mode you don't have to record or traverse a graph, which reduces overhead. Secondly the jvps tend to have simpler forms than the vjps, for many primitives. Look at einsum for example, a primitive which I seem to use a lot.

Oh interesting. Hmm, the autodiff papers always imply that mixed-mode is better for HVPs, so it would be interesting if the savings were only in overhead (or the subtle issue you mentioned that JVPs tend to be simpler than VJPs).
I agree that a clear writeup of the comparison would be super helpful, especially because I feel like I've never been able to definitively nail it down for myself. Here's some thinking-out-loud: in rev-rev mode, you have to trace over (i.e. store the intermediates of) an entire forward-backward pass on the function, so that's 2x the max memory usage of just tracing the forward pass. In fwd-rev mode, you evaluate the JVP of the VJP function, which means you only have to trace the forward pass of the function (to form the VJP), and then you can walk backward along that graph evaluating JVPs along the trace, in principle freeing up memory as you go. Doesn't that mean that the max memory usage is only as much as for grad?

I think of Jacobian-vector-product(fun) as doing the same computation as
fun, with an additional computation of jvps going on 'above' at the same
time. The jvp computation has the same memory complexity as fun itself, so
for any function the peak memory usage of Jacobian-vector-product(fun) will
be 2x that of just running fun.
Apply this argument to Jacobian-vector-product(grad(fun)) and you see that
the peak memory usage must be 2x that of grad(fun).
I'm not sure that's a particularly intuition friendly way of explaining it,
it would be nicer to do it with some pictures...
On Fri, 2 Jun 2017 at 18:32, Matthew Johnson<EMAIL_ADDRESS>wrote:

Oh interesting. Hmm, the autodiff papers always imply that mixed-mode is
better for HVPs, so it would be interesting if the savings were only in
overhead (or the subtle issue you mentioned that JVPs tend to be simpler
than VJPs).
I agree that a clear writeup of the comparison would be super helpful,
especially because I feel like I've never been able to definitively nail it
down for myself. Here's some thinking-out-loud: in rev-rev mode, you have
to trace over (i.e. store the intermediates of) an entire forward-backward
pass on the function, so that's 2x the max memory usage of just tracing the
forward pass. In fwd-rev mode, you evaluate the JVP of the VJP function,
which means you only have to trace the forward pass of the function (to
form the VJP), and then you can walk backward along that graph evaluating
JVPs along the trace, in principle freeing up memory as you go. Doesn't
that mean that the max memory usage is only as much as for grad?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/HIPS/autograd/pull/175#issuecomment-305859589, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AOjgu9HxnqN-RtlmUz-jEKG5B-3aeQnHks5sAEc2gaJpZM4LY52z
.

Interestingly I found the other mixed mode method, where you do
hvp = grad(jacobian_vector_product(fun), argnum=1)

to consistently perform worse than
hvp = jacobian_vector_product(grad(fun))

I guess that's cos you're reverse-moding more stuff in the top one.

Let's say our function is
def f(x):
  for i in range(N):
    x = np.sin(x)
  return np.sum(x)

Evaluating f(x) or jacobian_vector_product(f)(x)(v) requires memory that is independent of N, since even though we allocate temporaries for intermediate outputs, we can also free them up as we go. I agree that evaluating the JVP requires about twice the max memory as evaluating the function, since we basically need two temporaries in the JVP for each place we needed one temporary in the function, but both are independent of N.
However, when we trace the execution of f(x) to evaluate grad(f)(x) in reverse-mode, we need to store all the intermediates in the trace, requiring an amount of memory that grows linearly in N. That memory usage, which scales with N, is the unit of measure when we compare how much memory an HVP takes compared to the memory required by the reverse-mode gradient.
I think the rev-rev HVP requires memory that scales like 2N, while the fwd-rev HVP requires memory that scales like N.

evaluating the JVP requires about twice the max memory as evaluating the function

This is true for all functions, including those which happen to be grad(something).
I'm pretty sure you can't get around this fact, even in the special case of hvps.
Here's some graphs. Firstly a forward mode computation graph:
jvp(fun)  u_1 --> u_2 --> v
           ^       ^      ^
           |       |      |
fun       x_1 --> x_2 --> y

and reverse mode:
vjp(fun)  u_1 <-- u_2 <-- v
           ^       ^      ^
           |       |      |
fun       x_1 --> x_2 --> y

And this is what the hessian vector product graph looks like (I've dropped the subscripts because I'm lazy).
jvp(vjp)(fun)  z  <--  z  <--  z
             ↗ ↑     ↗ ↑     ↗ ^
vjp(fun)   u  <--  u  <--  v   |
           ^   |   ^   |   ^   |
           |   w - | → w - | → w
           | ↗     | ↗     | ↗
fun        x  -->  x  -->  y

This graph has the same structure as the vjp one, and you need to record the bottom rows in order to compute the top two rows just like in a vjp.

For completeness, I guess the reverse mode approach looks like this:
               z  -->  z  -->  z
             ↗ |     ↗ |     ↗ |
vjp(fun)   u  <--  u  <--  v   |
           ^   ↓   ^   ↓   ^   ↓
hvp(fun)   |   w ← | - w ← | - w
           | ↗     | ↗     | ↗
fun       x_1 --> x_2 -->  y

Whoa, amazing ascii art. I haven't fully parsed them yet, but just to be clear, do you claim that the JVP of the VJP requires 2N memory?
Your first two graphs nicely illustrate why the JVP is more memory-efficient than the VJP. Instead of just going up to index 2, let's tile things horizontally and say they go up to index N, so that the total horizontal extent of each graph is N+1 nodes. With the semantics that to evaluate a node we require the value of its parents, we can evaluate the JVP graph using a largest active set of 2 nodes. However, to evaluate the VJP graph we need an active set of N nodes, since to evaluate u_N we need x_1, ..., x_N as well as v. That is, to evaluate the VJP graph we need to store the values of about N nodes in active memory, while to evaluate the JVP graph we only have to store about 2.
As for the jvp-of-vjp graph, my claim is basically that we don't have w (what is that meant to be, anyway? we're not doing forward mode on f). I think the VJP of f only stores the x's, just like before, and then the JVPs we need can be computed using those x's (and no w's) along with the vector we're propagating. In other words, to draw the jvp-of-vjp graph, I think you should take the VJP graph in your second diagram, and then replace the chain of u's with a copy of the JVP chain from the first diagram, without introducing w's. Then the backbone of things we have to store is just N, not 2N.
Is there a mistake I'm making? What's w supposed to be?

do you claim that the JVP of the VJP requires 2N memory?
Precisely, yes. I agree that jvp(f)'s memory usage doesn't scale with N.

I previously thought exactly what you've just described was how it worked, I only revised my thoughts after I'd already finished writing forward mode and was surprised by the performance of the new hvps.
To address your questions, grad(f) does a forward pass and a reverse pass. If you do jvp(grad(f)), then you're going to be forward differentiating the whole of grad, both forward pass (i.e. f itself) as well as the reverse pass. Those w's are the forward derivatives of the forward pass.
It sounds like your suggesting a graph like this (have I got the arrows in the right direction?)
jvp(vjp(fun))  u_1 <-- u_2 <-- v
                ^       ^      ^
                |       |      |
               u_1 <-- u_2 <-- v
                ^       ^      ^
                |       |      |
fun            x_1 --> x_2 --> y

Which looks like you're just forward differentiating the reverse pass. Can you do that?
If you decompose grad into the forward pass and the reverse (vjp) pass, you could forward differentiate just the reverse vjp pass w.r.t. v, but this would just yield the gradient. I don't think you can forward differentiate it w.r.t. x_1 because the vjp isn't directly a function of x_1.

I think that's what I'm proposing. Would this do it?
import autograd.numpy as np
import autograd.numpy.random as npr
from autograd.core import make_vjp
from autograd_forward.core import make_jvp
import autograd.convenience_wrappers

def make_hvp(f):
  def hvp_maker(x):
    vjp = make_vjp(f)(x)[0]
    vjp = lambda x, v: make_vjp(f)(x)[0](v)
    def hvp(v):
      return make_jvp(vjp)(x, 1.)[0](v)[1]
    return hvp
  return hvp_maker

N = 10
def f(x):
  for i in range(N):
    x = np.sin(x)
  return np.sum(x)

x = npr.randn(10)
v = npr.randn(10)
print make_hvp(f)(x)(v)
print autograd.convenience_wrappers.make_hvp(f)(x)(v)

No, that code wouldn't do it: we'd still be running the VJP over the forward pass!
Let's look at the VJP as a function of both x and v. I agree we want to differentiate wrt x (and not v). It seems like there must be some way to do it, but I admit my thinking about it was flawed.

Just to summarize the current state of our knowledge, in idealized implementations, HVPs in rev-rev and fwd-rev have about the same memory and FLOP cost, given the best implementations we've figured out?
And for GGN- or Fisher-vector products, the story is different, since we can evaluate F v = (J' M J) v = (J' (M (J v))) using just a JVP, application of M, and then a VJP. That should cost half the memory of the rev-rev implementation I posted earlier, I think, since in this case we really are only tracing just the function.

Yeah. rev-rev, fwd-rev and rev-fwd all have the same cost, at least as far as I can tell. I noticed @jekbradbury you said above

grad(dot(v, grad(f))) ... takes twice as much computation as grad(Rop(f, v))

Is that commonly believed to be true? It would be good to get a reference for this.
I'm not sure about GGNs, but just looking at your sketch, doesn't the getval on line 18 prevent grad(f) from being traced by the outer grad operator? I.e. only one evaluation of f is stored (although g will be differentiated twice)?
I fear I may be hammering the final nails into the coffin of our forward mode use case... which is cruel irony. I guess that's the nature of research!
Nevertheless, forward mode for Autograd will always have the slight performance advantages from lower overhead and simpler primitives.

It's also a bit inelegant having to use getval

I'm convinced by your arguments above, and in looking back through the Hessian-free papers I read I'm not sure where I got the "twice as much" claim (I think I didn't make it up, and it's certainly the case that the fwd+rev approach is considered standard, with an obligatory citation to Pearlmutter 1993).
I've also realized that the rev-rev approach for GGN-vector products given by @mattjj was actually mentioned in passing (if a little cryptically) in Martens's thesis, and I simply missed that while trying to look for a way to avoid requiring the R-op/having to port a codebase from TF to Theano.

I think my misunderstanding comes from the idea that if you have a computation graph a->b->c, grad transforms it into a->b->c->c'->b'->a', while Rop transforms it into a"->b"->c" (where " is JVP), so wouldn't grad(Rop(f, v)) "double" the size of the graph while grad(dot(v, grad(f))) "doubles" and then "doubles" it again? But @j-towns's ASCII art makes it clear that both forward and reverse mode double the number of nodes in the graph, so they're of similar computational cost in terms of FLOPs.

I think we can write it without getval by instead making two copies of x and only boxing one of them, though it still looks a bit weird and is still evaluating f forward twice:
def make_ggnvp(f, g=lambda x: 1./2*np.dot(x, x)):
  def grad_h(x, y):
    f_vjp, _ = make_vjp(f)(y)
    return f_vjp(grad(g)(f(x)))
  def ggnvp_maker(x):
    return make_vjp(grad_h)(x, x)[0]
  return ggnvp_maker

Not sure about the memory complexity :)
Side note: James was actually involved in the discussion where this rev-rev FVP came up, and it didn't sound like he knew of this particular rev-rev approach, but maybe he just knew of it in a different form, or was dissatisfied with its efficiency compared to the mixed-mode approach.

"As observed by Martens and Sutskever (2011), the second interpretation of the GGN matrix given in Section 3.4 immediately implies an alternative method for computing Gv products. In particular, we can use the R method from Section 4.3 to efficiently multiply by the Hessian of h, given a computational graph for ∇h. While doing this would require one to replace the forward pass (corresponding to f) with a multiplication by the Jacobian of f evaluated at θ_k, a simpler approach is just to modify the algorithm for computing ∇h so that in the backwards pass, all non-differential quantities computed during the forward pass (like the a_i, but not Da_i) are treated as “constants”, which while they are computed from θ_k, are considered formally independent of θ."

If you take this "simpler approach" and combine it with the rev-rev method for Hv, I think you get the method you mentioned.

Here's a way only to run the forward pass on f once, but it's delving a bit deeper into the internal API:
from autograd.core import backward_pass

def make_ggnvp(f, g=lambda x: 1./2*np.dot(x, x)):
  def grad_h(x):
    f_vjp, y = make_vjp(f)(x)
    return backward_pass(grad(g)(y), x, y)
  def ggnvp_maker(x):
    return make_vjp(grad_h)(x)[0]
  return ggnvp_maker

I guess it would be very straightforward to run the forward pass only once if you allow yourself to use fwd mode, since you could easily write a wrapper make_jvp_and_vjp that cached the forward pass and returned functions for evaluating the reverse and forward derivative passes.
Note that I haven't yet written the necessary core stuff for jvps on cached forward passes, but am intending to, as I said above.

If I trace the execution of make_ggnvp(f, g)(x)(v) I get something like (pseudocode)
start_grad_h, end_grad_h = forward_pass(grad_h, x):
  start_f, end_f = forward_pass(f, x)
  res_f = f(x)
  start_g end_g = forward_pass(g, res_f)
  grad_f = backward_pass(1.0, end_g, start_g)
  backward_pass(grad_f, end_f, start_f)
backward_pass(v, end_grad_h, start_grad_h)

But the below attempt to replicate that doesn't work because gx isn't a node (I'm not that familiar with autograd internals):
def do_ggnvp(f, g, x, v):
  start_f, end_f = forward_pass(f, (x,), dict())
  start_g, end_g = forward_pass(g, (end_f,), dict())
  gf = backward_pass(1.0, end_g, start_g)
  gx = backward_pass(gf, end_f, start_f)
  return backward_pass(v, gx, start_f)```

Meanwhile in TF-world... https://github.com/renmengye/tensorflow-forward-ad
Since it's from Toronto, this is probably a cleaned-up version of the code that underlies the Distributed K-FAC paper.

I think I've got a solution which only traces f forwards once (took a little while to work out how to do this!):
def make_ggnvp(f, g=lambda x: 1./2*np.dot(x, x))
    def ggnvp(x):
         f_vjp, f_x = make_vjp(f)(x)
         g_hvp, grad_g_x = make_vjp(grad(g))(f_x)
         f_vjp_vjp, _ = make_vjp(f_vjp)(grad_g_x)
         return lambda v: f_vjp(g_hvp(f_vjp_vjp(v)))
    return ggnvp

I think you did it! I tweaked the test code in the gist like this:
def check_ggnvp(f, x, v):
  gnvp = make_ggnvp(print_calls(f))(x)
  gnvp2 = make_dense_ggnvp(f)(x)
  return np.allclose(gnvp(v), gnvp2(v))

def print_calls(func):
  def wrapped(*args):
    print 'ran {}'.format(func.func_name)
    return func(*args)
  return wrapped

and verified that the function is only run once with your code.
This might be an explanation: f_vjp is a linear function, so calling make_vjp on it returns a function that evaluates its adjoint. Then you're just evaluating (J' (H (J v))) using implicit matrices (i.e. J' is formed by make_vjp in the usual way, and J formed by calling make_vjp on f_vjp to get J'' = J). If that explanation is right, then it would seem obvious in hindsight!

Two more things. Firstly this works too:
def make_ggnvp(f, g=lambda x: 1./2*np.dot(x, x))
    def ggnvp(x):
        f_vjp, f_x = make_vjp(f)(x)
        g_hvp, grad_g_x = make_vjp(grad(g))(f_x)
        f_vjp_vjp, _ = make_vjp(f_vjp)(np.zeros_like(grad_g_x))
        return lambda v: f_vjp(g_hvp(f_vjp_vjp(v)))
    return ggnvp

and what about this trick:
def jacobian_vector_product(f):
    def jvp(x, v):
        f_vjp, f_x = make_vjp(f)(x)
        f_vjp_vjp, _ = make_vjp(f_vjp)(np.zeros_like(f_x))
        return f_vjp_vjp(v)
    return jvp

jacobian vector products with reverse mode!!

So perhaps the conclusion is that you can calculate Jacobain vector products (albeit probably quite inefficiently) with only reverse mode, therefore you can certainly calculate GGN vector products...

Wow nice. Calling vspace(getval(f_x)).zeros() would be slightly more general (maybe we should have a function that does that).
I think if evaluating the function costs 1 unit, then the forward-mode JVP costs 2 units, and this reverse-mode VJP costs 3 units (because we trace the execution of f, then we trace its vjp, and then finally we run the vjp vjp).

Also, I would tweak your jacobian_vector_product to do the caching thing we like now:
def jacobian_vector_product(f):
    def jvp_maker(x):
        f_vjp, f_x = make_vjp(f)(x)
        f_vjp_vjp, _ = make_vjp(f_vjp)(np.zeros_like(f_x))
        return f_vjp_vjp  # f_vjp_vjp is just f_jvp!
    return jvp_maker

Nice! I guess we should look at getting this stuff into convenience_wrappers.py

Yeah definitely! The confusing (yet obvious in hindsight) thing here is that the call f_vjp_vjp, _ = make_vjp(f_vjp)(zeros) is differentiating with respect to v, not x, just to form the adjoint of f_vjp.
And now we have a clear picture for why forward mode should let us be 1.5x more efficient for the first GGN-vector product: basically because the first JVP is 1.5x more efficient.
However, I wonder if we could eliminate that cost somehow, or at least reduce all the FLOPs and just have some graph munging overhead. Propagating the zeros is a waste; we really just want to do a transformation to the graph inside f_vjp. I wonder if we can add another function to core.py called adjoint... does this idea make any sense?

Btw I just merged a PR that I'm hoping, but haven't confirmed, will help make these functions handle broadcasting automatically. (If not, we should consider adding broadcasting versions, maybe with explicit axis arguments that get summed over at the output.)

I started adding these in the add-jvp-and-ggnvp branch.

Nice. Re adjoint operator, don't you reckon for the effort of implementing that you might as well use fwd mode? I'm planning to implement a cached fwd mode which will produce something roughly equivalent to what you're saying, I think.

Yes, definitely. I mainly meant it as an academic question: how small can we make the FLOP cost for a reverse-mode implementation of GGN-vector products (or even for JVPs), compared to a mixed-mode solution? That's interesting for our understanding of autodiff, and also more relevant to people who are using systems without full mixed-mode capabilities.
It might be relevant for TensorFlow, where graph manipulation overheads don't matter so much because they only happen ahead-of-time. Wouldn't this let us generate FLOP-efficient JVP routines in TF, by calling tf.gradients twice? (That might insert extra ops in the TF graph that aren't necessary, but in principle it should generate code that is FLOP-efficient, I think.)

It definitely matters for PyTorch, where the autograd library is a fairly substantial codebase that's only able to support reverse mode. I will try to wrap my head around these code snippets well enough to be able to rewrite them in PyTorch style (I'm currently trying and failing to do that in the GGN-related Theano code I have).

Based on @j-towns's autograd code, I think this is a way to get forward-mode for free in TensorFlow:
import numpy as np
import numpy.random as npr
import tensorflow as tf

def fwd_gradients(ys, xs, d_xs):
  """Forward-mode pushforward analogous to the pullback defined by tf.gradients.
  With tf.gradients, grad_ys is the vector being pulled back, and here d_xs is
  the vector being pushed forward."""
  v = tf.placeholder(ys.dtype, shape=ys.get_shape())  # dummy variable
  g = tf.gradients(ys, xs, grad_ys=v)
  return tf.gradients(g, v, grad_ys=d_xs)

A = tf.constant(npr.randn(5, 3), dtype=tf.float32)
x = tf.placeholder(tf.float32, [1, 5])
y = tf.tanh(tf.matmul(x, A))
u = tf.placeholder(tf.float32, [1, 5])

jvp = fwd_gradients(y, x, u)

x_val = npr.randn(1, 5)
u_val = npr.randn(1, 5)

init_op = tf.initialize_all_variables()
with tf.Session() as sess:
  sess.run(init_op)
  print sess.run(jvp,  feed_dict={x: x_val, u: u_val})

It does extra work ahead of time (i.e. at graph construction time), but those extra graph nodes being built shouldn't be involved at runtime, and the TF executor should in principle be able to carry out the Jacobian-vector product without any FLOP or memory overhead compared to a manual implementation of forward-mode. I haven't studied it closely, though, so there could be some subtleties or drawbacks.

Firstly, are you saying the FLOP cost is the same as fwd mode for the first vector you give to a jvp at a fixed point x? Or just for subsequent vectors? I guess for subsequent vectors we would expect the flops to be the same.
However for the initial computation, wouldn't g need to be computed at runtime? Or is TF clever enough to somehow not compute it? I guess it wouldn't be too difficult to test this, by hand implementing a fwd mode graph for something simple like an MLP and comparing timings, but maybe you know TF well enough to be confident that the nodes for computing g are somehow factored out of the final graph.

Assuming the TF interpreter isn't factoring out the computation of g, perhaps this optimization is the kind of thing which could be written into XLA.

Ah wait I think I'm with you on the runtime FLOPs now — because the all of the mappings in the reverse pass are linear as functions of g, TF can see that the nodes in the final graph needn't depend on g. Is that correct?

Yes, that's right. There's a graph to draw here, but I don't have your ascii art skills. For chain-structured functions, have three chains involved here: the top one is from the function eval, the middle one from the first call to tf.gradients, and the bottom one from the second call to tf.gradients. As you say, the bottom one doesn't actually depend on the values from the middle one, by linearity. Both the bottom chain and the middle chain depend on the values of the top chain.
Even better, there won't even be extra memory overhead at runtime: because the top chain and bottom chain have arrows pointing in the same direction (i.e. to the right), and the arrows from the top chain to the bottom don't skip steps, the TF graph executor is smart enough to reuse memory as it performs the evaluation, rather than evaluating things in a bad order and keeping too large an active set.
One way to convince yourself that g isn't evaluated at runtime is the fact that we don't even need to supply a value for v in feed_dict; that variable stays unbound, and we don't get an error because we never try to evaluate a node that depends on it.

Reverse mode FTW again! 😎
On Thu, 8 Jun 2017 at 15:14, Matthew Johnson<EMAIL_ADDRESS>wrote:

Yes, that's right. There's a graph to draw here, but I don't have your
ascii art skills. For chain-structured functions, have three chains
involved here: the top one is from the function eval, the middle one from
the first call to tf.gradients, and the bottom one from the second call
to tf.gradients. As you say, the bottom one doesn't actually depend on
the values from the middle one, by linearity. Both the bottom chain and the
middle chain depend on the values of the top chain.
Even better, there won't even be extra memory overhead at runtime: because
the top chain and bottom chain have arrows pointing in the same direction
(i.e. to the right), and the arrows from the top chain to the bottom don't
skip steps, the TF graph executor is smart enough to reuse memory as it
performs the evaluation, rather than evaluating things in a bad order and
keeping too large an active set.
One way to convince yourself that g isn't evaluated at runtime is the
fact that we don't even need to supply a value for v in feed_dict; that
variable stays unbound, and we don't get an error because we never try to
evaluate a node that depends on it.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/HIPS/autograd/pull/175#issuecomment-307116382, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AOjgu1RWppjrUN5c6qS2-9oEoVeqaGZmks5sCAGpgaJpZM4LY52z
.

Here is a quick attempt at a graph:

Each op in the blue chain is linear in the arguments moving right to left (i.e. coming from v). Due to that linearity, the orange chain doesn't depend on the values in the blue chain. We can evaluate y and J u given values for x and u using a maximal active set size of two nodes, and indeed this is the same graph that would be produced by a manual forward-mode implementation.
All that is my current thinking, but isn't really tested, and there may be TF implementation details that we haven't accounted for.

Bruce Christianson claims in his paper "A Leibniz Notation for Automatic Differentiation", Theorem 1,  "The three algorithms forward-over-reverse, reverse-over-forward and reverse-over-reverse are all numerically stepwise identical, in the sense that they not only produce the same numerical output values, but at every intermediate stage perform exactly the same floating point calculations on the same intermediate variable values"
If true, then we can see that the forward-mode calculation of some original function f must be buried, thus accessible via dead-code elimination, inside of a reverse-over-reverse twice-differentiation of f. Spooky.

I see second derivatives there. Doesn't his theorem generalise to the equivalence we were discussing last week (see above) between different methods for calculating Hessian-vector products? Not to be confused with what we're talking about here, which is Jacobian-vector products.

As an aside, I agree with his point that Leibniz notation > Newton notation, although what he calls his 'bariential' notation seems unnecessary.

Good eye on the 2nd derivatives there!
I like that the autograd issues tracker is a hotbed for autodiff discussion, though it would be even better if the information here were eventually distilled into some docs, or even the long-promised autograd paper.

I've written a blog post on this: https://j-towns.github.io/2017/06/12/A-new-trick.html. @mattjj and @jekbradbury I wasn't sure how to credit you guys, I've linked to this thread at the top of the post, if you guys want me to include your names (or anyone else's) explicitly let me know.

Just chiming it to say how awesome and satisfying this all is.  It's like something out of SICP.
It seems obvious in retrospect: How do you get forward-mode?  By reversing reverse mode! :)

Awesome blog post, @j-towns! I think the way you wrote it is great; citing the thread is a good way to share credit. It might have broader audience appeal if you include the TF implementation in the post, too, since TF is so popular right now (maybe linking to my comment in the thread).
@duvenaud I agree, and I think we were right on top of this idea for a while without noticing it.

Good point. I've put a link at the very bottom of the blog post and also on the post I've made on reddit.

Hmm I'm gonna have a go at running my forward mode implementation, but applying the new vjp(vjp) method on a primitive by primitive basis to get the jvps (rather than using the jvps that I've hand implemented).
It will be interesting to see how much overhead this introduces over the hand implemented jvps (this was discussed a bit above – I reckon there will probably be some overhead).
If the overhead is negligible this is great news because it means we only have to maintain

Finally catching up on this thread. Beautiful work, @j-towns and @mattjj!@duvenaud is right, it's one of those elegant results that's natural and obvious once it's pointed out but takes some real wizardry to get to in the first place.
I've been trying to think of ways we can avoid unnecessary FLOPS (FLOs?) in make_jvp and make_ggnvp. Here's one approach: we can introduce a special 'zero vector' object which the primitive wrapper can recognize and propagate FLO-free. But it's only ok to propagate a zero if the primitive is linear in that argument. We know the vjps are all linear, but we need to trace their component functions, which can be arbitrary primitives (although they're almost certainly linear in practice). One trick for figuring out linearity is to use the fact that a primitive is linear in one of its args iff its vjp doesn't use that arg in its definition (aside from things like extracting shape information, but our vspaces should make that unnecessary).
Off the top of my head, here are three options for figuring out linearity:

Inspect a function's body to detect whether it uses each arg. CPython must do some version of this internally because it garbage-collects variables present in the environment of a closure when the inner function doesn't use those variables. Maybe this machinery is exposed somewhere.
Use special variable names in vjp definitions to denote 'unused variable', which we can easily extract with the inspect module. I wish we could use _, but it's a regular identifier and can't be used twice in a function's args.
Explicitly tag the primitive with the linearity information. We will probably always need this option as a fallback for functions that can take an unbounded number of arguments, like concatenate_args.

A bonus side effect of doing this is that we can use the linearity information to avoid storing objects that the vjp doesn't need. As this thread makes clear, people really do care about memory use. Currently, we're needlessly hogging memory with linear operations like matrix multiplies.
But here's one major wrinkle: in order to propagate zeros, we need to be able to predict the output vspace of a function without evaluating it. We've basically been building our own type system within Autograd, so function signatures would a natural thing to add. It's a bit tricky because the output vspace isn't just a function of the input vspace(s) but also of (non-float) args like 'keepdims'. It's also a bit of a pain to have to write out all these function signatures. On the other hand, it would be hugely helpful for automated testing of primitives.

Yeah that sounds like a good template for how we could bring the FLO cost down for jvp/ggnvp. I have a minor question, on the point about avoiding storing objects that aren't needed, would it actually be possible to know ahead of time that a variable isn't going to be needed by any vjp?
It seems to me that if the user does something like this:
def f(x):
    a = np.ones(3)
    y = np.dot(a, x)
    return y**x

Although the third line is linear in x, Autograd has no way of knowing (until the function has returned/the graph has been completed) that x won't be needed somewhere else during the reverse pass.
Pruning nodes surely wouldn't be able to happen until the whole graph had been constructed, by which point we don't really care, since it's the peak memory usage that we wish to reduce.

@j-towns , you're raising excellent points. I'm living in the past. There was a brief period of Autograd's history when we separated the value-storing Node from the graph-representing ReverseNode. In fact, this sort of memory optimization was the whole motivation for the ReverseNode. In those days, the vjp functions returned a closure and Python was clever enough not to store those variables that weren't used in the inner function. The only data structure you'd end up after evaluating your composite function was a tape of ReverseNodes, with the values themselves stored implicitly in the closures as needed. The sad thing is that we ended up adding value to ReverseNode to track (generalized) shape information, which completely defeated the purpose. Now that we have vspaces, we wouldn't need to do that any more.
So it looks like what I'm proposing would require re-introducing some sort of ReverseNode. The memory saving are pretty compelling so it might be worth it. And we have benchmarks now to see whether the overhead is really anything to worry about. We could even go back to the nested functions of defgrad but I feel bad constantly swapping out the the interface from under people's feet.

Ah ok, that all makes sense. I'm just wondering if there's some way we can get the benefits of python's garbage collection without having two separate Node types (which is nasty IMO).
What about keeping Node as it is, but instead of having it contain vjp and recipe attributes, have it contain just a vjp, which is a closure that evaluates the vjp from the Node all the way back to its progenitor. This would also mean that backward_pass would simply evaluate the final Node's vjp function, removing the need for the toposort and manually looping over the graph. Please shoot me down if there are obvious reasons why that's bad!

A minor point: I think it's kind of elegent having the local primitive vjp's constructed by make_vjp closures, since this matches the global make_vjp function.

Edit: I guess it wouldn't be possible to efficiently handle fan out and fan in with what I think I was suggesting there.

Yup, you got it.

A minor point: I think it's kind of elegent having the local primitive vjp's constructed by make_vjp closures, since this matches the global make_vjp function.

You know, I have to agree. That plus the memory optimization and I'm starting to regret changing the interface. The arguments at the time were (1) slight reduction in overhead and (2) simpler interface for users. If it weren't for the albatross of backwards compatibility I'd change it back right now (keeping the vspaces).

I say make the change! We can figure out a way to make the transition easy enough. Maybe we could require uses of the non-staged defvjp method to be rewritten as defvjp_unstaged to keep working, which isn't too much of a burden. Or we could add a defvjp_staged method for the new-old way.
def defvjp(self, vjpfun, argnum=0):
    warnings.warn(defvjp_staging_is_better)
    def make_vjp(ans, vs, gvs, *args, **kwargs):
        def vjp(g): return vjpfun(g, ans, vs, gvs, *args, **kwargs)
        return vjp
    self.defvjp_staged(make_vjp, argnum)

(Not sure where the ans, vs, and gvs arguments should go, but you get the idea.)
Is there a problem I'm overlooking with switching between staged and unstaged versions like this?
IMO autograd's internals should stay agile.

That's the spirit!
Technically, defvjp is external because we mention it in the tutorial. But then again, so is our digestive tract.
Ok, I'll make a branch with the changes. It'll be nice to finally benchmark it too.

Do we think things should be named as they were before, with a Node and ReverseNode? I'm wondering if ReverseNode should really be called Node, since the reverse nodes form a graph, and then what used to be called Node could be renamed something like ActiveVariable?


Typescript scripts

Hi there!
We are looking around for typed scripting languages to run on our devices.
I experimented a bit with typescript and running it through tsc before microvium, but I'm not very experineces around js/ts/node etc so I'm not sure how to handle for example vmImport and vmExport.
Is there some magic ready to use or do you have throughts to share on how one could (or if one even should) approach a .ts -> .mvm-bc build flow?
Thanks.

Hi @Voxar
For TypeScript, you should be able to create a global.d.ts file with the following:
declare function vmExport(id: number, handler: Function): void;
declare function vmImport(id: number): Function;

This just tells TSC that these functions exist, so you don't get type errors when accessing them.
Something else to be aware of is that Microvium doesn't support commonjs, so your tsconfig should probably have a modern target and module field, such as ES2023 or ESNext, to avoid tsc rewriting the module imports to common.js.
Just for reference, in a Microvium project where I used TypeScript, I had something like the following scripts in package.json:
  "scripts": {
    "build": "npm run build:typescript && npm run build:microvium",
    "build:typescript": "tsc",
    "build:microvium": "microvium build/ts-output/main.js --snapshot build/app.mvm-bc --output-disassembly build/app.map
  },

and my tsconfig.json had "outDir": "./build/ts-output"
Let me know how this goes. What's the project you're working on?


fix: typo spelling grammar

Please provide a description of this PR:
fix typo spelling grammar, replace the typo to correct words with reference from merriam-webster
To help us figure out who should review this PR, please put an X in all the areas that this PR affects.

[ ] Configuration Infrastructure
[x] Docs
[ ] Installation
[ ] Networking
[ ] Performance and Scalability
[ ] Policies and Telemetry
[ ] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure

Please check any characteristics that apply to this pull request.

[x] Does not have any user-facing changes. This may include CLI changes, API changes, behavior changes, performance improvements, etc.

Hi @slowy07. Thanks for your PR.
I'm waiting for a istio member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.
Once the patch is verified, the new status will be reflected by the ok-to-test label.
I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

/ok-to-test


Version Packages

This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.
Releases
<EMAIL_ADDRESS>Patch Changes

Updated dependencies [3bfb2877]:

<EMAIL_ADDRESS>

<EMAIL_ADDRESS>Patch Changes

#3498 3bfb2877 Thanks @acao! - Add typescript as a dependency for svelte2tsx

<EMAIL_ADDRESS>Patch Changes

#3498 3bfb2877 Thanks @acao! - Add typescript as a dependency for svelte2tsx

Updated dependencies [3bfb2877]:

<EMAIL_ADDRESS>

@acao Great job being so quick to add the typescript dependency! :) Seems to be version mismatch though

@Antonio-Bennett ah good catch. I need to stop trusting the copilot autocomplete for versions!


NeonService: Deploy health-check and ready-check programs as Linux binaries

We are currently deploying health-check and ready-check as scripts with a !/bin/sh, but this isn't working for Kubernetes exec based health probes.  This does work when we exec via: [ "sh", "/health-check" ].
The solution is to build these as little Linux executables, package these in Neon.Service as embedded resources and deploy that instead of scripts.

DONE


Ctrl-Shift-i not working in Google Chrome 45.0.2454.101 (64-bit)

Reason:
DockMonitor.prototype.handleKeyDown = function handleKeyDown(e) {
    if (!e.ctrlKey) {
      return;
    }
    e.preventDefault();

with commented e.preventDefault(); all works as expected

ah, and I see this on beta-3.

This appears to be fixed by https://github.com/gaearon/redux-devtools-dock-monitor/commit/1e6980ae181bb773b0d5451d5316ad1b011789ec on Oct 18.  When will v1.0.0-beta-4 be released ?

The fix is released in 1.0.1, requires DevTools 3.0 stable.


Ebpf fallback

Tested with success with kernel version 4.15

@andrekassis @eranra can you confirm that works for you ?

@safchain, @andrekassis is on this :-)

working;)

rerun skydive-functional-tests-backend-orientdb


No IntelliSense when import folder under the workspace.

Environment

Steps to Reproduce

Open folder in SE.
Add new python file in SE named WholsRunningMe.py
Add folder named TestMethod under current workspace
Add init.py file in Folder
Type code in init.py

def FOLDER1_MSG():
    print("hello world!")

Type code in WholsRunningMe.py

import TestMethod
TestMethod.FOLDER1_MSG()

Expected behavior
Make sure IntelliSense should show when import statement
Additional context and screenshots
No IntelliSense when import folder

The dropdown for import completions doesn't show up in general, not even for standard modules. However, once the import is typed, using the module works, and completions appear for its members.
It doesn't seem to matter whether it's a folder or a project, though. Imports just aren't there.

Likely caused by LSP protocol incompatibilities. It works in 17.3.0 Preview 3.0 [32607.526.main], where the LSP client is updated. Can you please re-check on that version?

I can reproduce it only with the following steps:

Ensure that employee.pyi doesn't exist.
Create employee.pyi.
Try triggering Intellisense.

With those, the module doesn't show up in import completions regardless of how near a match it is. However, if I close and reload the project, completions show up. Deleting .pyi and starting from the first step repros again.
Can you confirm whether this also holds true for your repro? Or does it happen independently of .pyi file presence?

I can repro it without .pyi file. After restart VS, i still got no IntelliSense

In today's build ,I can repro it when import folder outside the workspace

I still cannot reproduce. Is there anything special about the Python environment that is selected (even if it's global)?

@int19h

In today's build ,I can repro it when import folder outside the workspace

The Python environment is global default(install from VS)

Is PythonSettings.json (and specifically "SearchPaths") the same as on the earlier screenshot? Also, can you share the filesystem tree showing where the folder being imported is actually located relative to the opened folder, as well as any .py files inside the imported folder?

@int19h
PythonSettings.json (and specifically "SearchPaths") is the same as on the earlier screenshot
imported folder's location:

there is one "init.py" file in the imported folder

current workspace's location:

In today's build , the IntelliSense is missing after  restarting VS

On today's build

This issue is Still repro.


Support a meta property on baseQuery, enhance fetchBaseQuery to pass through Request/Response clones

Closes #194
Overview
This PR allows a baseQueryFn to return a meta property that will pass through to transformResponse, onSuccess, and onError. fetchBaseQuery has been modified to pass through clones of the Request/Response.
Possible use cases

A user could merge the Response headers into the result payload
A user could pass-through properties from the Request and/or Response to an analytics or logging service in onError/onSuccess

added a bit stuff on top of this :)

We should probably merge https://github.com/rtk-incubator/rtk-query/pull/158 before this, since that deduplicates the query & mutation thunk logic.

@phryneas Looks like I didn't break anything with the merge 🎉. Please just give it a once over :)

Let's get this merged :)


Do not write violation on missing url

A missing URL in Kio is not a reason for a violation.

@harti2006 same with ApplicationMasterDataPlugin?


update expected mysql and php versions so tests are passed

When running the tests as described in the readme, I ended up with newer versions for both mysql and php, which failed the test. I adjusted the tests and the readme accordingly. Tests are then passed succesfully again.

Hi @freakpants, this PR is no longer needed due to the merging of #123 but I would like too thank you for your contribution :)
Thanks,
Matt


Submit in modal footer need margin-bottom: 0px

When using submit in we should add margin-bottom: 0px as you can see in this image

this code should be enought to correct it:
.modal-footer input[type="submit"] {
margin-bottom: 0px;
}

Got it—resolved. I just nuked the bottom margin on all .btn instances within the .modal-footer.
Thanks!


custom elemement doesn't exist

HA version - 2023.7.2
i have tried to install and reinstall integration.

+1
The same.

The same

https://github.com/AlexxIT/WebRTC/issues/260#issuecomment-1643524820


[Question][HELM Chart] Not able to deploy via Traefik in Kubernetes

Question
Is there any specific configurations to be done when deploying the HELM using Traefik Ingress class in Kubernetes ?
Screenshots
If applicable, add screenshots to help explain.
Additional context
I use v0.19.0-beta6
I get 504 Gateway Timeout with the below configuration, UI Pod is running fine and I get HTML document when I exec curl inside the pod, there seems to be an issue between Ingress and Service.
Could someone please assist here ?
Below is my ingress configuration,
ingress:
  enabled: true
  enableHttps: false
  # Set to false if you want to use a different ingress controller
  useDefaultNginx: false
  # ingress class name, example: alb for AWS load balancer controller
  className:
    # domain name for hosting devlake, must be set if ingress is enabled
  hostname: mydomain.com
  # annotations required for your ingress controller; see the examples below
  # for nginx, use the first two lines of annotations
  # for alb (w/ external-dns), use the last 5 (6) lines of annotations
  annotations:
    kubernetes.io/ingress.class: traefik
    traefik.ingress.kubernetes.io/router.tls: "true"
    # {}
    # kubernetes.io/ingress.class: nginx
    # kubernetes.io/tls-acme: "true"
    #
    # alb.ingress.kubernetes.io/actions.ssl-redirect: '{"Type": "redirect", "RedirectConfig": { "Protocol": "HTTPS", "Port": "443", "StatusCode": "HTTP_301"}}'
    # alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:us-east-2:xxx:certificate/xxx-xxx-xxx
    # alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS":443}, {"HTTP":80}]'
    # alb.ingress.kubernetes.io/scheme: internet-facing
    # alb.ingress.kubernetes.io/target-type: ip
    # external-dns.alpha.kubernetes.io/hostname: www.example.com

  # url prefix, not works right now, keep "/"
  prefix: /
  # if using https provides the certificates secret name
  tlsSecretName: ""
  # ingress http port
  httpPort: 80
  # ingress https port
  httpsPort: 443

hi @ChintanPania, what error is it?

@ZhangNing10 504 Gateway Timeout Error (seems to come from Service), the request goes to Ingress (Traefik) but service does not forward to the Pod.

@ChintanPania do you use 443 port or 80 port to access? and is traefik behind some load balancer? can i have a look at your traefik values？

@ZhangNing10, we have a load balancer, and below is the service info of the traefik
kind: Service
apiVersion: v1
metadata:
  name: traefikv2
  namespace: ingress
  uid: a615a59e-a883-4c99-8510-5455b8254604
  resourceVersion: '34898376'
  creationTimestamp: '2023-05-22T04:55:12Z'
  labels:
    app.kubernetes.io/instance: traefikv2
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/name: traefikv2
    helm.sh/chart: traefikv2-10.3.6
  annotations:
    loadbalancer.openstack.org/load-balancer-address: xx.xxx.xxx.xxx
    loadbalancer.openstack.org/load-balancer-id: 5b4de1fd-5d96-4483-8514-bf08a94fc979
    meta.helm.sh/release-name: traefikv2
    meta.helm.sh/release-namespace: ingress
  finalizers:
    - service.kubernetes.io/load-balancer-cleanup
  managedFields:
    - manager: helm
      operation: Update
      apiVersion: v1
      time: '2023-05-22T04:55:11Z'
      fieldsType: FieldsV1
      fieldsV1:
        f:metadata:
          f:annotations:
            .: {}
            f:meta.helm.sh/release-name: {}
            f:meta.helm.sh/release-namespace: {}
          f:labels:
            .: {}
            f:app.kubernetes.io/instance: {}
            f:app.kubernetes.io/managed-by: {}
            f:app.kubernetes.io/name: {}
            f:helm.sh/chart: {}
        f:spec:
          f:allocateLoadBalancerNodePorts: {}
          f:externalTrafficPolicy: {}
          f:internalTrafficPolicy: {}
          f:ports:
            .: {}
            k:{"port":80,"protocol":"TCP"}:
              .: {}
              f:name: {}
              f:port: {}
              f:protocol: {}
              f:targetPort: {}
            k:{"port":443,"protocol":"TCP"}:
              .: {}
              f:name: {}
              f:port: {}
              f:protocol: {}
              f:targetPort: {}
          f:selector: {}
          f:sessionAffinity: {}
          f:type: {}
    - manager: openstack-cloud-controller-manager
      operation: Update
      apiVersion: v1
      time: '2023-05-22T04:55:45Z'
      fieldsType: FieldsV1
      fieldsV1:
        f:metadata:
          f:finalizers:
            .: {}
            v:"service.kubernetes.io/load-balancer-cleanup": {}
        f:status:
          f:loadBalancer:
            f:ingress: {}
      subresource: status
    - manager: openstack-cloud-controller-manager
      operation: Update
      apiVersion: v1
      time: '2023-09-15T09:51:58Z'
      fieldsType: FieldsV1
      fieldsV1:
        f:metadata:
          f:annotations:
            f:loadbalancer.openstack.org/load-balancer-address: {}
            f:loadbalancer.openstack.org/load-balancer-id: {}
spec:
  ports:
    - name: web
      protocol: TCP
      port: 80
      targetPort: web
      nodePort: 33080
    - name: websecure
      protocol: TCP
      port: 443
      targetPort: websecure
      nodePort: 35998
  selector:
    app.kubernetes.io/instance: traefikv2
    app.kubernetes.io/name: traefikv2
  clusterIP: xxx.xxx.xx.xxx
  clusterIPs:
    - xxx.xxx.xx.xxx
  type: LoadBalancer
  sessionAffinity: None
  externalTrafficPolicy: Cluster
  ipFamilies:
    - IPv4
  ipFamilyPolicy: SingleStack
  allocateLoadBalancerNodePorts: true
  internalTrafficPolicy: Cluster
status:
  loadBalancer:
    ingress:
      - ip: xx.xxx.xxx.xxx

so you use 443 to access devlake, and the listener 443 of aws lb has a target group to websecure node port 35998? if so, could you use the web port as 443 to have a try?

@ZhangNing10 I was able to load the devlake-config-ui by adding some network policy.
But somehow the UI is not able to connect to /api/ping and /api/userinfo endpoints, I get 404 in the browser and below is the snapshot for the same.

could you please suggest what is the issue here ?


I have added "current enrollment date"

It will help reader because when i gone through this i didn't knew that think but if reader will read with current enrollment date then he realises what he actually want to upload

Why:

What's being changed:

Check off the following:

[ ] All of the tests are passing.
[ ] I have reviewed my changes in staging. (look for the deploy-to-heroku link in your pull request, then click View deployment)
[ ] For content changes, I have reviewed the localization checklist
[ ] For content changes, I have reviewed the Content style guide for GitHub Docs.

👍 The application is explicit about the enrollment date requirement so it makes sense that the help article should be, too. Good suggestion!

@sejalrane777
I have added "current enrollment date" …
315913a
It will help reader because when i gone through this i didn't knew that think but if reader will read with current enrollment date then he realises what he actually want to upload

👋 @sejalrane777 While we were frozen for GitHub Universe, I think this article was renamed and your pull request now has conflicts. Would you mind making this same change on the new article: https://docs.github.com/en/free-pro-team@latest/education/teach-and-learn-with-github-education/apply-for-a-student-developer-pack#applying-for-a-github-student-developer-pack
Thank you so much for contributing and I'm sorry about the timing of the rename 💛

👋 @sejalrane777 While we were frozen for GitHub Universe, I think this article was renamed and your pull request now has conflicts. Would you mind making this same change on the new article: https://docs.github.com/en/free-pro-team@latest/education/teach-and-learn-with-github-education/apply-for-a-student-developer-pack#applying-for-a-github-student-developer-pack
Thank you so much for contributing and I'm sorry about the timing of the rename 💛

👋 @sejalrane777 While we were frozen for GitHub Universe, I think this article was renamed and your pull request now has conflicts. Would you mind making this same change on the new article: https://docs.github.com/en/free-pro-team@latest/education/teach-and-learn-with-github-education/apply-for-a-student-developer-pack#applying-for-a-github-student-developer-pack
Thank you so much for contributing and I'm sorry about the timing of the rename 💛

Done👍 . I make changes on new article.

Thank you! I'm closing this PR out in favor of the updated https://github.com/github/docs/pull/2103 ✨


Jobs no longer register from git repositories when structured as a submodule in 2.2.3+

Environment

Nautobot version (Docker tag too if applicable): v2.2.3+ (Worked in v2.2.2)
Python version: 3.11.9
Database platform, version: Postgres 13
Middleware(s):

Steps to Reproduce

Add Git Repository to nautobot that is structured as a jobs submodule

.
|-- README.md
`-- jobs
    |-- __init__.py
    `-- intended_state.py

Run sync
Observe warning

Expected Behavior
Expected the intended_state job to be added.

Observed Behavior
No jobs were registered on loading the intended_state.jobs submodule. Did you miss a register_jobs() call? Or was there a syntax error or similar in your code?

Can you confirm this is not working in v2.2.8? It's possible that this was fixed by #5828 which was released in v2.2.6. I was able to import this repo in my local dev instance and the jobs were loaded. I took a look at the module loading code and it looks like we still support this directory structure.

The reported issue is still not working in v2.2.8.  The repo you shared has an additional __init__.py in the root of the repository.  If I add the same to my repository, then it works too.  (shown below)
.
|-- README.md
 -- __init__.py  <- adding additional one here works
`-- jobs
    |-- __init__.py
    `-- intended_state.py

I went and double checked the documentation for v2.2.8 and I do not see the requirement of the additional __init__.py mentioned. (And this appears to have changed in v2.2.3+)  There is a note to make sure you include one in your jobs dir, but not the repository's root.

Thanks for looking into that. Looks like we need to update the documentation to show that the __init__.py is required at the root of the git repo.

It's also worth to mention that this was a breaking change in v2.2.3 that was not listed.  Not sure how to address that.
I can submit a PR to update the documentation.  Do you have any insight on why the additional __init__.py is needed now?

Unintended side consequence of the broader Job loading changes made in #5586. Sorry for the trouble.

Thank you @glennmatthews!  Just to confirm though, I still need to update the documentation because it's required going forward?

Yes, I don't think we'll be able to roll that part back so a docs update would be valuable.

I was able to find the requirement listed in the documentation.  Interestingly, this was not a requirement at the time it was added to the documentation.  However, we should be covered here, so closing issue.
https://github.com/nautobot/nautobot/blob/206a31d10bb23f1cafdf458aa8a0bf135681ed9b/nautobot/docs/development/jobs/index.md#L24-L26

@tsm1th I don't feel like that is adequate documentation. The tree diagram you created above would be a great visual to include to make it as clear as possible.

That works for me.  Anywhere special you would like to see that?

Split out Git Repositories from this  section and add it under there?

@alhogan - Do you think this will suffice?


Query-Multiple tables

For the third milestone of the Vet Clinic database project, I
Created a table named owners with columns id, full_name, and age
Created a table named species with columns id and name
Modified the animal table
Removed column species
Added column species_id which is a foreign key referencing the species table
Added column owner_id which is a foreign key referencing the owners table
Inserted the given data into the owners table
Inserted the given data into the species table
Altered the animal table with the given data
Modified the inserted animals to include values of species_id and owners_id
Performed queries using JOIN

Here are answers with screenshots
What animals belong to Melody Pond?

List of all animals that are pokemon (their type is Pokemon).

List all owners and their animals, remember to include those that don't own any animal.

How many animals are there per species?

List all Digimon owned by Jennifer Orwell.

List all animals owned by Dean Winchester that haven't tried to escape.

Who owns the most animals?

According to the feedback, I have implemented the required changes .


Options rendered unaligned with dropdown

Getting a strange behavior when using 0.0.6. The options are rendered with quite an offset. Looks like this when running the example code from the readme:

@Pungsnigel
Hi, this is a know issue on Android. And still we couldn;t resolve it ..

No idea how to fix?

Nops. I will give it a try on weekend though.
On Jan 7, 2016 7:01 PM, "Jesper Persson"<EMAIL_ADDRESS>wrote:

No idea how to fix?
—
Reply to this email directly or view it on GitHub
https://github.com/alinz/react-native-dropdown/issues/22#issuecomment-169664789
.

Great, thanks. Let me know if I can help out.

Sure. As you are using on Android if you can figure anyways to fix it
please send pr. I will merge it .
Thanks
On Jan 7, 2016 7:03 PM, "Jesper Persson"<EMAIL_ADDRESS>wrote:

Great, thanks. Let me know if I can help out.
—
Reply to this email directly or view it on GitHub
https://github.com/alinz/react-native-dropdown/issues/22#issuecomment-169665432
.

Having this exact same problem, is this fixed yet @gs-akhan ?

I found it renderered in the correct position if I took away the styles for the  container that contains the dropdown in the example code.
Remove alignItems style and justifyContent. One of those must be responsible for this bug.

Problem solved after removing 'justifyContent: 'center', alignItems: 'center' ' but now how can we align the component. I need it in center of screen.

You can wrap the select component in a View like this:
 <View style={{flex: 1, justifyContent: 'center', alignSelf: 'center'}}>


Arduino-compatible library for xioAPI

As I've been working on integrating the xioAPI onto my custom board, I have forked a repository from Reefwing. But their library is limited and relies on their common hardware libraries.
I'd like to develop a general library that can be deployed onto Arduino-compatible microcontrollers. Would it be possible for you to release the files you use for the x-IMU3 and its API implementation? Else, help me develop a generalized library. My current effort can be found in the ThetisAPI repo.
My end goal is to develop a package that can be downloaded onto Arduinos with IMUs and be instantly compatible with the x-IMU GUI.

Thank you for the suggestion and your initial work towards this goal.  I look forward to discussing this further in our scheduled call.


corrupted size vs. prev_size with Nvidia 495+ and DXVK 1.9.3+

Star Citizen works very well with DXVK, except is some precise situations.
If using Nvidia 470.x, it works with basically any version of DXVK.
With Nvidia 495.x, it doesn't work with any DXVK.
With Nvidia 510.x if works with DXVK 1.9.2 and prior. But not with DXVK 1.9.3+.
Only one line seems relevant in the log attached : corrupted size vs. prev_size
We tried every game or Wine setting with the LUG with no difference except for one :
When changing __GL_THREADED_OPTIMIZATIONS to 0 the error line changes to : malloc(): invalid next size (unsorted)
We are not sure if these error messages are related or two completely different errors.
Software information
Star Citizen.
System information

GPU: RTX 2070
Driver: 510.47.03
Wine version: 7.1
DXVK version: 1.9.3+

log SC.txt

I'm not seeing any DXVK messges in that log, did you disable logging or does it crash before even calling into any of our code? Are you using the native Vulkan renderer perhaps (if that's even a thing yet)?
This sounds like an extremely painful issue since Star Citizen is not something I can test locally, and even if I could, this sounds like some sort of memory corruption that bleeds into the Linux side or happens within the Nvidia driver itself, and problems like that are exceptionally hard to debug. This could be caused by literally anything as well, including the driver, the game itself, or DXVK.
Couple of things you can do:

try to run the game with Vulkan validation layers enabled and post a full log, to see if we're doing anything obviously wrong
try to bisect the issue on 510.x to see which change between 1.9.2 and 1.9.3 broke it on these drivers

Would also be interesting if the game still works on AMD drivers.

I'm not seeing any DXVK messges in that log, did you disable logging or does it crash before even calling into any of our code? Are you using the native Vulkan renderer perhaps (if that's even a thing yet)?

No it's not a thing yet and no logging isn't disabled.

Couple of things you can do:

try to bisect the issue on 510.x to see which change between 1.9.2 and 1.9.3 broke it on these drivers

Someone in the LUG did it and says that this commit is the culprit : https://github.com/doitsujin/dxvk/commit/86148ec070628f5a89fbb0a91603bae2ce89529a

try to run the game through Valgrind and see if it complains about buffer overflows etc

I'm lacking time but I'll try to find a moment to do it.

Would also be interesting if the game still works on AMD drivers.
Yes it does. And yes we think that the NV driver isn't innocent there. But we also think that DXVK does something
specific to NV cards that triggers this crash (see the commit potentially responsible).

The code that was added quite literally doesn't do anything except enable some Vulkan extensions, it doesn't change DXVK's behaviour in any way at all as long as DLSS is not used.
Does https://github.com/doitsujin/dxvk/tree/sc-test help?

Yes, it fixes it. I'm at 5/5 successful launches (A Hat in Time).

Commenting just the devExtensions.nvxBinaryImport.setMode(DxvkExtMode::Optional); in the if (enableCudaInterop) block also works.

The code that was added quite literally doesn't do anything except enable some Vulkan extensions, it doesn't change DXVK's behaviour in any way at all as long as DLSS is not used.

Our thought is that the commit might do something that uncovers a Nvidia driver bug.

Yeah, but the point that I don't quite get is... why the heck does this only happen in specific games that don't even use DLSS?

Yeah, it seems a bit strange. I looked up what nvxBinaryImport is, and it looks like it's a Vulkan extension that "allows applications to import CuBIN binaries and execute them."
strings HatinTimeGame.exe | grep -i cuda has one result, ?enableCudaAcceleration@Compressor@nvtt@@QEAAX_N@Z. That might be a clue? I don't have other crashing games to look at though.

Is it possible for me to manually apply this fix to Proton, before it gets merged?
I'm running into the same A Hat in Time crashes with Proton Experimental, and running AHiT with this fix applied seems to fix the crash, though with no Steam features (since I'm not launching through Steam to test it).

@RealTheSunCat yeah, if you build Proton from source you can comment out that line in the DXVK submodule and make install it to Steam, that's what I'm doing. You can also compile just DXVK with the fix and overwrite Proton Experimental's DXVK files with the output, but then Steam's gonna replace those files every time it checks them since they're modified.

@doitsujin would you accept a PR to put disabling that behind an environment variable? It's clearly misbehavior on the GPU side, but it would be nice to enable people who aren't capable of manually building dxvk to use more recent versions again.
I'm also assuming someone has flagged this to nvidia by now?

I have been maintaining a DXVK build with the workaround on my fork that has been working for the Star Citizen LUG for some time now, if that might be interesting to anyone here.

Could any of you recheck on the newly released 520.56.06 Nvidia driver?

@Blisto91 Just tested it with Star Citizen.
Unfortunately still the same problem with 520.56.06 (non-open version) and a RTX3060 by using dxvk v1.10.3.

have same problem with Star Citizen.
work with <= dxvk-1.9.2
RTX3080
Driver Version: 520.56.06

Yes a driver fix from Nvidia is needed afaik.

FWIW, can confirm that this issue is still affecting 525.60.11 (RTX 3060 Ti).
At least for AHIT, I made a semi-custom Proton version that uses symlinked files from whatever the latest Proton-GE version is (using Arch AUR's proton-ge-custom-bin package as my GE install), just with the relevant DXVK files replaced from @gnusenpai's fork, and the game boots consistently.

Have there any news about this? Currently facing the same issue with Watch Dogs 2. I tried to downgrade DXVK to 1.9.2, but it is still happening. Do I need to downgrade NVIDIA driver too?

@TheBill2001 Not yet besides that Nvidia devs are notified of the issue.

535 drivers have reached stable. Not every fix usually makes it to the release notes, so might be worth a try.

Gonna knock on wood as I say this, but I think this might be resolved in the current drivers?
Using 535.86.05, and tested with both Proton-GE and Experimental; launched it like eight consecutive times and it seems to consistently launch. But I can only say this with regards to A Hat In Time for now. Someone else advise for Star Citizen if they can?

Thanks for reporting this. Though I can't test Star Citizen, A Hat in Time indeed works fine for me too now

@Loacoon1 are you able to give this a spin in Star Citizen with the latest Nvidia drivers? 🙂

@Loacoon1 Friendly ping


Build error on android, RN 0.45.1

Hey there,
When trying to run on android we get:
ReactNativeContacts is not abstract and does not override abstract method createJSModules() in ReactPackage during build.
We use react-native 0.45.1.
Works great on iOS.

v0.9 was a breaking change it seems. I'll promote it to v1.0 as many people are reporting breakage.
To fix pin your module to v0.8 or upgrade your project to RN 0.47+
See https://github.com/rt2zz/react-native-contacts/pull/205

error: ReactNativeContacts is not abstract and does not override abstract method createJSModules() in ReactPackagepublic class ReactNativeContacts implements ReactPackage {^1 error:react-native-contacts:compileReleaseJavaWithJavac FAILED
Got this module working by adding the following to ReactNativeContacts.java.
import com.facebook.react.bridge.JavaScriptModule;
@override public List<Class<? extends JavaScriptModule>> createJSModules() { return Collections.emptyList(); }


Block all unknown urls in RSpec when using a js driver.

upgrade capybara-webkit to ~> 1.5 as page.driver.block_unknown_urls
was introduced in 1.4

Successfully used in our latest projects.

:+1:

:+1:


There is a bug in option() method of eg.Component at version 1.0.0

Nowhere do not initialize the this.options member variable.
So, a reference error occurs when I call.
// define my component
var MyComponent = eg.Class.extend(eg.Component,{
  construct : function(ht){
    this.option(ht);
  }
});

// create instance
new MyComponent({nIndex : 0}); // error occurs. 'Uncaught TypeError: Cannot set property 'nIndex' of undefined'

Thank you @hiuny

We don't initialize this.options property.
if you can do this, I wish you contribute this issue.  thank you.


Basic Frontend

Convert the chicken coop into a basic SPoG frontend:

[x] Browse packages
[x] Browse vulnerabilities
[x] Scan user provided SBOM

I think we can close this. We are actually in the process of polishing what we have. So I guess we are beyond "basic" already.


IPROTO-392 Remove @private javadoc from generated sources

https://issues.redhat.com/browse/IPROTO-392

Thanks @tristantarrant

Solves https://github.com/infinispan/protostream/issues/327


Migrate Giant Swarm workload clusters to Cluster API for AWS

User Story
- As a user, I want to reconcile existing Giant Swarm clusters with Cluster API for AWS controllers clusters instead of the Giant Swarm controllers so that I can leverage the flexibility and extra features available in Cluster API.
Details, Background
It's very important to have a migration path for the existing Giant Swarm clusters to Cluster API in order not to force a disruptive move for our customers.
The migration risk can be minimized by identifying the differences between existing Giant Swarm clusters and Cluster API clusters as soon as possible.
Blocked by / depends on
None

Duplicate of https://github.com/giantswarm/roadmap/issues/1787 .


Clarify imports

Specify what is imported from each module to easier locate the source of a function.

Telomare modules now have explicit imports.


lost refresh capability

there no longer seems to be a link to refresh the dataset.
Please can this be provided again?

You have a miliestone filter applied that is showing you only the issues from phase 3. On the left hand side, there are filter options, and you can disable the milestone filter.


DLLNotFoundException

Hello there. I know there is an issue in #5, but mine seems to be slightly different.
I had this error:
Failed to load 'Assets/PocketSphinx/Lib/win64/libpocketsphinxwrap.dll', expected x64 architecture, but was Unknown architecture. You must recompile your plugin for x64 architecture.
VoiceInputHandler:SetupDecoder() (at Assets/Scripts/VoiceInputHandler.cs:75)
<Start>d__6:MoveNext() (at Assets/Scripts/VoiceInputHandler.cs:23)
UnityEngine.SetupCoroutine:InvokeMoveNext(IEnumerator, IntPtr)

and
DllNotFoundException: libpocketsphinxwrap
Pocketsphinx.pocketsphinxPINVOKE+SWIGExceptionHelper..cctor () (at Assets/PocketSphinx/pocketsphinxPINVOKE.cs:107)
Rethrow as TypeInitializationException: The type initializer for 'SWIGExceptionHelper' threw an exception.
Pocketsphinx.pocketsphinxPINVOKE..cctor () (at Assets/PocketSphinx/pocketsphinxPINVOKE.cs:127)
Rethrow as TypeInitializationException: The type initializer for 'Pocketsphinx.pocketsphinxPINVOKE' threw an exception.
Pocketsphinx.Decoder.DefaultConfig () (at Assets/PocketSphinx/Decoder.cs:83)
VoiceInputHandler.SetupDecoder () (at Assets/Scripts/VoiceInputHandler.cs:75)
VoiceInputHandler+<Start>d__6.MoveNext () (at Assets/Scripts/VoiceInputHandler.cs:23)
UnityEngine.SetupCoroutine.InvokeMoveNext (System.Collections.IEnumerator enumerator, System.IntPtr returnValueAddress) (at C:/buildslave/unity/build/Runtime/Export/Scripting/Coroutines.cs:17)

which seems similar to #5, but different. It seems to be related to x64 architecture this time.
I searched online and found a seem-to-be solution, like this where I do
In the Unity Editor, select your dll file and then in the Inspector>Platform settings, choose x86 for CPU.

The message should go away now.

but the same error keeps popping up. Do you happen to know any way I can fix this?
Thank you.

What is your platform?

Sorry for missing the important information, here is the system info I found for my computer:
Windows 10 Home edition

Manufacturer: ASUSTek Computer Inc

Processor: Intel(R) Core(TM) i9-8950HK CPU @ 2.90GHz 2.90 GHz

Installed memory (RAM): 16.0 GB (15.9GB usable)

System type: 64-bit Operating System, x64-based processor

Have you tried to install MSVCR110.dll?

I apologize for jumping on this thread a bit late. But the first thing to try would be what @jin-archipin suggested. Let us know if downloading that DLL helps.

Is this still an issue? Please re-open if you continue to have trouble with this.

Is this still an issue? Please re-open if you continue to have trouble with this.

Where should I put MSVCR110.dll after downloading it?


Update uuid-creator to 4.2.1

Updates com.github.f4b6a3:uuid-creator from 4.2.0 to 4.2.1.
Changelog
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "com.github.f4b6a3", artifactId = "uuid-creator" } ]

labels: library-update, early-semver-patch, semver-spec-patch

Codecov Report

Merging #229 (bb9a4ba) into main (17ff3c5) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #229   +/-   ##
=======================================
  Coverage   88.85%   88.85%
=======================================
  Files          91       91
  Lines        2772     2772
  Branches       70       70
=======================================
  Hits         2463     2463
  Misses        309      309

Continue to review full report at Codecov.

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


Homepage updated design #131

Initial pass at new homepage layout/structure, ran under local Jekyll with MM to test
#131

@jenniferthibault Do you want to review?  It wouldn't let me add you as a reviewer, since you don't appear to be in the OpenMaine org.  I sent you an invite to join the org.

@curtisk This is great!  I'm thinking we should probably add links to the absentee ballot request form and municipal clerk's office listings from the homepage.  Links are on the live site right now: https://maineballot.org/

Since we don't have preview links, this is what the homepage looks like.

And the How to Vote in Maine page.

We also need to figure out where to put credit for the icons.  We do have an image credits section in the ReadMe that I used for one image that required credit.

@curtisk good idea!

adding "About" page, nav, footer pruning and links to "vote by mail" and "early voting" areas

@curtisk I can tell you made changes from the change log, but when I pull the branch they're not showing up locally.  Any idea why?

are you pulling/fetching from the branch or from master?

From the branch.

@curtisk It's acting strangely.  It's not giving me the ability to fetch and only the ability to publish.

not sure why its doing that, is that the github for desktop? Its a pull request with two commits in it...hmmm

I'll just merge it and review it in production.

@curtisk The images broke when I merged.

The About page and footer look good.

It looks like it stripped all the styling.

only thing missing are the two new images on homepage, even though they are in merge..... ?

so, it looks like the github hosted server is case sensitive..../assets/img/other versus /assets/img/Other

The blue background was missing, as well, but it appears to be there now.

So it is just the homepage images that are missing now.  It must have just taken a bit for the rest of the styling to catch up.


feat: 🎸 Adds a getKeyPressData function will

Adds a util function that consumes a native keydown, keyup or keypress event and returns information about the cornerstone element and the position of the mouse cursor. Useful for "do something to this hovered annotation" functions at the app level.
element.addEventListener('keydown', (evt) => {
  console.log(cornerstoneTools.importInternal('util/getKeyPressData')(evt))
});

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Player 3.0 plays better than 3.1 but its notes are out of sync for a period (about 30 seconds for me) after loadPlugin completes

After replacing Player.js 0.3 with 0.3.1, the player loads a midi file right away and in sync, but there are more audio cuts/clicks.
Player.js 0.3 audio sounds better than 0.3.1, but is out of sync for the first 30 seconds.
Could this be a compatibility issue between other files? Please let me know if you need anything else posted.
Thanks,

may have just been an overload


Merge pull request #1 from akshaykarnawat/master

initial commit -- merge to github pages

merged with latest master


Fix data/presets/amenity/ticket_validator format

data/presets/amenity/ticket_validator is not valid JSON, with trailing commas and a dangling curly bracket. This PR fixes these issues.

Thanks! FYI: The file was also missing the .json file ending (see 7efb634), that's why the tests didn't catch the issues.

Thanks to you and other for this fantastic work.
I found these errors because I have a tool that processes the schema. Besides the errors fixed by the PR, my tool also choked up on emergency/water_reservoir, which has the same tags as emergency/water_tank. In fact, the tags are different in their respective preset files, i.e. data/presets/emergency/water_reservoir.json:
    {
        "emergency": "water_tank",
        "natural": "water",
        "water": "reservoir"
    }

and data/presets/emergency/water_tank.json;
    {
        "emergency": "water_tank",
        "landuse": "reservoir"
    }

but they are the same in dist/presets.json (which my tool uses), both being the latter two-key tags.  Is dist/presets.json out of date or is there a weird bug somewhere that sets the wrong tags for emergency/water_reservoir (or am I misunderstanding something)? Thanks in advance.


Wrong notification after changing email address

After confirming the change of my email address (in the email I get) I get the notification "Your account was successfully confirmed. Please sign in." But I am already signed in. I should get the same notification when I change my password.

After you have changed your eail adress ->

After you clicked in the link in the confirmation email.

We use the confirmation controller for the changing of the email address. We could change that behavior and use another controller or another method in controller for that.