Why do the docs say that terminals have to be upper case but when I have lowercase terminals I have not issues?

Describe the bug
I recently had a bug where the parser told me that my terminals were recrusive (detected by the use of uppercase).
'''
lark.exceptions.GrammarError: Recursion in terminal 'LAMBDA_EXP' (recursion is only allowed in rules, not terminals)
'''
But when I removed the recursion and changed the name to a lower case I got not bug. Isn't this a bug?
To Reproduce
Initial grammar with bug:
LAMBDA_EXP : IDENT
    | "λ" IDENT ":" SIMPLE_TYPE "." LAMBDA_EXP
    | LAMBDA_EXP LAMBDA_EXP
    // | "(" LAMBDA_EXP LAMBDA_EXP ")"

SIMPLE_TYPE : IDENT
    | SIMPLE_TYPE "→" SIMPLE_TYPE  // "→"

IDENT : /[A-Za-z0-9_]+/

%import common.WS
%ignore WS

// %import common.ESCAPED_STRING
// %import common.SIGNED_NUMBER

corrected grammar with no bug (but I believe it should be throwing a bug due incorrect use of lowercase):
term : ident
    | "λ" ident ":" type "." term
    | term term
    // | "(" term term ")"

type : ident
    | type "→" type  // "→"

ident : /[A-Za-z0-9_]+/

%import common.WS
%ignore WS

// %import common.ESCAPED_STRING
// %import common.SIGNED_NUMBER

Why would that be incorrect use?

Why would that be incorrect use?

because the docs say that terminals are uppercased. So when I do a non-terminal with a upper case I get recursion errors. But it seems inconsistent to not throw me errors when my terminals are lower case.
I am just basing what I read https://lark-parser.readthedocs.io/en/latest/grammar.html and the docs. I am fine with letting the user define rules terminals with whatever case we want and then having lark detect terminals automatically by seeing if they point to a constant or regex etc.

But if you write them lowercase, they aren't terminals. The case defines if they are terminals or non terminals.
You can btw. make IDENT a Terminal without any problems.

When you write
ident : /[A-Za-z0-9_]+/

You define a rule called ident, which matches one anonymous terminal, in this case a regexp.
Most terminal definitions can be turned into rules and still work the same way. But that's not always the case! Also, the resulting tree will look different.


Getting session expired error

Hi,
Request token validity is for 5 min and it can only be used only once. So once you get access token store it and use the same, don't call requestAccessToken() every time you run the app.

I didn't get any token from response, Kindly check from your end.

@eswaran88,
It is mandatory by the exchange that a user has to log in manually at least once a day.
You need to login on browser, after successful login, you will get request token


Fix memory card

#336

@huan I trined a new way to handle async test this time, is this kinda async/await style you mentioned?

is this kinda async/await style you mentioned?

No, it's not the async/await style. It's still the callback style. ;-p

after await puppet.start(), puppet.stop() will be called, does this affect puppet's state?

start/stop of course will affect the state.
What's the state in your context?

I mean if I wrote
puppet.on('scan', () => {puppet.stop()}
await puppet.start()
t.ok((puppet.memory as any).payload !== undefined, 'memory is loaded')

will this puppet.memory.payload effected by puppet.stop()>

I'm not sure about it.
My suggestion would be just write an unit test to confirm the behavior and make sure it's your expected.


Bower support

Could you make this a bower component?
Thanks.

Does a simple bower install przno/double-scroll-bars not work for you?


nixosTests.prosody*: port to python

Motivation for this change
#72828
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS

[x] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[x] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

@GrahamcOfBorg test prosody prosodyMysql


AddProject XML docs improvements.

Bulking out the XML docs with some more background.
Microsoft Reviewers: Open in CodeFlow

Note this PR sneaks in a subtle API breaking change. I found the WithReplicas method for executable resources on the wrong extension method. It's a source compatible change though.

It is a source breaking change if someone was calling ProjectResourceBuilderExtensions.WithReplicas(IResourceBuilder<ExecutableResource> builder, int replicas) rather than using as an extension method?
But, that's a we should do it now rather than later.

Thats right. The method is clearly in the wrong place. I can't do an obsolete because it would be ambiguous.

/backport to release/8.0


WIP: Derivatives interface

Hi all -- here's a first attempt at moving some of the derivative code from https://github.com/oxfordcontrol/osqpth/ and into here. What do you think of this interface?
If it's good I can also start adding:

[ ] The same interface to modulepurepy
[ ] The full differentiation mode, following https://github.com/oxfordcontrol/osqpth/pull/5 but with slacks too
[x] Backward derivatives
[ ] Forward derivatives
[ ] Derivative tests (for now just with backward derivatives)
[ ] Batch loops and multithreaded

Two other things:

Something that may be worth adding to diff_mode is the linear system solver type too (direct/LSQR/sparse/dense)
This follows the interface of https://github.com/cvxgrp/diffcp/blob/master/diffcp/cone_program.py -- do you also want to stub in a derivative function here too?

\cc @sbarratt @akshayka

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

This is great thanks! Just a couple of comments/suggestions:

I would focus on the sparse version first since the solver is anyway sparse. Then we can work out the dense version after we have the sparse one running.

I totally agree with having a direct solver (QR decomposition) and indirect solver (LSQR). I am not sure LSQR always works for badly conditioned systems. By the way, if we end up using the functions from the internal C code we will benefit from the problem data scaling in OSQP. This should help the LSQR convergence.

What do you think about having the same solve function for osqp and then adding some boolean option to compute the derivatives? I mean something like derivative=True. This would be more coherent with the current osqp interface when we pass the polish=True to perform the final polish step at the end of the ADMM algorithm.

I totally agree with having a direct solver (QR decomposition) and indirect solver (LSQR). I am not sure LSQR always works for badly conditioned systems. By the way, if we end up using the functions from the internal C code we will benefit from the problem data scaling in OSQP. This should help the LSQR convergence.

How would you like to specify these modes? Maybe we can put the solver into diff_mode as full_qr, full_lsqr?

What do you think about having the same solve function for osqp and then adding some boolean option to compute the derivatives? I mean something like derivative=True. This would be more coherent with the current osqp interface when we pass the polish=True to perform the final polish step at the end of the ADMM algorithm.

Yes this sounds good too. How would you like the derivative functions to be returned? Maybe we could add derivative and adjoint_derivative fields to the OSQP_results struct that point to Python functions?

Maybe we could add derivative and adjoint_derivative fields to the OSQP_results struct that point to Python functions?

It may be easy to accidentally leak memory if we add pointers to Python functions in the struct where the Python functions keep data around

How would you like to specify these modes? Maybe we can put the solver into diff_mode as full_qr, full_lsqr?

Happy to use the parameter diff_mode. We could also just set it to qr and lsqr. The active-set mode could be a special feature we run only in debug (not very robust yet) as active_qr and active_lsqr.

Yes this sounds good too. How would you like the derivative functions to be returned? Maybe we could add derivative and adjoint_derivative fields to the OSQP_results struct that point to Python functions?

It may be easy to accidentally leak memory if we add pointers to Python functions in the struct where the Python functions keep data around

I think we need to discuss this a bit more. I would really like to have a solution that does not necessarily depend on Python function pointers. This would be enable the use of differentiable OSQP also in other languages. (e.g., Julia?)
Here is an idea that goes against what I suggested before (no derivative=True option anymore) but that could work.
We could have lower level functions in C called osqp_derivative and osqp_adjoint_derivative that take the workspace structure as input, check that the problem status is solved and compute the derivative. To start, these functions could be prototyped in Python and then ported to C later.
However, this approach would need the workspace to be stored somewhere in Python. At the moment it does not happen with the one-shot solve function disabling the GIL but it does happen in the standard way we call OSQP with the Python object. We can fix this by using the OSQP object methods instead of the one-shot solve and by disabling the GIL (making them thread unsafe).

I have started creating the differentiable interface from Python. It works from the object interface  now. In particular, I have

Released GIL on OSQP object functions
Removed OSQP one-shot solve function (useless now and repeats code)
Added test for 'qr_active' differentiation mode
Dropped Python 2 support (next release will not support it)

The tests are now using numdifftools but I would prefer not to install additional packages. Let me know what you think.

I have implemented the backward derivative also with the lsqr method. All the tests pass except dA.
It is weird because the derivative does not match the numerically estimated one, but we get the same output for both lu_active or lsqr method. Probably there is an issue either in the math or in the numerical estimation.

The tests are now using numdifftools but I would prefer not to install additional packages. Let me know what you think.

Could we use check_grad? (https://docs.scipy.org/doc/scipy/reference/generated/scipy.optimize.check_grad.html)
This is part of scipy, so should already be included.

I double checked and the math seems right. Here's a write-up.
diff_osqp.pdf

Tests should be working now (at least from my machine) for all the adjoint derivatives. I ended up using approx_fprime from scipy and tuning its precision accordingly.
I think we should add the forward derivative and the multithreaded code from this interface directly (just as it happens for diffcp).

Just quickly added back in the full, sparse, LU option too. I think we'll need to tune the LSQR settings a bit to make sure it converges for most problems, as here's an ill-conditioned problem that LSQR returns early from but the direct solver gives something reasonable: t.pkl.zip
import pickle as pkl
import torch
from osqpth.osqpth import OSQP

Q_idx, Q_shape, A_idx, A_shape, Q_data, p, A_data, l, u = pkl.load(open('/private/home/bda/repos/optnet/sudoku/t.pkl', 'rb'))
p.requires_grad_()

y_lsqr = OSQP(Q_idx, Q_shape, A_idx, A_shape, diff_mode='lsqr')(
    Q_data, p, A_data, l, u
)
print('==== lsqr')
print(torch.autograd.grad(y_lsqr[0,0], p)[0])

y_lu = OSQP(Q_idx, Q_shape, A_idx, A_shape, diff_mode='lu')(
    Q_data, p, A_data, l, u
)
print('===== lu')
print(torch.autograd.grad(y_lu[0,0], p)[0])

Output:
==== lsqr

LSQR            Least-squares solution of  Ax = b
The matrix A has      272 rows  and      272 cols
damp = 0.00000000000000e+00   calc_var =        0
atol = 1.00e-08                 conlim = 1.00e+08
btol = 1.00e-08               iter_lim =      544

   Itn      x[0]       r1norm     r2norm   Compatible    LS      Norm A   Cond A
     0  0.00000e+00   1.000e+00  1.000e+00    1.0e+00  5.8e-01
     1  4.70547e-03   9.920e-01  9.920e-01    9.9e-01  1.0e+05   4.6e+00  1.0e+00
     2  4.71200e-03   9.920e-01  9.920e-01    9.9e-01  7.9e-09   1.0e+08  2.2e+07

LSQR finished
The least-squares solution is good enough, given atol

istop =       2   r1norm = 9.9e-01   anorm = 1.0e+08   arnorm = 7.9e-01
itn   =       2   r2norm = 9.9e-01   acond = 2.2e+07   xnorm  = 2.7e-02

tensor([[-4.7120e-03,  9.1007e-18,  7.7816e-18,  9.2699e-18,  9.8331e-18,
          1.1310e-17,  9.2798e-18,  9.8769e-18,  9.1475e-18,  8.3885e-18,
          7.9731e-18,  1.0012e-17,  9.4575e-18,  9.7441e-18,  8.5112e-18,
          9.1525e-18,  8.9611e-18,  1.0282e-17,  8.6824e-18,  8.2783e-18,
          7.9033e-18,  6.1820e-18,  8.8372e-18,  8.7393e-18,  8.5133e-18,
          8.4072e-18,  9.3348e-18,  6.6223e-18,  8.8388e-18,  7.8768e-18,
          7.1385e-18,  7.4183e-18,  8.0707e-18,  7.9934e-18,  7.0882e-18,
          8.7638e-18,  8.5200e-18,  9.0570e-18,  8.7410e-18,  8.4229e-18,
          8.2337e-18,  5.8012e-18,  8.3921e-18,  6.9027e-18,  9.5226e-18,
          9.1675e-18,  7.7723e-18,  8.3988e-18,  7.4415e-18,  7.5445e-18,
          8.8055e-18,  9.4669e-18,  8.3989e-18,  8.3193e-18,  9.0031e-18,
          7.4605e-18,  1.0165e-17,  7.0037e-18,  8.8694e-18,  9.6764e-18,
          9.5390e-18,  9.1936e-18,  9.7664e-18,  1.0186e-17]], device='cuda:0',
       dtype=torch.float64)
===== lu
tensor([[-1.2817e+00,  1.7240e-04, -7.5087e-05,  7.0880e-02, -2.5255e-02,
          2.9073e-04, -1.2829e+00,  8.6578e-04, -5.7333e-01, -7.3684e-01,
         -1.5084e-01,  3.2826e-01, -3.7487e-01,  6.1822e-01,  2.9244e-01,
         -1.5862e-01,  4.6635e-01,  2.0958e-01,  1.9206e-01,  1.5975e-01,
         -3.8013e-03, -8.8888e-02, -4.0045e-01,  1.8145e-01,  5.0644e-01,
         -4.2531e-01, -2.3564e-02,  4.9506e-01,  6.2890e-01, -5.0957e-01,
         -7.4680e-01, -5.2668e-02, -1.4794e-02,  3.4635e-01,  1.6762e-05,
          1.1221e-01,  4.5385e-01,  6.7591e-02, -5.5885e-01, -2.9073e-01,
         -5.2149e-01, -2.5710e-01, -2.6545e-01, -3.4104e-01, -2.4808e-01,
         -2.8137e-02,  6.1538e-01,  5.7590e-06,  2.3811e-04, -3.5384e-01,
         -7.7634e-02, -3.7694e-01,  6.0934e-01, -1.8100e-04,  4.5111e-01,
          4.4656e-01,  1.9813e-03, -2.0191e-02,  1.6115e-02,  1.6816e-01,
          1.3684e+00,  8.1238e-01,  1.0328e-01,  3.1379e-01]], device='cuda:0',
       dtype=torch.float64)

Just to update on this: there has been much progress on the CVXPY QP interface https://github.com/cvxgrp/cvxpy/pull/960 thanks to @SteveDiamond.
From OSQP side I am working on a formulation that does not need LSQR. We now have qdldl-python that can be quickly hooked in and supports factorization updates/multi-threading.

I have just pushed the derivatives with symmetrized M matrix working with qdldl solver. @bamos @akshayka  would you have time to have a look at it? I think it should be more reliable than LSQR. It requires qdldl.

Awesome! The interface for adjoint_derivative looks good to me. It'd be great if a derivative method was also added at some point, but for CVXPY Layers, the adjoint is all we need.
Do the derivative tests all pass? (Just curious, I haven't run them myself.)
The dependency on QDLDL is fine by me.
Besides style things, such as commented out dead code (which I'm sure you're already planning to fix), it looks good to me.

Awesome! I've pulled the latest code and updated this osqpth PR/branch to use it: https://github.com/oxfordcontrol/osqpth/pull/7
The OptNet sudoku experiment is still not converging with osqpth as it does with osqp and I've been debugging it a bit over the past few days. It may be related to gradient scaling (related to summing v averaging across the broadcasted input tensors), the derivatives of equality constraints, or the -inf/large negative inequality constraints, but I'm not quite sure. I've also bumped up the accuracy of OSQP, as these problems are pretty poorly-scaled, which may make them a bad test suite for this...
I've been debugging by doing a single epoch of training with a minibatch size of 1:

If you think it should work with equality constraints and -inf/large negative inequality constraints, I can try to pull out a few concrete examples of where the mismatch is happening.
Also I ran into this error when factorizing M and patched it by adding a small diagonal term:
RuntimeError: Error in computing elimination tree. Matrix not properly upper-triangular, sum_Lnz = -1
> /private/home/bda/repos/osqp-python/osqp/interface.py(374)adjoint_derivative()
    372                                 spa.diags(y_l) @ dy_l])
    373
--> 374         r_sol = - qdldl.Solver(self._derivative_cache['M']).solve(d_sol)
    375
    376         r_x, r_yu, r_yl = np.split(r_sol, [n, n+m

The OptNet sudoku experiment is still not converging with osqpth as it does with osqp and I've been debugging it a bit over the past few days. It may be related to gradient scaling (related to summing v averaging across the broadcasted input tensors), the derivatives of equality constraints, or the -inf/large negative inequality constraints, but I'm not quite sure. I've also bumped up the accuracy of OSQP, as these problems are pretty poorly-scaled, which may make them a bad test suite for this...

It might be worth using this example to check the derivatives correctness since it is more challenging than our unittests.

Also I ran into this error when factorizing M and patched it by adding a small diagonal term:
RuntimeError: Error in computing elimination tree. Matrix not properly upper-triangular, sum_Lnz = -1
> /private/home/bda/repos/osqp-python/osqp/interface.py(374)adjoint_derivative()
    372                                 spa.diags(y_l) @ dy_l])
    373
--> 374         r_sol = - qdldl.Solver(self._derivative_cache['M']).solve(d_sol)
    375
    376         r_x, r_yu, r_yl = np.split(r_sol, [n, n+m

This error should not happen since we have a convex program. I wonder if this is related to scipy having not necessarily ordered sparse matrices. Maybe I should check has_sorted_indices before factoring. Do you have a MWE reproducing it?

Awesome! The interface for adjoint_derivative looks good to me. It'd be great if a derivative method was also added at some point, but for CVXPY Layers, the adjoint is all we need.
Do the derivative tests all pass? (Just curious, I haven't run them myself.)
The dependency on QDLDL is fine by me.
Besides style things, such as commented out dead code (which I'm sure you're already planning to fix), it looks good to me.

The tests pass on my computer but do not pass on ci because qdldl-python is not available on conda-forge yet. I just created an issue https://github.com/conda-forge/osqp-feedstock/issues/23 hoping that they could help me creating a feedstock. I will keep you posted and cleanup the code once we have something finalized ;-)

Do you have a MWE reproducing it?

Yes, I just looked a bit closer and it looks like this is happening when the solution hits the boundary exactly and makes those residuals in M exactly zero. Here's a MWE:
import scipy.sparse as sp
import numpy as np
import numpy.random as npr

import osqp

n = 100

npr.seed(1)

P = 0.01*npr.randn(n,n)
P = P.T.dot(P)
P = sp.csr_matrix(P)
q = npr.randn(n)
A = sp.csr_matrix(npr.randn(n, n))
l = npr.randn(n)
u = l

s = osqp.OSQP()
s.setup(P, q, A, l, u, eps_abs=1e-10, eps_rel=1e-10, max_iter=int(1e8))
results = s.solve()

s.adjoint_derivative(dx=np.ones(n))

I just tried replacing the QP solver with the cvxpylayers with the CP backend and that is able to reproduce the qpth results on the sudoku experiment. From a quick glance it even seems to slightly help roll out some instabilities with qpth. So this at least points to the convergence issues here being either from some way I've hooked osqp up to the sudoku experiment, or from some way the derivatives are being handled for these problems


Fail to ingest data to index after index created

Describe the bug
I deploy the quickwit in my prod env with k8s. It works for months normally. But I cannot ingest data to recently created index with rest api. The POST /api/v1/indexes respond 200, but POST /api/v1/my-index/ingest respond 404 with following response body:
{
   "message": "Index `Index `my-index` not found.` not found."
}

I can get index info with GET /api/v1/indexes/my-index/describe. I seems the index has been created.
I found quickwit-metastore reports the following error everytime I create a new index:
ERROR quickwit_control_plane: Failed to notify control plane of index change. error=Unavailable("Request not delivered") event="add-source"

I tried to restart quickwit-control-plane. After restarted, I found quickwit-control-plane reports the following error:
2023-12-11T09:03:02.100Z  WARN quickwit_metastore::metastore::retrying_metastore::retry: Request failed attempt_count=5
2023-12-11T09:03:02.100Z ERROR quickwit_control_plane::scheduler: Error when controlling the running plan: `Internal error: `Error, message length too large: found 4270109 bytes, the limit is: 4194304 bytes` Cause: ``.`.
2023-12-11T09:03:05.149Z  WARN quickwit_metastore::metastore::retrying_metastore::retry: Request failed attempt_count=5
2023-12-11T09:03:05.149Z ERROR quickwit_actors::spawn_builder: actor-failure cause=Error when scheduling indexing plan

Caused by:
    Internal error: `Error, message length too large: found 4270109 bytes, the limit is: 4194304 bytes` Cause: ``. exit_status=Failure(Error when scheduling indexing plan

Caused by:
    Internal error: `Error, message length too large: found 4270109 bytes, the limit is: 4194304 bytes` Cause: ``.)
2023-12-11T09:03:05.149Z  INFO quickwit_actors::spawn_builder: actor-exit actor_id=IndexingScheduler-autumn-PbzF exit_status=Failure(cause=Error when scheduling indexing plan

Caused by:
    Internal error: `Error, message length too large: found 4270109 bytes, the limit is: 4194304 bytes` Cause: ``.)
2023-12-11T09:03:05.149Z ERROR quickwit_actors::actor_context: exit activating-kill-switch actor=IndexingScheduler-autumn-PbzF exit_status=Failure(Error when scheduling indexing plan

Caused by:
    Internal error: `Error, message length too large: found 4270109 bytes, the limit is: 4194304 bytes` Cause: ``.)

Steps to reproduce (if applicable)
The problem is still in my prod env, but I cannot reproduce in my local env.
Expected behavior
How to fix it?
Configuration:
Please provide:

Output of quickwit --version

Quickwit v0.6.3 (5060b6c 2023-07-28T14:08:35Z)

The index_config.yaml

version: 0.6

index_id: my-index

doc_mapping:
  mode: strict
  field_mappings:
    - name: trace_id
      type: text
      fast: true
    - name: trace_state
      type: text
      indexed: false
    - name: service_name
      type: text
      tokenizer: raw
    - name: resource_attributes
      type: json
      tokenizer: raw
    - name: resource_dropped_attributes_count
      type: u64
      indexed: false
    - name: scope_name
      type: text
      indexed: true
    - name: scope_version
      type: text
      indexed: false
    - name: scope_attributes
      type: json
      indexed: false
    - name: scope_dropped_attributes_count
      type: u64
      indexed: false
    - name: span_id
      type: text
      tokenizer: raw
    - name: parent_span_id
      type: text
      fast: true
      tokenizer: raw
    - name: span_kind
      type: u64
    - name: span_name
      type: text
      tokenizer: raw
    - name: span_start_timestamp_nanos
      type: datetime
      input_formats: [unix_timestamp]
      output_format: unix_timestamp_nanos
      indexed: false
      fast: true
      precision: milliseconds
    - name: span_end_timestamp_nanos
      type: datetime
      input_formats: [unix_timestamp]
      output_format: unix_timestamp_nanos
      indexed: false
      fast: false
    - name: span_duration_millis
      type: u64
      indexed: false
      fast: true
      stored: false
    - name: span_attributes
      type: json
      tokenizer: en_stem
      record: position
    - name: span_dropped_attributes_count
      type: u64
      indexed: false
    - name: span_dropped_events_count
      type: u64
      indexed: false
    - name: span_dropped_links_count
      type: u64
      indexed: false
    - name: span_status
      type: json
      indexed: true
    - name: events
      type: array<json>
      tokenizer: raw
    - name: event_names
      type: array<text>
      tokenizer: default
      record: position
      stored: false
    - name: links
      type: array<json>
      tokenizer: raw

  timestamp_field: span_start_timestamp_nanos

  # partition_key: hash_mod(service_name, 100)
  # tag_fields: [service_name]

indexing_settings:
  commit_timeout_secs: 5

search_settings:
  default_search_fields: []

retention:
  period: 5 days
  schedule: daily

The index is just created. Nothing has been ingested to it.

@mingshun thanks for the report.
So, the control plane is retrieving all indexes metadata in one request and if the payload is too big, you will get this error. How many indexes do you have?
We can provide a quick fix by increasing the max size of gRPC messages but we first need to be sure if my assumption is correct.
Are you using a PostgreSQL metastore or file backed metastore?

There are 1027 indexes.

Ok, I think increase the max size of gRPC messages should solve your issue.
Are you deployment with docker images or binaries?

@mingshun, we just released the 0.6.5. Can you try it and see if it solves your issue? You should not see this problem up to 5000k indexes.
We will do a proper fix in the main branch to handle an arbitrary amount of indexes.

@fmassot 0.6.5 works.


Look up usdt

USDT asset ID is now looked up properly, a cache is created at the start of the processor run.
If a new asset ID is added and the processor is not restarted, it should still work, because if there is a cache miss the existing code queries for it.

Please create a new branch starting from master. Then apply the change and open a new PR.
All commits before the actual change in b3a44bc were part of a previous PR #90 .
We can't merge this as is.


3.3.0版本用户管理显示问题

3.3.0版本，不是dev版本，用户管理显示Page Not Found，之前装过好几次也是一直这个问题，其他功能都正常，是不是需要设置还是配置，求指导！
Page Not Found
The page you are looking for could not be found. Check the address bar to ensure your URL is spelled correctly. If all else fails, you can visit our home page at the link below.

/admin/user 404?

非 404
Page Not Found
The page you are looking for could not be found. Check the address bar to ensure your URL is spelled correctly. If all else fails, you can visit our home page at the link below.


laser scan seems off at higher distances.

As you can see in the figure (topdown ortho view in RVIZ) the laserscan does not match the pointcloud at further distances.

It might be due to the laser scan max range that we set to 6 meters.

Could we fix this somehow, I would set the max range to the same as the max pointcloud readings.

This issue could not be reproduced, it might have been some ghost points.
Still a PR will be opened to set the max range the same as the max from pointcloud.


Skip loading tags where the tag list is known to be empty

Coverage decreased (-0.2%) to 46.939% when pulling 40013ffed7e960845e5a114c8a3426d532a29260 on dont-load-empty-tags into f629e828b511ca8a89c4566d0a21f7edaaa624cf on master.

Current coverage is 40.78% (diff: 0.00%)

Merging #209 into master will decrease coverage by 0.12%

@@             master       #209   diff @@
==========================================
  Files            33         33
  Lines          1303       1307     +4
  Methods         180        180
  Messages          0          0
  Branches        166        167     +1
==========================================
  Hits            533        533
- Misses          770        774     +4
  Partials          0          0

Powered by Codecov. Last update f629e82...40013ff

Coverage decreased (-0.2%) to 46.939% when pulling 7583e2bdb17d9d46b5941bcc47c430d67522cec2 on dont-load-empty-tags into f629e828b511ca8a89c4566d0a21f7edaaa624cf on master.

Coverage decreased (-0.2%) to 46.939% when pulling c84017e8d7edcdaf941884b7c6c1dcb59ca5d21e on dont-load-empty-tags into f629e828b511ca8a89c4566d0a21f7edaaa624cf on master.


Improve: More Cleaner Code WITH Output Helper Functions (low priority)

add helper functions to change this
sys.stderr.write(
            "\n" + BOLD + "Usage:" + END + "\n\nmdpre < inputfile > outputfile\n\n"
        )

if wantVerbose is True:
        sys.stderr.write("Writing to Textbundle " + realpath + "\n\n")

to

log( bold( "Usage:") + "\n\nmdpre < inputfile > outputfile\n\n" )

# remove if blocks from verbose checking by creating a new log_detail method
log_detail("Writing to Textbundle " + realpath + "\n\n")

# this would be bold ;-)
def bold( p_text ):
    return BOLD + p_text + END

Looks like we have a few sys.stderr.write() incantations left. Leaving open so this can be fixed.


⚠ Bofrost.de has degraded performance

In e2a0a0b, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 1691 ms

Resolved: Bofrost.de performance has improved in b545336 after 303 days, 18 hours, 49 minutes.


Switch rng.gen_range() to Uniform.sample() in Gnp functions

This commit updates the gnp random graph functions to internally use
Uniform.sample() instead of rng.gen_range(). The rand docs for
gen_range() recommend the use of Uniform if you're going to getting
random values in a range more than once, as the gen_range() function is
optimized for the single sample case. [1][2]
[1] https://docs.rs/rand/0.7.3/rand/trait.Rng.html#method.gen_range
[2] https://docs.rs/rand/0.7.3/rand/distributions/uniform/struct.Uniform.html

Pull Request Test Coverage Report for Build 315773842

4 of 4 (100.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.006%) to 93.277%

Totals

Change from base Build 315696750:
0.006%

Covered Lines:
2206

Relevant Lines:
2365

💛  - Coveralls

@MoAllabbad Does this look good to you?

@MoAllabbad Does this look good to you?

LGTM. Thanks.


RTB-2: add telegram bot to the project

Create stub telegram-bot for the project.
Acceptance criteria:
stub answer via telegram-bot added to the project

https://github.com/JBolivarLi/JRTelegramBot/pull/16

https://github.com/JBolivarLi/JRTelegramBot/pull/16


Integrate with oathkeeper via forward-auth interface

Issue

This PR adds integration with Oathkeeper - the policy decision point in Identity and Access Proxy architecture.
In order to integrate Traefik into IAP, it must create routing rules for Oathkeeper and the related applications, with the ForwardAuth middleware specified.
The middleware should be defined in the Oathkeeper rule, while other charms should only use it. The definition must include headers and decisions address.
Solution

This PR integrates traefik with oathkeeper with the use of forward-auth interface.
Oathkeeper provides Traefik with its decisions address, allowed return headers and application names that requested the IAP protection. This information is processed by Oathkeeper from auth-proxy relation.
Traefik adds middleware definition to Oathkeeper's route and updates the relation databag with app names it provides ingress for, so that Oathkeeper can compare the app names and evaluate if they can be protected using forwardAuth.
If an app is related with ingress-per-app/leader/unit, Traefik will update its routes and append the middleware.
Context

Traefik ForwardAuth upstream docs
IAP interfaces design
Testing Instructions

Pack and deploy the charms.
As forward-auth relies on auth-proxy relation data, I'm using zinc-k8s from this branch as a dummy example to test that the relation data is then transferred to traefik.
Oathkeeper is built from this branch.

juju deploy ./traefik-k8s_ubuntu-20.04-amd64.charm traefik-ingress --trust --resource traefik-image=ghcr.io/canonical/traefik:2.10.4
juju deploy ./oathkeeper*.charm --resource oci-image=$(yq eval '.resources.oci-image.upstream-source' metadata.yaml)
juju deploy ./zinc-k8s*.charm --resource zinc-image=ghcr.io/jnsgruk/zinc:0.4.9 --trust

Add integrations to oathkeeper:

juju relate oathkeeper traefik-ingress:ingress
juju relate oathkeeper zinc-k8s:auth-proxy
juju relate oathkeeper traefik-ingress:forward-auth

At this point, if zinc was not related to ingress, oathkeeper will get blocked with message zinc-k8s is not related via ingress.
After you relate zinc with ingress, oathkeeper will get active:
juju relate zinc-k8s traefik-ingress

Check the traefik routes:

juju ssh --container traefik traefik-ingress/0 bash
cd /opt/traefik/juju/

Oathkeeper route should hold the forwardAuth middleware definition, but should not enlist it in http.routers.middlewares:
# cat juju_ingress_ingress_3_oathkeeper.yaml
http:
  middlewares:
    juju-sidecar-forward-auth-oathkeeper:
      forwardAuth:
        address: https://oathkeeper.test1.svc.cluster.local:4456/decisions
        authResponseHeaders:
        - X-User
    juju-sidecar-noprefix-test1-oathkeeper:
      stripPrefix:
        forceSlash: false
        prefixes:
        - /test1-oathkeeper
  routers:
    juju-test1-oathkeeper-router:
      entryPoints:
      - web
      middlewares:
      - juju-sidecar-noprefix-test1-oathkeeper
      rule: PathPrefix(`/test1-oathkeeper`)
      service: juju-test1-oathkeeper-service
    juju-test1-oathkeeper-router-tls:
      entryPoints:
      - websecure
      middlewares:
      - juju-sidecar-noprefix-test1-oathkeeper
      rule: PathPrefix(`/test1-oathkeeper`)
      service: juju-test1-oathkeeper-service
      tls: {}
  services:
    juju-test1-oathkeeper-service:
      loadBalancer:
        servers:
        - url: http://oathkeeper-0.oathkeeper-endpoints.test1.svc.cluster.local:4456

Zinc route should only use the middleware:
# cat juju_ingress_ingress_6_zinc-k8s.yaml
http:
  middlewares:
    juju-sidecar-noprefix-test1-zinc-k8s:
      stripPrefix:
        forceSlash: false
        prefixes:
        - /test1-zinc-k8s
  routers:
    juju-test1-zinc-k8s-router:
      entryPoints:
      - web
      middlewares:
      - juju-sidecar-forward-auth-oathkeeper
      - juju-sidecar-noprefix-test1-zinc-k8s
      rule: PathPrefix(`/test1-zinc-k8s`)
      service: juju-test1-zinc-k8s-service
    juju-test1-zinc-k8s-router-tls:
      entryPoints:
      - websecure
      middlewares:
      - juju-sidecar-forward-auth-oathkeeper
      - juju-sidecar-noprefix-test1-zinc-k8s
      rule: PathPrefix(`/test1-zinc-k8s`)
      service: juju-test1-zinc-k8s-service
      tls: {}
  services:
    juju-test1-zinc-k8s-service:
      loadBalancer:
        servers:
        - url: http://zinc-k8s.test1.svc.cluster.local:4080

Release Notes

add forward-auth integration with oathkeeper

Thanks Natalia, will review when I have time after/during the sprint (or probably next week we can go through it together if you like).

In order to make it clear that the feature is untested and might be unstable/experimental, we should rename the endpoint to experimental_forward_auth. The description should make it clear what it does and that it's insecure and that you're supposed to have traefik enabled as TLS termination endpoints.
For now you'll have to do juju relate traefik:experimental_forward_auth oathkeeper, and then when the feature becomes stable and oathkeeper has TLS, we can rename the interface to forward_auth.
Secondly, we will only enable the experimental forward auth feature behind a feature flag.
You'll need to juju config traefik enable_experimental_forward_auth=True in order to use it.
All code blocks introduced by this PR should be behind a:
if self.config["enable_experimental_forward_auth"]: guard so that we can easily filter out any buggy behaviour due to this feature.
If you relate traefik to oathkeeper but enable_experimental_forward_auth is False, Traefik will not enable the middleware.

In order to make it clear that the feature is untested and might be unstable/experimental, we should rename the endpoint to experimental_forward_auth. The description should make it clear what it does and that it's insecure and that you're supposed to have traefik enabled as TLS termination endpoints.
For now you'll have to do juju relate traefik:experimental_forward_auth oathkeeper, and then when the feature becomes stable and oathkeeper has TLS, we can rename the interface to forward_auth.
Secondly, we will only enable the experimental forward auth feature behind a feature flag. You'll need to juju config traefik enable_experimental_forward_auth=True in order to use it. All code blocks introduced by this PR should be behind a: if self.config["enable_experimental_forward_auth"]: guard so that we can easily filter out any buggy behaviour due to this feature.
If you relate traefik to oathkeeper but enable_experimental_forward_auth is False, Traefik will not enable the middleware.

Wouldn't it be enough to have the feature flag as a juju config? I'd prefer to avoid renaming the relation.

In order to make it clear that the feature is untested and might be unstable/experimental, we should rename the endpoint to experimental_forward_auth. The description should make it clear what it does and that it's insecure and that you're supposed to have traefik enabled as TLS termination endpoints.
For now you'll have to do juju relate traefik:experimental_forward_auth oathkeeper, and then when the feature becomes stable and oathkeeper has TLS, we can rename the interface to forward_auth.
Secondly, we will only enable the experimental forward auth feature behind a feature flag. You'll need to juju config traefik enable_experimental_forward_auth=True in order to use it. All code blocks introduced by this PR should be behind a: if self.config["enable_experimental_forward_auth"]: guard so that we can easily filter out any buggy behaviour due to this feature.
If you relate traefik to oathkeeper but enable_experimental_forward_auth is False, Traefik will not enable the middleware.

Wouldn't it be enough to have the feature flag as a juju config? I'd prefer to avoid renaming the relation.

We don't have to rename the interface, only the endpoint. That seems like a minor change.
We want to avoid the impression that traefik offers stable support for forward_auth. A config-toggled feature flag is a bit hidden: someone might skip reading the config, deploy traefik, relate forward-auth, and be surprised when it doesn't work.

Hi @natalian98
I deployed the following bundle (you can add it to ./tests/manual if you'd like):
bundle: kubernetes
applications:
  ok:
    # From https://github.com/canonical/oathkeeper-operator
    charm: ./oathkeeper-operator/oathkeeper_ubuntu-22.04-amd64.charm
    scale: 1
    constraints: arch=amd64
    trust: true
    resources:
      oci-image: "ghcr.io/canonical/oathkeeper:0.40.6"
  trfk:
    # From https://github.com/canonical/traefik-k8s-operator/pull/275
    charm: ./traefik-k8s-operator/traefik-k8s_ubuntu-20.04-amd64.charm
    series: focal
    scale: 1
    constraints: arch=amd64
    storage:
      configurations: kubernetes,1,1024M
    trust: true
    resources:
      traefik-image: "docker.io/ubuntu/traefik:2-22.04"
zinc:
    # From https://github.com/natalian98/zinc-k8s-operator/tree/test-proxy-interfaces
    charm: ./zinc-k8s-operator/zinc-k8s_ubuntu-22.04-amd64.charm
    scale: 1
    constraints: arch=amd64
    storage:
      data: kubernetes,1,1024M
    trust: true
    resources:
      zinc-image: "ghcr.io/jnsgruk/zinc:0.4.9"
relations:
- - ok:forward-auth
  - trfk:experimental-forward-auth
- - ok:auth-proxy
  - zinc:auth-proxy
- - zinc:ingress
  - trfk:ingress

Then oathkeeper is stuck in
Unit     Workload  Agent      Address       Ports  Message
ok/0*    waiting   executing  <IP_ADDRESS>         Waiting for Oathkeeper service

and debug-log has a recurring error:
unit-ok-0: 14:55:12.963 ERROR unit.ok/0.juju-log Uncaught exception while in charm code:
Traceback (most recent call last):
  File "/var/lib/juju/agents/unit-ok-0/charm/venv/lightkube/core/generic_client.py", line 188, in raise_for_status
    resp.raise_for_status()
  File "/var/lib/juju/agents/unit-ok-0/charm/venv/httpx/_models.py", line 758, in raise_for_status
    raise HTTPStatusError(message, request=request, response=self)
httpx.HTTPStatusError: Client error '404 Not Found' for url 'https://<IP_ADDRESS>/apis/apps/v1/namespaces/auth2/statefulsets/oathkeeper?fieldManager=ok'
For more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/404

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/var/lib/juju/agents/unit-ok-0/charm/./src/charm.py", line 555, in <module>
    main(OathkeeperCharm)
  File "/var/lib/juju/agents/unit-ok-0/charm/venv/ops/main.py", line 436, in main
    _emit_charm_event(charm, dispatcher.event_name)
  File "/var/lib/juju/agents/unit-ok-0/charm/venv/ops/main.py", line 144, in _emit_charm_event
    event_to_emit.emit(*args, **kwargs)
  File "/var/lib/juju/agents/unit-ok-0/charm/venv/ops/framework.py", line 340, in emit
    framework._emit(event)
  File "/var/lib/juju/agents/unit-ok-0/charm/venv/ops/framework.py", line 842, in _emit
    self._reemit(event_path)
  File "/var/lib/juju/agents/unit-ok-0/charm/venv/ops/framework.py", line 931, in _reemit
    custom_handler(event)
  File "/var/lib/juju/agents/unit-ok-0/charm/./src/charm.py", line 329, in _on_oathkeeper_pebble_ready
    self._patch_statefulset()
  File "/var/lib/juju/agents/unit-ok-0/charm/./src/charm.py", line 318, in _patch_statefulset
    self.client.patch(StatefulSet, name=self.meta.name, namespace=self.model.name, obj=patch)
  File "/var/lib/juju/agents/unit-ok-0/charm/venv/lightkube/core/client.py", line 325, in patch
    return self._client.request("patch", res=res, name=name, namespace=namespace, obj=obj,
  File "/var/lib/juju/agents/unit-ok-0/charm/venv/lightkube/core/generic_client.py", line 245, in request
    return self.handle_response(method, resp, br)
  File "/var/lib/juju/agents/unit-ok-0/charm/venv/lightkube/core/generic_client.py", line 196, in handle_response
    self.raise_for_status(resp)
  File "/var/lib/juju/agents/unit-ok-0/charm/venv/lightkube/core/generic_client.py", line 190, in raise_for_status
    raise transform_exception(e)
lightkube.core.exceptions.ApiError: statefulsets.apps "oathkeeper" not found
unit-ok-0: 14:55:13.190 ERROR juju.worker.uniter.operation hook "oathkeeper-pebble-ready" (via hook dispatching script: dispatch) failed: exit status 1
unit-ok-0: 14:55:13.191 ERROR juju.worker.uniter pebble poll failed for container "oathkeeper": failed to send pebble-ready event: hook failed

Tested successfully with the bundle below.
$ juju run trfk/0 show-proxied-endpoints
proxied-endpoints: '{"zinc": {"url": "http://<IP_ADDRESS>/auth2-zinc"}}'

$ curl http://<IP_ADDRESS>/auth2-zinc/version
{"version":"'0.4.9'","build":"0","commit_hash":"'249a843897ade8ca3f7e80ac6036b8ac0a27154a'","branch":"0","build_date":"'2023-09-13_09:50:04AM-GMT'"}%

$ curl http://<IP_ADDRESS>/auth2-zinc/versionn
{"error":{"code":401,"status":"Unauthorized","message":"The request could not be authorized"}}

@natalian98 do we have issues open to capture the gaps currently addressed by:

config option: enable_experimental_forward_auth: true
config option: dev: true
relation: trfk:experimental-forward-auth

bundle: kubernetes
applications:
  ok:
    # From https://github.com/canonical/oathkeeper-operator
    # 1e23771 - (HEAD -> address-forward-auth-comments, origin/address-forward-auth-comments) refactor
    charm: ./oathkeeper-operator/oathkeeper_ubuntu-22.04-amd64.charm
    scale: 1
    constraints: arch=amd64
    trust: true
    resources:
      oci-image: "ghcr.io/canonical/oathkeeper:0.40.6"
    options:
      # until tls is impl'd dev mode would resort to http decisions url
      dev: true
  trfk:
    # From https://github.com/canonical/traefik-k8s-operator/pull/275
    # cc35a85 - (HEAD -> IAM-500-forward-auth-relation-implementation, natalian98/IAM-500-forward-auth-relation-implementation) refactor: add experimental_forward_auth_enabled as an init arg
    charm: ./traefik-k8s-operator/traefik-k8s_ubuntu-20.04-amd64.charm
    series: focal
    scale: 1
    constraints: arch=amd64
    storage:
      configurations: kubernetes,1,1024M
    trust: true
    resources:
      traefik-image: "docker.io/ubuntu/traefik:2-22.04"
    options:
      enable_experimental_forward_auth: true
  zinc:
    # From https://github.com/natalian98/zinc-k8s-operator
    # 0c19865 - (HEAD -> test-proxy-interfaces, origin/test-proxy-interfaces) fix: auth-proxy
    charm: ./zinc-k8s-operator/zinc-k8s_ubuntu-22.04-amd64.charm
    scale: 1
    constraints: arch=amd64
    storage:
      data: kubernetes,1,1024M
    trust: true
    resources:
      zinc-image: "ghcr.io/jnsgruk/zinc:0.4.9"
relations:
- - ok:forward-auth
  - trfk:experimental-forward-auth
- - ok:auth-proxy
  - zinc:auth-proxy
- - zinc:ingress
  - trfk:ingress


Add SpaceTimeLocationPicker and allow for offsets form t0 for different data sources

Detailed Description
The t0 would be the initialization time, renamed to that, and then the t0 for different data sources are offset from that, like rounding down half an hour, or 45 minutes, etc. to more match what we see in productions, and can be tailored in production to the actually available data
Context

Possible Implementation

This is done somewhat, look at PVNet datapipes


Add config code for different file types

Description
The readme file needs some copy paste code blocks for configuring astro-layouts in:

[x] Markdown
[x] MDX
[x] Both

fixed in #11


Documenting mypy

Below is an example of a needing help working out which type these objects are:
def to_pyats(env, df, output_dir: str = None):
    """
    Take the pandas dataframe, convert it to a dictionary
    and render that dictionary through a Jinja2 template to
    create an pyATS testbed file.

    Args:
        env (?): The loaded Jinja2 environment, used to retrieve
        templates from.
        df (?): The pandas dataframe object, initialised from the
        inventory data source.
        output_dir (str): The output directory. Default: None

    Returns:
        tb_file (?): The pyATS testbed file object.

    Raises:
        N/A
    """

Would be great to get some advice on how to work these out, so I can document them.

Finally closed this issue :)


"dotnet paket --version" hangs until forcefully closed

Description
Short version
Some threads hang at dotnet paket --version and never moves on. This results in builds hanging because some projects never gets build; Visual Studio won't unload projects or ReSharper fails to load; possibly also causing other faulty behaviors.
Longer version
We've found that having the CPU max out sometimes causes dotnet paket --version commands to hang a process. It seems to be some kind of timing issue, but we are uncertain if the issue is in dotnet faulting on the output from paket, og if paket simply never exists correctly.
The problem seems to only happen when using the new SDK project format (which is the one leveraging dotnet to begin with), as we do not have the same issue with our large Full Framework projects that have not yet been upgraded.
Also, having anti virus monitoring file changes, as well as using ReSharper, seems to increase the likelyhood dramatically of it happening.
We started noticing dotnet processes not closing down again after calling dotnet paket --version, and they seem to be what is blocking all the processes. Even more odd is, that when inspecting the process with Process Explorer and going to the Threads tab, the process finally closes down. What exactly causes the process to close down from that inspection we have still not uncovered, as listing the threads of the process via PowerShell does not yield the same result.
Repro steps

Have a large solution (in our case 230 projects) in Full Framework, but in the new SDK format.
Have ReSharper active in Visual Studio.
Work for a bit in Visual Studio, building and navigating around for 4-5 minutes.
Attempt to unload the solution

Expected behavior
Visual Studio should simply unload the solution.
Actual behavior
Unloads hangs at "Unloading project 0 of 230 ..." and never quits (have tried leaving it for multiple hours). In Process Explorer a process will be running with the command dotnet paket --version.
Known workarounds
Either:

Shut down the hanging process by going to the threads tab, or forcing the process to exit.
Or:
Removing the part in the paket.targets file that actually calls dotnet paket --version, and replacing it with calling the local paket.exe always instead. This get overridden however when paket install/update is called, and must be corrected again, and there are no switches to prevent it from happening.

Final thoughts
This issue has been downright cripling for our development department, as everything slowed down to an almost standstill. Different developers saw the bug more or less frequently, but some had an unresponsive Visual Studio for 10-15 minutes at a time.
We do not know, however, if the error is with dotnet instead of directly with paket, but it is only in combination of the two we have the error.
The best solution, for us right now, I believe is to have some sort of flag, that would brevet paket to get asked all the time.
I hope the issue makes somewhat sense, and that a more permanent solution can be found, rather than we manually fix the targets file, time and time again.. :)

Could you please send a pr which checks if the lical Paket exists and calls
it instead of global one? Thst would be easy and non breaking change,
right?
Johny Woller Skovdal<EMAIL_ADDRESS>schrieb am Sa., 9. Nov.
2019, 00:44:

Description Short version
Some threads hang at dotnet paket --version and never moves on. This
results in builds hanging because some projects never gets build; Visual
Studio won't unload projects or ReSharper fails to load; possibly also
causing other faulty behaviors.
Longer version
We've found that having the CPU max out sometimes causes dotnet paket
--version commands to hang a process. It seems to be some kind of timing
issue, but we are uncertain if the issue is in dotnet faulting on the
output from paket, og if paket simply never exists correctly.
The problem seems to only happen when using the new SDK project format
(which is the one leveraging dotnet to begin with), as we do not have the
same issue with our large Full Framework projects that have not yet been
upgraded.
Also, having anti virus monitoring file changes, as well as using
ReSharper, seems to increase the likelyhood dramatically of it happening.
We started noticing dotnet processes not closing down again after calling dotnet
paket --version, and they seem to be what is blocking all the processes.
Even more odd is, that when inspecting the process with Process Explorer
https://docs.microsoft.com/en-us/sysinternals/downloads/process-explorer
and going to the Threads tab, the process finally closes down. What exactly
causes the process to close down from that inspection we have still not
uncovered, as listing the threads of the process via PowerShell does not
yield the same result.
Repro steps

Have a large solution (in our case 230 projects) in Full Framework,
but in the new SDK format.
Have ReSharper active in Visual Studio.
Work for a bit in Visual Studio, building and navigating around for
4-5 minutes.
Attempt to unload the solution

Expected behavior
Visual Studio should simply unload the solution.
Actual behavior
Unloads hangs at "Unloading project 0 of 230 ..." and never quits (have
tried leaving it for multiple hours). In Process Explorer a process will be
running with the command dotnet paket --version.
Known workarounds
Either:

Shut down the hanging process by going to the threads tab, or
forcing the process to exit.
Or:
Removing the part in the paket.targets file that actually calls dotnet
paket --version, and replacing it with calling the local paket.exe
always instead. This get overridden however when paket install/update
is called, and must be corrected again, and there are no switches to
prevent it from happening.

Final thoughts
This issue has been downright cripling for our development department, as
everything slowed down to an almost standstill. Different developers saw
the bug more or less frequently, but some had an unresponsive Visual Studio
for 10-15 minutes at a time.
We do not know, however, if the error is with dotnet instead of directly
with paket, but it is only in combination of the two we have the error.
The best solution, for us right now, I believe is to have some sort of
flag, that would brevet paket to get asked all the time.
I hope the issue makes somewhat sense, and that a more permanent solution
can be found, rather than we manually fix the targets file, time and time
again.. :)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/fsprojects/Paket/issues/3705?email_source=notifications&email_token=AAAOANDZH5DSXZXETL6IH23QSX2UXA5CNFSM4JLAUE2KYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HYC56SQ,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAOANEW4I3FJZL6CAPATJTQSX2UXANCNFSM4JLAUE2A
.

I hope so. But I can not be 100% sure when not completely understanding why it is prioritized as it is now? For instance, the global tools takes precedence over what is included in the repository, which makes me believe, that it will actually have an effect on existing installations to change that logic.
I will give at a try though, and we can discuss it around concrete code changes.

Tbh I think local tools should always be preferred.
Johny Woller Skovdal<EMAIL_ADDRESS>schrieb am Sa., 9. Nov.
2019, 14:08:

I hope so. But I can not be 100% sure when not completely understanding
why it is prioritized as it is now? For instance, the global tools takes
precedence over what is included in the repository, which makes me believe,
that it will actually have an effect on existing installations to change
that logic.
I will give at a try though, and we can discuss it around concrete code
changes.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/fsprojects/Paket/issues/3705?email_source=notifications&email_token=AAAOANFAZ4RF5YKJJN4B4U3QS2Y5TA5CNFSM4JLAUE2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDUFYYY#issuecomment-552098915,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAOANEYVVBRZBNCV45AA3LQS2Y5TANCNFSM4JLAUE2A
.

Then the next issue is how you determine if they are available or not. Delving deeper into it, a few things puzzles me with the target file.
E.g. why does windows need the .exe extension? In my understanding it is never needed? Windows will always attempt to run the .exe file if it exists, and you execute a command using no extension.
If not using the dotnet CLI approach, it seems, the fallback, if nothing is found, is the global path, but nothing to test for its presence. Perhaps that is where the distinction should be? If no local tools are found, use dotnet CLI if it works, if not, use global tool?

This also seems to be an error:
<!-- no windows, try bootstrapper -->
<PaketExePath Condition=" '$(PaketExePath)' == '' AND '$(OS)' != 'Windows_NT' AND Exists('$(PaketBootStrapperExeDir)') ">$(PaketBootStrapperExeDir)paket.exe</PaketExePath>

Shouldn't "paket.exe" be included in the "Exists" test? I'll be changing that in the PR to begin with, and we'll see where it leads us.. :)

I'm happy about all the help that we can get. It's extremely tricky to get
those things working on all the platforms. Thanks for jumping in.
Johny Woller Skovdal<EMAIL_ADDRESS>schrieb am Sa., 9. Nov.
2019, 14:26:

This also seems to be an error:

$(PaketBootStrapperExeDir)paket.exe
Shouldn't "paket.exe" be included in the "Exists" test? I'll be changing
that in the PR to begin with, and we'll see where it leads us.. :)
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/fsprojects/Paket/issues/3705?email_source=notifications&email_token=AAAOANBQDFZ3T33IMOL2JSDQS23CHA5CNFSM4JLAUE2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDUGD4A#issuecomment-552100336,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAOANFOPRBJCS625FFN3X3QS23CHANCNFSM4JLAUE2A
.

You're welcome. Awesome product! :) And now I've forced 40 developers to use it here, so I'd better make sure it works for them. ;) I've opened #3706 that should be a good first step to solving it.


Retrain PVnet with new PV live data

after upgrade to v4, we need to retrain PVNet to work on these values.

Need to do this first - https://github.com/openclimatefix/GSPConsumer/issues/27


!wolfram breaks threads

The wolfram thread reply mode reports an error on any thread message regardless of whether it originated from the !wolfram command. Happens when the bot can't request information about a thread through conversations.history
This is probably a missing scope error.

Not sure I am able to fix this myself. As far as I can tell it is a scoping error on Slacks end which I don't really get considering it works perfectly fine on the testing Slack and I can't really think of a way to do this that doesn't require the scope it's missing.

Fair, I say it needs a bit of investigatory work at some point.
Adding this comment for documentation + future consideration:
Possible solution is creating a new uqcsbot app to (potentially) fix issues that may have arisen from one of slack's many changes to the API in the past year. This is somewhat likely, as if I recall correctly we had the same issue on the uqcstesting slack and adding new bots fixed it.

I believe I fixed this through messing with auth stuff. We'll likely have to migrate to the new oauth system at some point as well, so I expect to open a new issue about that eventually anyway. For now though, I believe the missing scope issue has been fixed.

reopening as it turns out this isn't fixed in channels, it was only fixed in direct messages.
obviously uqcsbot has access to im.history and not channels.history for some reason I presume, so further investigation is needed.

I think the whole authentication and scopes problem can be avoided if @264 is implemented.

Seems like the bot in the uqcstesting slack somehow has more permissions than a normal bot. According to bots.info the testing bot has "identify,read,post,client,apps" and a normal bot only has "identify,bot:basic".


Update the SharedTree fuzz tests to use describeFuzz

Description
This will allow the SharedTree fuzz tests to be run by the DDS stress test pipeline.

describeFuzz is already being invoked by createDDSFuzzSuite, so this is redundant.


Teleportation circuit compiled with opt level 2 cannot be run on AerBackend due to conditional Phase

c = Circuit()
alice = c.add_q_register("a", 2)
bob = c.add_q_register("b", 1)
data = c.add_c_register("d", 2)
final = c.add_c_register("f", 1)
c.Rx(0.3, alice[0])
c.H(alice[1]).CX(alice[1], bob[0])
c.CX(alice[0], alice[1]).H(alice[0])
c.Measure(alice[0], data[0])
c.Measure(alice[1], data[1])
c.X(bob[0], condition_bits=[data[0], data[1]], condition_value=1)
c.X(bob[0], condition_bits=[data[0], data[1]], condition_value=3)
c.Z(bob[0], condition_bits=[data[0], data[1]], condition_value=2)
c.Z(bob[0], condition_bits=[data[0], data[1]], condition_value=3)
c.Measure(bob[0], final[0])

backend = AerBackend()
c = backend.get_compiled_circuit(c)
handle = backend.process_circuit(c, n_shots=2000)

NotImplementedError: Cannot convert tket Op to Qiskit gate: Phase(0.5)

This is caused by conditional X/Z being converted to conditional Phase, and the latter is not supported by the qiskit converter.

I think this bug is related to the one I was experiencing with the comparing_simulators.ipynb/py notebook
I noticed this with the CI failure here https://github.com/CQCL/pytket/actions/runs/3675606009/jobs/6215237406#step:9:214

Ah sorry yes you're right it was https://github.com/CQCL/tket/issues/683

The code snippet above woks for me with 0.31.0.


Question: Does Calcite-bootstrap extend the bootstrap JavaScript?

I'm looking at using React-Bootstrap, but one of its stipulations is that it doesn't play well with libraries that extend Bootstrap's JS functionality. Does Calcite Bootstrap use the bootstrap JS out-of-the-box, or is some of it extended? Are there plans to extend it?

Calcite Bootstrap uses the core unmodified Bootstrap JB library. There are no plans to change from that.


.transform/.traverse should only trigger partial function once

I had to admit it but I was writing a partial function today that did have a side effect and I hit on this
@ var i = 0
i: Int = 0

@ q"A".transform {
    case q"A" if {
    i += 1
    i < 2
  } => q"b"
  }
scala.MatchError: A (of class scala.meta.Term$Name$TermNameImpl)
  scala.PartialFunction$$anon$1.apply(PartialFunction.scala:254)
  scala.PartialFunction$$anon$1.apply(PartialFunction.scala:252)

We should use .applyOrElse which is designed exactly for this use-case.

I agree that it should not do that. But... side effects in the pattern are just asking for trouble!


Adds missing await

Don't merge yet.
We still need to exclude the bot DMs from being processed I think.

Oh cool, you're already checking to make sure they have the role removed. Should be good to go.


How is the language set

Hi I am tying to set the language but i keep getting an error The language must be an object.
My code looks like this
new FlipClock($block.get(0), new Date(endDate), {
  face: 'DayCounter',
  countdown: true,
  language: 'de'
});

Do you have global variable FlipClock.Lang['de'] on your page?

@tangar76 No. It might be the way I use the lib. I require it with the following line
require("flipclock/dist/flipclock");

I install a fork instead flipclock-es6

Couple things, I would recommend Babel/and ES6 imports and just import the raw files, and dont mess with the compiled/dist files unless you load the script into the global scope. It should work though, even that way, but I think your bundle size will be smaller. import FlipClock from 'flipclock/src/js/Components/Flipclock'. require() might work too, but haven't tested it directly. I just noticed I need to add a module property to the package.json so it autoloads main.js.
Also for the lang files, I've debated on how to handle this. I really don't like the fact that all the language files are baked into the package, bloating the file size for 30+ languages when people only usually use a few of them. I might create a separate bundle call flipclock.languages.js and compile each language file individually. I also need to test importing specific languages with ES6.
There is an example in the new branch that shows how to use the languages.


OP logout request doesn't pass id_token_hint in parameter when OIDCSessionType set to "client-cookie"

Okta op logout required to have a query parameter id_token_hint as below including post_logout_redirect_uri
https://dev-/<>.okta.com/oauth2/default/v1/logout?post_logout_redirect_uri=<redirect_uri>&id_token_hint=
However, triggering below redirect to OP where id_token_hint will be missing causing error when OIDCSessionType set to "client-cookie". It works well when OIDCSessionType set to "server-cache"
http://ip/oauth/callback?logout=<redirect_uri>&id_token_hint=

https://github.com/zmartzone/mod_auth_openidc/discussions/812

Adding Ankit.
Thanks,
Rahul
From: Hans Zandbelt @.>
Sent: 19 August 2022 19:56
To: zmartzone/mod_auth_openidc @.>
Cc: Kumar Rahul -X (kumrahu2 - WIPRO LIMITED at Cisco) @.>; Author @.>
Subject: Re: [zmartzone/mod_auth_openidc] OP logout request doesn't pass id_token_hint in parameter when OIDCSessionType set to "client-cookie" (Issue #908)
Closed #908https://github.com/zmartzone/mod_auth_openidc/issues/908 as completed.
—
Reply to this email directly, view it on GitHubhttps://github.com/zmartzone/mod_auth_openidc/issues/908#event-7222671181, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ATZRGDGDBJMPU2MECPNYSKTVZ6KQTANCNFSM57A5LECQ.
You are receiving this because you authored the thread.Message ID<EMAIL_ADDRESS>


161 symmetric key pr2

closes #161.  obsoletes #169
This PR addresses review requests in #169 and goes further to simplify and improve the implementation.
Heres a list of changes since #169
code:
 * simplified `UtxoNotifyMethod` to `OnChain`, `OffChain`
 * simplified `UtxoNotifcation` to `OnChain(_)`, `OffChain(_)`
 * removed `UtxoNotifyMethodSpecifier`
 * change logic in `TxOutput::auto()`
 * add `KeyType` enum to improve abstraction
 * refactor common key logic into address::common
 * simplify WalletState::scan_for_announced_utxos()
 * simplify WalletState::find_spending_key_for_utxo()
 * add WalletState::get_all_known_spending_keys()
 * new param `owned_utxo_output_method` for `generate_tx_outputs()`
 * new param `change_key` for `create_transaction()
 * new param `key_type` for `next_receiving_address()` rpc
 * neptune-cli generate-wallet: remove display of first wallet addr
   as it should not be considered special/only.

docs:
 * document keys and addresses in mdbook
 * document utxo notifications in mdbook
 * add/update type/method doc-comments
 * add some missing module doc-comments

tests:
 * consolidate all key/addr tests into address_type::test
 * same test logic applies to both symmetric and generation keys
 * make all key tests into proptests (symmetric and generation)
 * make transaction_output tests more comprehensive

Here's how requests were addressed:

Please add a page to the documentation covering symmetric keys for change UTXOs.

Added a page about "Keys and Addresses" and another about "Utxo Notifications".   Please review and feel free to edit, or send me your edits.

Avoid importing tools from generation_address in symmetric_key. Instead, factor them out to a helper module.

done.  added address::common module.

UtxoNotifierMethodSpecifier and UtxoNotifierMethod seem similar and I wonder if they cannot be merged.

I got rid of UtxoNotifierMethodSpecifier.  UtxoNotifyMethod and UtxoNotification are now simpler with just Onchain and OffChain variants.

Consider renaming SpendingKeyType to SpendingKey and generation_address::SpendingKey to generation_address::GenerationSpendingKey.

I forgot about this one.  There is also ReceivingAddressType/ReceivingAddress.  anyway, I can do that in a follow-up commit.  either to this PR, or after merging.

Please convert the randomized tests in symmetric_key.rs into proptests. Have a look in primitive_witness.rs if you need something to pattern match on. (I realize there are plenty of tests out there that are randomized with thread_rng but I should like to convert those to proptests at some point. Let's not add to that conversion workload.)

done.  all the tests for generation_address and symmetric have been moved into address_type and the same tests apply to both implementations.    all tests that were in generation_address are now proptests.

Please add an integration test (not sure that's the right word) whereby you spawn two global states, one of which is a premine recipient whose sends some money to the other node and gets some change, and verify that the change is being observed and recovered correctly, even if the node in question reboots and loses everything but the seed phrase.

ok, I missed this one too.   I will work on it tmw.
I'm making this a draft PR until the above two items are completed.

i think the build is failing in CI because of new rust 1.81.   the time crate is generating an error.   I will update to 1.81 and see if I can duplicate/fix.


Missing speakers and tracks color not reflected in session

Please compare the details of http://2016.opentechsummit.net/programm/ with http://fossasia.github.io/open-event-webapp/sessions.html
Several items are missing

[x] Names of speaker missing
[x] Colors of tracks not reflected in time field

Done here #612


pointer-events bug not mentioned

From what I can tell, if you set an iframe to pointer-events: none, you cannot get pointer events on any of its children, even if you set them to pointer-events: all. Maybe that's in the spec, but I don't know how to find it. This isn't mentioned on the pointer-events page: http://caniuse.com/#search=pointer-events.
This issue came up on Mac OSX 10.11, Chrome 55.0.2883.75.

I assume the pointer-events would go to the child document loaded within the iframe, (intentionally) not the parent document.

@lpd-au: Is this the behavior you're describing? https://jsfiddle.net/smy9oouj/3/ (try clicking on both halves of the iframe). The events are on the iframe's child element itself. I would expect the background to change when the lower half of the iframe is clicked, but not when the upper half of the iframe is clicked. Also, when the upper half is clicked, I'd expect the text color to turn white and a console message to be logged, which isn't the case.

Sorry I think I misunderstood what you were saying, you were going for something like this, right? https://jsfiddle.net/1oku60py/6/
Styles shouldn't inherit through iframes (excluding the defunct seamless version) so the root element of an iframe will already have pointer-events computed to auto, even if the iframe element itself has them set to none. I imagine the justification for the behaviour you see is that the iframe acts as a glorified blackbox UI widget, not a whitebox nested root node. Like eg an input element, if it doesn't receive pointer-events then it can't process them, which in this case means forwarding them into the child document.
This doesn't seem like a particularly good justification, though. The illusion/outcome that the parent page controls a css property of the child page must violate some separation principle. Though, if the above speculation is all correct, I question whether caniuse is the correct place to note it...

IE11 on Win7 does not support pointer-events: initial, while IE11 on Win10 does. pointer-events: visible shall be used instead in a non-SVG content. For SVG, its pointer-events: visiblePainted.
Just thought it's best to drop this in here as it's related.

@lpd-au: The behavior I was looking for was more like my example (except that pointer events would work on the internal elements of the iframe, as the css suggests). Your example, unfortunately, wasn't what I was looking for.
I don't know at this point if it belongs as a bug or what, but it at least seems like unexpected behavior and worth a note.
@thevictor13: Good to have the note. I think maybe you should make a new issue, though, because that detail doesn't really fit this title and so your note might not be noticed.


Assertion failed!

  That assertion was removed several releases ago.


west: update requirements.txt to avoid west 0.6.1

Update scripts/requirements.txt to use 0.6.2 or later (avoiding 0.6.1
that has an known issue)
Signed-off-by: David B. Kinder<EMAIL_ADDRESS>

@dbkinder I suppose we want this for 2.0.0, correct?

Given the discussions about west 0.6.1, it might indeed be good to get this into the 2.0.0 release. @mbolivar ?

Given the discussions about west 0.6.1, it might indeed be good to get this into the 2.0.0 release. @mbolivar ?

+1 FTR


Add license

Hello!
Once again I am super stoked about your work!
Thanks for sharing it.
What is missing is a license, so contributor's and leachers (;-)) alike know what they sign up for.
Best regards,
Tom

Solved via https://github.com/ria8651/alex/commit/0a1094bfc74c667f6a66db0b9a8db761d8f4309a
Thanks!


Add basic support for adding SVG pictures to docx files

See issues #351, #651, #659.

Hi @takis thanks for the improvement - for my SVG files produced by matplotlib there are relative scalings in the width and height attributes. I had to take the data from the viewbox attribute:
Scaling is not great in document, but maybe you know the cause?
Example svg header:
<svg baseProfile='full' height='100.000000%' version='1.1' viewBox='0.000000 0.000000 1240.000000 1753.000000' width='100.000000%' xmlns='http://www.w3.org/2000/svg' xmlns:xlink='http://www.w3.org/1999/xlink'>
in svg.py:
    @classmethod
    def _dimensions_from_stream(cls, stream):
        stream.seek(0)
        data = stream.read()
        root = ET.fromstring(data)
        # FIXME: The width could be expressed as '4cm'
        # See https://www.w3.org/TR/SVG11/struct.html#NewDocument
        width_str = root.attrib["width"]
        height_str = root.attrib["height"]
        if r'%' in width_str and r'%' in height_str:
            vb_lims = str(root.attrib["viewBox"]).split(' ')
            width_scale = float(width_str.strip(r'%')) * 0.01
            height_scale = float(height_str.strip(r'%')) * 0.01
            width = int(width_scale * float(vb_lims[2]))
            height = int(height_scale * float(vb_lims[3]))
        else:
            width = int(root.attrib["width"])
            height = int(root.attrib["height"])

        return width, height

Hi @takis, I'm new using docx (and python), and I'm tryng to load some SVG images in a word document, looking for that I found this, but try to replicate the code you were testing with and it doesn't work for me, I get the docx.image.exceptions.UnrecognizedImageError. So it isn't "included" in docx now? if not, is there a way for using your code? thanks in advance, and sorry if it's not a place for asking this, i'll remove the comment if needed.

This would be amazing if it could be merged into a new release. In the meantime, if somebody wants to play around with SVG files, I created a monkey patch just as was made in the case for EMF files: https://github.com/python-openxml/python-docx/pull/196#issuecomment-758974499. Just add the code from the gist below to a file called docx_svg_patch.py, and at the top of your own python script you have import docx_svg_patch. I haven't tested this extensively, and I am not sure how well this plays with other image types now, but it's at least a start.
Link to gist: https://gist.github.com/Kladdy/d3bdb9bbf2c38d4f194ea9a7904fc3f2

Hi @takis, I'm new using docx (and python), and I'm tryng to load some SVG images in a word document, looking for that I found this, but try to replicate the code you were testing with and it doesn't work for me, I get the docx.image.exceptions.UnrecognizedImageError. So it isn't "included" in docx now? if not, is there a way for using your code? thanks in advance, and sorry if it's not a place for asking this, i'll remove the comment if needed.

Hi @JaverHumberto, no, unfortunately, the code was not merged. I've created a new pull request and updated the code though. If you want to try it, you can use my fork for now:
https://github.com/takis/python-docx/

Hi @Kladdy
I've updated the pull request and I'm also still hoping that it will get merged one day.

Hi @goomesthiago
Unfortunately not, but I do try to keep my fork in sync with the main repository.


Appstudio update test-component-pac-kcal

Pipelines as Code configuration proposal
To start the PipelineRun, add a new comment with content /ok-to-test
For more detailed information about running a PipelineRun, please refer to Pipelines as Code documentation Running the PipelineRun
To customize the proposed PipelineRuns after merge, please refer to Build Pipeline customization

Pipelines as Code CI/test-component-pac-kcal-on-pull-request has successfully validated your commit.

StatusDurationName

✅ Succeeded
6 seconds
init

✅ Succeeded
20 seconds
clone-repository

✅ Succeeded
30 seconds
build-container

✅ Succeeded
19 seconds
deprecated-base-image-check

✅ Succeeded
19 seconds
inspect-image

✅ Succeeded
1 minute
clamav-scan

✅ Succeeded
3 minutes
clair-scan

✅ Succeeded
17 seconds
sbom-json-check

✅ Succeeded
15 seconds
label-check

✅ Succeeded
8 seconds
show-summary

✅ Succeeded
7 seconds
show-sbom

Pipelines as Code CI/test-component-pac-kcal-on-pull-request has successfully validated your commit.

StatusDurationName

✅ Succeeded
10 seconds
init

✅ Succeeded
13 seconds
clone-repository

✅ Succeeded
32 seconds
build-container

✅ Succeeded
22 seconds
inspect-image

✅ Succeeded
20 seconds
deprecated-base-image-check

✅ Succeeded
11 seconds
clair-scan

✅ Succeeded
33 seconds
clamav-scan

✅ Succeeded
10 seconds
sbom-json-check

✅ Succeeded
13 seconds
label-check

✅ Succeeded
8 seconds
show-sbom

✅ Succeeded
7 seconds
show-summary


Diagnostic output file

We've played with a lot of different diagnostic outputs printed to screen when sorting or building events. The percent of events successfully sorted, for example. I think @VinzenzBildstein has also implemented some PPG diagnostic output. I know there's already a way to print errors to a file, but I think we should consider developing a diagnostic output file so we don't just print this info to screen and then lose it.

Things that could be included: number of "corrupted" words, PPG patterns lost, network packets dropped.
The first is (I think) only calculated upon sorting, the network packet loss is calculated after sorting, so this might not be as simple as I world like. But if we're moving toward an automatic MIDAS->FragmentTree->AnalysisTree, automatic diagnostics would be helpful.

Do you want to store this in a text file? or did you want to write it in the fragment file? We can write a TSortLog to the fragment file and then have a print and WriteToText for it. However, depending on how out of hand we get with logging, this could have downsides.

I think in principle it would be better to store it in the root-file, that way you can never loose the information. Of course this means that we have to make sure that we limit the amount of diagnostics we write, we don't want to wait a long time for this to be written to file.

We will definitely need to limit the amount of diagnostics we write. Especially if we're storing it in the ROOT file though, we should try to avoid saving information that be extracted elsewhere. As an example, looking at the dropped channel IDs and the dropped network packets might be a better diagnostic than the percent of events that were written to file. Perhaps storing some information in the file and then developing a quick-running diagnostic script that prints information to screen or to a file is the way to go.

Okay, I've added a TDiagnostics class that has so far just a few diagnostics variables: number of good and bad fragments per detector type, min. and max. channel ID (per channel), number of hits per channel, min. and max. network packet ID, and number of network packets found.
It has a Print function that produces this output (for run 5023_001):
PPG cycle is 34500 ms long.
Found 7762403 network packets in range 6032415 - 13817921 => 99.7032 % packet survival.
detector type -3:       167166 good,          186 (0.111267 %) bad fragments.
detector type -2:          232 good,            4 (1.72414 %) bad fragments.
detector type  0:     11413012 good,        26172 (0.229317 %) bad fragments.
detector type  2:      3678635 good,         6353 (0.1727 %) bad fragments.
The class also has a Draw function, that so far simply draws the event survival rate (the number of hits in the channel divided by the max-min channel ID for that channel), the plot for run 5023_001 is attached.
The class stores the PPG cycle length right now, but I change that to just store a pointer to the PPG (and use the PPG functions for printing).

Just to clarify, this was all done on the multiset branch.

A random channel ID value outside of the usual range could reduce the
apparent event survival rate. I don't know if there's an easy way to get
around this though.
On Nov 14, 2015 7:04 PM, "Vinzenz Bildstein"<EMAIL_ADDRESS>wrote:

Just to clarify, this was all done on the multiset branch.
—
Reply to this email directly or view it on GitHub
https://github.com/GRIFFINCollaboration/GRSISort/issues/581#issuecomment-156774437
.

There was talk about putting a function into this to be able to generate a .dat file. That way we could have it accessed by a browser in the future... Say after a lazy-logger sort? This could be it's own issue though perhaps.

I've updated the *Diagnostics::WriteToFile functions (PR #823) which could be used to generate the .dat file. I think this can be closed now.


Priority Scheduling

Topic
About
Name
Label

Priority Scheduling
Priority scheduling is one of the most common scheduling algorithms in batch systems.
Manvitha  Chowdary Ramineni
Feature Request

Define you

[x] DevIncept Participants

Description

Priority Scheduling is a method of scheduling processes that is based on priority.
Process with the highest priority is to be executed first and so on.
In this algorithm, the scheduler selects the tasks to work as per the priority.

Please assign this issue to me @prathimacode-hub mam

Issue assigned. @manvitha3579

9th is the last date to accept PR's. If you wouldn't do it by then, obviously you can submit later but points won't be counted towards DCP program. @manvitha3579

Update? @manvitha3579

Time is up for the program. Unfortunately I have to remove the label but still you can submit the PR hopefully ASAP. @manvitha3579

Any update? @manvitha3579

Any update? @manvitha3579

Are you willing on this? Do let us know. Issue can't held for this long. If so, kindly intimate up with your work progress. It's been 15 long days since issue is assigned. @manvitha3579

Update please? @manvitha3579

So sorry mam. I was busy with my semester exams and placement. Will complete it soon.

Sure, but keep me updated. @manvitha3579

Update please? @manvitha3579

kindly assign this to me . I have an very efficient algorithm for this problem.

Issue assigned to @sajal-19


Adding upper cases

#sign-off

@outinyman : Thanks for your contribution! The author(s) have been notified to review your proposed change.


How to add ID to resolved custom scalar

How do I add optional Scalars['ID'] to resolved type?
Consider the following type definitions:
type User {
  id: ID!
  name: String!
}

type Asset {
  id: ID!
  uploader: User!
}

Currently, it generates:
interface User {
  id: Scalars['ID'];
  name: Scalars['ID'];
}

interface Asset {
  id: Scalars['ID'];
  uploader: User
}

What I want:
interface Asset {
  id: Scalars['ID'];
  uploader: ID | User
}

Why? because on the server-side, I might want to use this type before Asset.uploader is resolved to User
How do I achieve it? I feel like it should be a common use case, but didn't find a doc for it
Thanks in advance

You can override default types for scalars using scalars option. You can find the documentation below.
https://graphql-code-generator.com/docs/plugins/typescript#scalars-scalarsmap

Hi @ardatan I tried the option but it doesn't seem to work. Below is my config:
generates:
  src/gql/__generated__/types.ts:
    config:
      scalars:
        User: ID
    plugins:
      - 'typescript'

Seems similar bug happened before: https://github.com/dotansimha/graphql-code-generator/issues/2342

@zicodeng it seems like you are using it in a wrong way.
If that's because of resolvers, use typescript-resolvers and mappers config.


Added kickofflabs entry

Visit this URL to cross-check https://kickoffpages.com/no-page-exists

I added this entry but still the tool does not finds the subdomain.
I am able to check it manually

I added the cname entry which works with SubOver but still not working here


Implement Component Renderer.

We have a poor component render.
So we have to implement a simple component renderer that allow us to render components inside components.
The second implementation must be a soft implementation, in the future the core will be more complex and optimized.

Implemented.
Check #5


Feature/dependency update

Updated Apache Commons Codec from 1.11 -> 1.13

Fixes Apache Commons Invalid Base32 String Tunneling Weakness.

Updated Logback from 1.2.3 -> 1.2.7

Fixes some Logback Config File Field Server-side Request Forgery (SSRF) weaknesses.

Additional Notes
Logback 1.2.7 still has more issues with request forgery, so we should update to 1.3.0 when it gets a full release (it is still 1.3.0-alpha).
The Apache Commons Compress dependency has a known security risk with an exception DDOS exploit. The newest release does not fix this issue, so we should keep an eye out for an update.

I have updated all the repos with different branches.
https://github.com/networknt/light-config-test/issues/655


[doc] Document rustc type privacy bug

See #1292
Makes progress towards #671

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 88.11%. Comparing base (73b15e5) to head (c5caa45).

Additional details and impacted files
@@           Coverage Diff           @@
##             main    #1734   +/-   ##
=======================================
  Coverage   88.11%   88.11%
=======================================
  Files          16       16
  Lines        5720     5720
=======================================
  Hits         5040     5040
  Misses        680      680

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


Replace CGDisplayIOServicePort with a workaround implementation

This could be cleaned up and refined a bit by comparing more display
attributes when available, but it gets the job done.

Lion is also now unsupported even for security updates from Apple.

Steam still supports 10.6 and the amount of effort required for GLFW to do so is still just a few isolated ifdefs. If it becomes an issue or when Steam removes support I'll drop those lines. Support for 10.6 isn't holding the code back, as far as I can tell. The code uses several of 10.7 features and at least one symbol added in 10.10.
Supporting Windows XP is far more, far nastier work.

So, #448 might be the first good argument for dropping 10.6 support.

I understand the desire to want to keep Snow Leopard support, but no one should be using that OS anymore. It's vulnerable to Heartbleed and about 50 other major vulnerabilities that have been patched on OS X since it was supported. World of Warcraft: The largest MMO on the planet doesn't even support Snow Leopard. :)

I don't have any particular emotional attachment to any version after 10.3; it's just that the effort involved to keep supporting a version still supported by Steam used to be tiny and thus worth it.

Why don't we just check the operating system and if it's Snow Leopard it can execute the legacy code, however if it's running a newer version it can run this new implementation?


Add documentation for property/flaky tests

This PR adds documentation on how to deal with property/flaky tests for Guardian.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

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

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
0

Relevant Lines:
0

💛  - Coveralls


true stream parsing

Hi @vovapolu . I heard you are hacking on FastParse this summer. One thing that is similar to the changes you are doing would be support for true stream parsing. I actually opened https://github.com/lihaoyi/fastparse/pull/39 for this last year. It worked, but we never investigated the performance implications. There may be some refinements for speedup needed to avoid the control flow via exceptions. Maybe you want to take a crack at it :)?
One concrete use case I have personally would be improving Scala error messages with a streaming error message parser. Combining https://github.com/cvogt/cbt/ with https://github.com/cvogt/scalac-cosmetics/

This is happening here #97

awesome :)!!!

Last changes brought the ability to parse streaming data, though it's not perfect and even unstable, I think this issue isn't relevant yet.

@vovapolu nice :). Is there a trajectory to stabilize it?

I'm probably going to take a crack at optimizing/fully-understanding it at the end of the summer after GSOC, after which I'll publish the next stable release containing the summer's worth of changes (binary & streaming parsing)
@cvogt If you have time to publishLocal it and see how it works for your use cases right now, that would help a lot 😄

probably not any time soon, but might do a follow up pr whenever I get to it in case something is missing


Not specifying direction of inputs, could be detected by tester

There are situation when the directions of io are not specified that the tester does not detect any of the inputs.  I think the tester should throw consider throwing an exception when no inputs are detected.
Alternatively, the tester should assume that unspecfied directions are outputs, which seems to be the current assumption within chisel3 and firrtl

Obviated by new IO wrapper


More tweaks for modernization

Follows up #2 to add a few more tweaks for modernization:

Move GitHub Actions configuration to workflows directory so it's
picked up by GitHub correctly.

Update GitHub Action versions of checkout and setup-go. Target
stable version of Go. Run on pushes to master or pull requests.

Add instructions to README on how to cut a release and run tests for
development purposes.

Add a changelog.

cc @rzhade3

Cut release v0.1.0.


tests/e2e: Jenkins to GHA migration for SEV and SNP

The ccruntime-pr.yaml file has been modified and works only for amd specific tests currently. Work adds on to operator pull 295

@portersrc @fitzthum  DCO passing finally.

Ok, higher level question here. Maybe @wainersm will have some good advice.
Do you think we should have a separate workflow for SEV? I'm not sure if this is going to scale very well as we introduce more tests. Can we instead modify the existing e2e workflow to add SEV/SNP support?

Ok, higher level question here. Maybe @wainersm will have some good advice.
Do you think we should have a separate workflow for SEV? I'm not sure if this is going to scale very well as we introduce more tests. Can we instead modify the existing e2e workflow to add SEV/SNP support?

Well the workflow should be similar, shouldn't it? Only the set of tests and perhaps some setup parts will differ and that should be part of the scripts but IMO the workflows should be shared as much as possible.

See https://github.com/confidential-containers/operator/pull/383/files for an example


Add type hinting to train_batch function

trainer.py's train_batch function has a number of arguments, it would be nice if each of these had an associated type hint, eg bool, int, EmaModel, etc.
def train_batch(
    model,
    sample,
    optimizer,
    scheduler,
    logger,
    args,
    grad_scaler=None,
    accumulate_gradient=False,
    num_grad_accumulations=1,
    ema_model=None,
    loss_factor=1,

I can work on this!

Some typing libraries are missing. I can work on it.

#56


Release v0.2.0

Let's release next preview version v0.2.0. I think it would be great to release every 10 indicators with bumping up minor version.

[x] Add 10+ new indicators.
[x] Review documentation and docstrings(#80).
[x] Final sanity check and code style.
[x] Release to PyPI.
[x] apply release description to tag

Let's release next preview version v0.2.0. I think it would be great to release every 10 indicators with bumping up minor version.
(Still 2 indicators left to implement for the next version.)

Yah, that sounds like a good plan + take care of any general improvements along the way.

@DaveSkender  I mis-counted newly added indicators. It's already 10. If you have time, please check the docs for new indicators :)
I'll have a sanity check and add some inline docstrings.

Anything else to do?

Yeah, some style checks left, with Pylint. I'll leave a comment when it's done.

Cool.  Add PyLint to the build, if helpful.  Also, if that will be the last PR we’ll Ned to remember to add the version increment command in the PR merge comment.

Okay, 104 will be the last PR for this version.

Everything is done. Let's release!👍

Do you want to create the release note?

Do you want to create the release note?

Yep, I'd love to. I'll do that tomorrow.

Not sure if you've done this before, basically you convert the v0.2.0 tag into a release, here:
https://github.com/DaveSkender/Stock.Indicators.Python/releases

@DaveSkender  Thank you for letting me know. I've just written release note!

Very nice, well done!  From the emoji, looks like you made some people quite happy.

lol, I forced them to click.


Error when running the example

When following the README example, I ran into an issue when running the example mgf file.
I used the following command: python -m PrimeNovo.PrimeNovo --mode=denovo --peak_path=data/bacillus.10k.mgf --model=data/model_massive.ckpt
And this gave me the following error:
Traceback (most recent call last):
  File "/home/xxxx/xxxx/envs/PrimeNovo2/lib/python3.10/runpy.py", line 196, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/home/xxxx/xxxx/envs/PrimeNovo2/lib/python3.10/runpy.py", line 86, in _run_code
    exec(code, run_globals)
  File "/home/xxxx/pi-PrimeNovo/PrimeNovo/PrimeNovo.py", line 211, in <module>
    main()
  File "/home/xxxx/xxxx/envs/PrimeNovo2/lib/python3.10/site-packages/click/core.py", line 1130, in __call__
    return self.main(*args, **kwargs)
  File "/home/xxxx/xxxx/envs/PrimeNovo2/lib/python3.10/site-packages/click/core.py", line 1055, in main
    rv = self.invoke(ctx)
  File "/home/xxxx/xxxx/envs/PrimeNovo2/lib/python3.10/site-packages/click/core.py", line 1404, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/home/xxxx/xxxx/envs/PrimeNovo2/lib/python3.10/site-packages/click/core.py", line 760, in invoke
    return __callback(*args, **kwargs)
  File "/home/xxxx/pi-PrimeNovo/PrimeNovo/PrimeNovo.py", line 202, in main
    writer.save()
AttributeError: 'NoneType' object has no attribute 'save'

Sorry for this, we have replace the writer object with manual txt output file, so simply delete this line "writer.save()" fix the error. We have fix the error already, you can pull the GitHub code again and use it now!
Also, de novo mode now will output a denovo.txt file at your current directory, containing predictions results. Each line in this txt file has: (title (true label if given), model prediction, charge, confidence score (from 0-1)). Let us know if it works on your end!


Push as SomeWeekendReadingEditor

How to do pushes from my laptop, when SomeWeekendReading now owns it?  Supply SWR
credentials on command line somehow?  (And then delete myself as a collaborator.)
Looks related to the staticman bot pushing comments into the repo with a personal
access token, so maybe solve the comment problem first?
https://stackoverflow.com/questions/29776439/username-and-password-in-command-for-git-push
This prompts for the password:
git push<EMAIL_ADDRESS>
ALSO: https://www.appveyor.com/docs/how-to/git-push/

Done.


cargo test passes, cargo test -p glyphs-reader fails

Initially thought it was just my branch but it happens on main too

Updating to kurbo 0.9.3 w/https://github.com/linebender/kurbo/pull/266 should fix.


work on issue #86 UI issue in activity_course_detail

NOTE: Please review the pull request process before opening your first PR: https://github.com/WikiEducationFoundation/apps-android-wikiedudashboard/blob/master/CONTRIBUTING.md#pull-request-process
What this PR does
< describe the purpose of this pull request and note the issue it addresses >
Screenshots
Before:
< add a screenshot of the UI before your change >
After:
< add a screenshot of the UI after your change >
Open questions and concerns
< anything you learned that you want to share, or questions you're wondering about related to this PR >

hey @MarinaTaran  kindly read through the PR process and restructure your PR and also figure out what the conflicts

After merging #86 ,there is a minor UI issue in activity_course_detail, we are unable to see the top layout of fragment, it is getting hidden below the toolbar, tablayout.
befor changes

after changes

in fork we still have relativelayout ,but in "code" it is constraintlayout,so when i take fork I change relative to constraint and when i push i have conflict

in fork we still have relativelayout ,but in "code" it is constraintlayout,so when i take fork I change relative to constraint and when i push i have conflict

how is that possible, well i think everything is ok now change the PR title too to be related to the issue

I see only 3 whitespaces are added in this PR. Correct me if I am wrong.

@MarinaTaran  do you mind if I fix this?

@ujjwalagrawal17  what does it means  3 whitespaces

Please check the changes made by you once.

@kulloveth yes,why not

but still,I want to ask when I take fork I have inside code like this

and we have originaly such a code

is this posible that this dose in my PR conflict?

not relevant now.


It is unclear and surprising that --var flag values are directly interpreted as YAML

When passing in something like --var foo=5.0 it is surprising that the 5.0 is interpreted as an integer and that a template like:
favorite_value: "((foo))"

becomes
favorite_value: "5"

and the ".0" is lost for my string.
It is also surprising that something like --var "foo={space: &place cowboy, home: *place}" becomes:
favorite_value:
  space: cowboy
  home: cowboy

I would like this to be less surprising by either a change to the behavior (e.g. passing values around as strings so that the final interpretation of favorite_value: ((foo)) and favorite_value: "((foo))" can behave differently) or a clarification in the documentation, such as in the --help text.

even if we change --var arg behaviour down the line yaml processing will strip off .0 during serialization/deserialization operations.
will add something to the help text.

Sounds good to me, thanks!

Closing this due to inactivity. Please feel free to reopen if you have further questions.