[WIP] - Debugger Transport APIs and Zephyr port

This is patch to tackle issue #2229, basically we want the ability to have debugger support different platforms and different transports.
The current debugger implementation only supports BSD sockets, and it's not portable to different OSes that have different platform APIs.  Besides, other platforms may want to use another transport layer like USB or Bluetooth instead of TCP sockets.  The goal is to create a generic transport interface that different platforms can be used, and provide the actual implementation for running on their devices.  This patch provides a struct that defines the function signature that each transport can be used to register their own implementation of the socket APIs using the jerry_port_xxx interface and a Zephyr port is provided as a sample.
This is a WIP patch and a reference implementation, but I would like use this as a starting point for discussion on how to improve the APIs from here, would like to have feedbacks from @zherczeg and @martijnthe and JerryScript team after reviewing them.

@jimmy-huang some builds are failing (click "Details" to learn more) ^^^

@zherczeg could you take a look at the design?

JERRY_DEBUGGER_INIT_SEND_MESSAGE
JERRY_DEBUGGER_SET_SEND_MESSAGE_SIZE_FROM_TYPE
JERRY_DEBUGGER_SET_SEND_MESSAGE_SIZE

jerry_debugger_accept_connection
jerry_debugger_close_connection
jerry_debugger_send
jerry_debugger_receive

jerry_debugger_send_header_t

It seems these types/functions are used by the debugger. If we want to stick to the websocket package format, perhaps the first step would be to move certain of these types into the main debugger, reducing  the content of debugger-ws.h as much as possible. If not, the transport system must provide a way to provide these declarations.

By the way the send / receive already working in different ways, since the send aware of the low-level websocket header format while it is stripped from the receive part. Perhaps the JERRY_DEBUGGER_INIT_SEND_MESSAGE could be removed first, and moved internally to jerry_debugger_send in debugger-ws.c. One less macro to worry about.

Re. keeping websocket packet framing:
I'm OK with either, keeping it or moving it out. I do think that it's a tad bit wasteful / annoying if the transport itself also (inherently) takes care of packet framing (I'm thinking about BLE for example where every byte saved in the air is important).
It was just your past comment that made me take the initial position of "OK the websocket framing is part of the JrS debug protocol".
If we decide to move it out, then I agree, there's quite a bit of rework needed to separate the WS related stuff out and into the transport side of the fence.
If we decide to keep WS and regard it as part of the JrS debug protocol, I'm not sure why it's needed to refactor the debugger-ws.c/debugger.c split in order to progress with the transport layer abstraction. IMHO, cleaning up those files would be better off as a separate PR.
@jimmy-huang thoughts?
@zherczeg So it sounds like a decision needs to be made about "websocket framing is part of JrS debug protocol": yes or no. Any other people that need to chime in to help make that decision?

@martijnthe Yeah, personally, i rather keep the WS at least for now, because initially I think most of the platforms will just re-use the same WS protocol, and like you said, it's a lot of work for each port to add these WS.   I think the WS and both the TCP socket can be consider as a transport, so for now if we just move the TCP logic into a tcp transport, then later we can then move the WS into a separate transport as well.  But I am okay with either as well.

I would first remove as much macros / types from debugger-ws.h as possible. Probably in separate PR-s first. JERRY_DEBUGGER_INIT_SEND_MESSAGE could go away easily (send should write this byte). The JERRY_DEBUGGER_SET_SEND_MESSAGE_SIZE_FROM_TYPE and
JERRY_DEBUGGER_SET_SEND_MESSAGE_SIZE macros probably could go away by adding a size parameter to send. Basically the transport protocol should specify how much (maximum) bytes should be reserved for the header in the send buffer. This should be a constant of course (if less bytes are needed for the actual message, just internally adjust the start before sending the packet).

@zherczeg where does jerry_debugger_send_header_t go?  Should it be moved to debugger.h? or it's a internal thing that's in debugger-ws.c?  I am guessing the former?

@zherczeg I submitted another patch #2262 to remove some of these macros.  Is the goal here to make the debugger-ws.c as the default transport and remove all the macros and structurs in debuggr-ws.h.  What about these structs?
jerry_debugger_send_header_t
jerry_debugger_receive_uint8_data_part_t
jerry_debugger_uint8_data_t

Basically the transport protocol should specify how much (maximum) bytes should be reserved for the header in the send buffer. This should be a constant of course (if less bytes are needed for the actual message, just internally adjust the start before sending the packet). The size passed to send excludes this amount of course.

@jimmy-huang @zherczeg Alternative idea: instead of letting the transport specify the max header size, how about if the debugger instead would ask the transport for a pointer to a send buffer? The transport itself would take care of reserving space for a header. In case sending happens async, it could also save a copy to another buffer + lower the peak memory usage a little (perhaps not relevant though). Downside is that getting a buffer would become a function call instead of just getting a pointer + offset from the context, which in the simplest of projects would be at a fixed memory location.
I'm not feeling strongly about either, but wanted to share the idea.

@martijnthe I've moved the generic debugger logic into the debugger.c so the transport layer doesn't have to depend on any of the internal context.  I've try to remove as many dependencies from the transport except for as the jerry_debugger_compute_sha1(), which I think it's okay to leave it as is, and other platforms can build with it if needed since it is not really platform-specific.  In ZJS, I have another patch that basically ports the websocket transport layer to Zephyr as you can see here https://github.com/intel/zephyr.js/pull/1865

I guess there are a little more refactoring needed for the transport layer as it's calling internal APIs like JERRY_CONTEXT, so those would needed be moved out of there as well.

This is the next step (patch). We need to invent something for that.

@zherczeg I am passing the buffer to the transport layer, the debugger_receive () is actually a little tricky as it has to jerry_debugger_process_message () while keeping track of the offset of the buffer, so I had to pass that to the transport layer and have it updated as well,  see @f66f0b48859f8dcb8ca1adf78129d39b91895b87

What about using calls to the debugger to set the global variables? This way the transport layer can set variables without access to the global variables. It would be good to do in a separate patch.

Passing the receive buffer to the transport to write the received data into is seems quite natural and logical to me actually. Updating the offset seems awkward to me, I left a comment on a suggestion for a nicer solution.
@zherczeg I think this is getting close to being done. Can you take another serious look?

@martijnthe yeah, when i tried to refactor it, it was a little awkward, since I wasn't really sure that loop to constantly adjust the offset to the receive buffer was part of the debugger protocol or part of the websocket protocol, and I trying to preserve the originally behavior without breaking the core logic.  I am pretty sure I can enhance it a bit, maybe if @zherczeg can take a look at it and see what the receive API should look like, then I can adapt it to use that API?

have multiple transports at the same time? Like what @martijnthe described?

I think only one can be "actively" used at the same time. What we would like for our use case is be able to switch between transports (i.e. USB vs BLE) w/o recompiling anything. In other words, at runtime decide what transport to pass into jerry_debugger_init.

@jimmy-huang I would not use .something fields. Simply create some functions such as jerry_debugger_set_transmit_sizes with 3 arguments. Such as @martijnthe said, we should not be able to switch transport after it is set for a jerry instance. I would like to some suggestions how could we remove jcontext.h dependency from debugger-ws.c and do it in a separate patch.

@zherczeg

I would like to some suggestions how could we remove jcontext.h dependency from debugger-ws.c and do it in a separate patch.

I'm not sure if I understand. This PR removes the jcontext.h dependency from debugger-ws.c already? Would you like to see this PR split in 2 separate ones? If so, what should be left out?
Please clarify. Thank you.

@zherczeg @martijnthe Updated with jerry_debugger_set_transmit_sizes function

@zherczeg Can take take a another look at the patch?

The problem is not with the patch. The problem lies in nicely restructuring the debugger interface. I spent some hours to decouple the ws part from jcontext, but I was not satisfied with the results. It worked, but the code was ugly. Unfortunately this must be the first step. So this is the challenge here. If you have time, you can try it.

@zherczeg Ok, that's essentially what I am doing with one of the commits, so I separate it out as a separate patch, maybe this is what you are looking?
https://github.com/jimmy-huang/jerryscript/tree/refactor-ws

Not exactly. I would like to be able to chain this at the top of other interfaces, e.g. tcp. Maybe move it to some jerry extension or port. I am not sure.

@zherczeg @akosthekiss Thanks for the feedback, been out for a while and just got back from vacation.  We actually have a work-around building debugger on top of Zephyr's native posix network stack, since they are almost identical.  So in our project, we have this custom header that get injected when debugger is turned on.  I can probably submit a patch to the zephyr target as well, is this something you guys want? Since at this point, we don't need to support other transports besides tcp.  This will not have any changes on the API too.
https://github.com/intel/zephyr.js/blob/master/src/jerry-port/arpa/inet.h

Unfortunately I have no time to work on this at the moment. The whole debugger interface needs a major redesign to satisfy all requirements. I would recommend to use your workaround until we can do this.

https://github.com/zherczeg/jerryscript/tree/debugger_transport
Something to start with. It is far from compiling though. This will take a long time to finish.

Please check #2421

Hi @jimmy-huang, after #2426 lands you can freely add your low-level transmission protocols to JerryScript. Please check the patch if you have time.

@zherczeg Yeah, thanks for the heads up, I am actually ramping up on another project atm, but I'll try to look at this later when I have time, if you think i should close this PR first, I am okay with it and I'll re-submit a pr later.

closing


Expose Amazon Bedrock amazon-bedrock-invocationMetrics in response

Feature request
Amazon Bedrock now provides some useful metrics when it has finished:
"completion":"Response from Bedrock...","stop_reason":"stop_sequence","stop":"\n\nHuman:","amazon-bedrock-invocationMetrics":{"inputTokenCount":16,"outputTokenCount":337,"invocationLatency":4151,"firstByteLatency":136}}
It would be good to expose these via LangChain, similar to how OpenAI API provides them.
Motivation
To make it easier to calculate the cost of Amazon Bedrock queries.
Your contribution
I'm happy to test any solution. I'd look to existing developers to guide us how best to expose them.

Did you have something like this in mind https://python.langchain.com/docs/modules/model_io/llms/token_usage_tracking?

Yep. Something like that.

This issue is important. Langchain api should not thrown out useful bedrock data.


Requesting Http proxy and it returns -106

Question
I started the admin and proxy server successfully, but it returned an error  when I sent a request to the server like:
{   "code": -106,   "message": "未能找到合适的调用url,请检查你的配置!",   "data": null }
here is my  configuaration:
`
spring:
main:
allow-bean-definition-overriding: true
soul:
http:
adminUrl: http://localhost:9095
port: 9195
contextPath: /http
appName: proxyee
full: false
`
I try to find the answer why this problem occured, I saw

I think this may be the answer, please help me  to fix it or tell me how can I fix it, thanks:)
Please pay attention on issues you submitted, because we maybe need more details.
If no response anymore and we cannot reproduce it on current information, we will close it.

check soul-admin divide plugin config, do you config selector and rule, if you selector conditions is uri, please use 'match' type /http/**

check soul-admin divide plugin config, do you config selector and rule, if you selector conditions is uri, please use 'match' type /http/**.
if can not work,please show your soul-admin config

Here is my soul-admin config, I don't  configure anything.

https://dromara.org/zh/projects/soul/quick-start-http/


Question on UCCSD with VQEClient/VQEProgram runtime

Environment

Qiskit Nature version: 0.2.2
Python version: 3.9.7
Operating system: x86_64 GNU/Linux

What is happening?
I tried to set up UCCSD ansatz to for VQEProgram, but the ansatz failed to be transpiled in the remote. In particular, I am seeing the following exception being returned:
qiskit.exceptions.QiskitError: "Cannot unroll the circuit to the given basis, [...].
Instruction circuit-36_dg not found in equivalence library and no rule found to expand."

 Full traceback from the remote runtime
Unable to retrieve job result. Job c6kq1hmgkavn0ge2re20 has failed:
2021-12-03T04:45:09.200181663Z /usr/local/lib/python3.8/site-packages/sympy/core/expr.py:2451: SymPyDeprecationWarning:
2021-12-03T04:45:09.200348792Z
2021-12-03T04:45:09.200524237Z expr_free_symbols method has been deprecated since SymPy 1.9. See
2021-12-03T04:45:09.200682015Z https://github.com/sympy/sympy/issues/21494 for more info.
2021-12-03T04:45:09.200831012Z
2021-12-03T04:45:09.200966077Z   SymPyDeprecationWarning(feature="expr_free_symbols method",
2021-12-03T04:45:09.594976991Z concurrent.futures.process._RemoteTraceback:
2021-12-03T04:45:09.595027186Z """
2021-12-03T04:45:09.595041516Z Traceback (most recent call last):
2021-12-03T04:45:09.595041516Z   File "/usr/local/lib/python3.8/concurrent/futures/process.py", line 239, in _process_worker
2021-12-03T04:45:09.595041516Z     r = call_item.fn(*call_item.args, **call_item.kwargs)
2021-12-03T04:45:09.595041516Z   File "/usr/local/lib/python3.8/concurrent/futures/process.py", line 198, in _process_chunk
2021-12-03T04:45:09.595041516Z     return [fn(*args) for args in chunk]
2021-12-03T04:45:09.595041516Z   File "/usr/local/lib/python3.8/concurrent/futures/process.py", line 198, in <listcomp>
2021-12-03T04:45:09.595041516Z     return [fn(*args) for args in chunk]
2021-12-03T04:45:09.595041516Z   File "/usr/local/lib/python3.8/site-packages/qiskit/tools/parallel.py", line 93, in _task_wrapper
2021-12-03T04:45:09.595041516Z     return task(value, *task_args, **task_kwargs)
2021-12-03T04:45:09.595041516Z   File "/usr/local/lib/python3.8/site-packages/qiskit/compiler/transpiler.py", line 380, in _transpile_circuit
2021-12-03T04:45:09.595041516Z     result = pass_manager.run(
2021-12-03T04:45:09.595041516Z   File "/usr/local/lib/python3.8/site-packages/qiskit/transpiler/passmanager.py", line 216, in run
2021-12-03T04:45:09.595041516Z     return self._run_single_circuit(circuits, output_name, callback)
2021-12-03T04:45:09.595041516Z   File "/usr/local/lib/python3.8/site-packages/qiskit/transpiler/passmanager.py", line 272, in _run_single_circuit
2021-12-03T04:45:09.595041516Z     result = running_passmanager.run(circuit, output_name=output_name, callback=callback)
2021-12-03T04:45:09.595041516Z   File "/usr/local/lib/python3.8/site-packages/qiskit/transpiler/runningpassmanager.py", line 123, in run
2021-12-03T04:45:09.595045032Z     dag = self._do_pass(pass_, dag, passset.options)
2021-12-03T04:45:09.595052061Z   File "/usr/local/lib/python3.8/site-packages/qiskit/transpiler/runningpassmanager.py", line 154, in _do_pass
2021-12-03T04:45:09.595058972Z     dag = self._run_this_pass(pass_, dag)
2021-12-03T04:45:09.595065567Z   File "/usr/local/lib/python3.8/site-packages/qiskit/transpiler/runningpassmanager.py", line 166, in _run_this_pass
2021-12-03T04:45:09.595072169Z     new_dag = pass_.run(dag)
2021-12-03T04:45:09.595078798Z   File "/usr/local/lib/python3.8/site-packages/qiskit/transpiler/passes/basis/unroll_custom_definitions.py", line 86, in run
2021-12-03T04:45:09.595086892Z     raise QiskitError(
2021-12-03T04:45:09.595094816Z qiskit.exceptions.QiskitError: "Cannot unroll the circuit to the given basis, ['ccx', 'cp', 'cswap', 'csx', 'cu', 'cu1', 'cu2', 'cu3', 'cx', 'cy', 'cz', 'delay', 'diagonal', 'h', 'id', 'initialize', 'mcp', 'mcphase', 'mcr', 'mcrx', 'mcry', 'mcrz', 'mcswap', 'mcsx', 'mcu', 'mcu1', 'mcu2', 'mcu3', 'mcx', 'mcx_gray', 'mcy', 'mcz', 'multiplexer', 'p', 'pauli', 'r', 'rx', 'rxx', 'ry', 'ryy', 'rz', 'rzx', 'rzz', 's', 'sdg', 'swap', 'sx', 'sxdg', 't', 'tdg', 'u', 'u1', 'u2', 'u3', 'unitary', 'x', 'y', 'z', 'kraus', 'roerror', 'save_amplitudes', 'save_amplitudes_sq', 'save_density_matrix', 'save_expval', 'save_expval_var', 'save_probabilities', 'save_probabilities_dict', 'save_stabilizer', 'save_state', 'save_statevector', 'save_statevector_dict', 'set_density_matrix', 'set_stabilizer', 'set_statevector', 'snapshot']. Instruction circuit-36_dg not found in equivalence library and no rule found to expand."
2021-12-03T04:45:09.595118810Z """
2021-12-03T04:45:09.595125597Z
2021-12-03T04:45:09.595148382Z The above exception was the direct cause of the following exception:
2021-12-03T04:45:09.595159003Z
2021-12-03T04:45:09.595170745Z Traceback (most recent call last):
2021-12-03T04:45:09.595182298Z   File "/code/program_starter.py", line 78, in <module>
2021-12-03T04:45:09.595192361Z     final_result = main(backend, messenger, **user_params)
2021-12-03T04:45:09.595203801Z   File "/code/program.py", line 1072, in main
2021-12-03T04:45:09.595374269Z     result, history = vqe.compute_minimum_eigenvalue(operator, aux_operators)
2021-12-03T04:45:09.595385749Z   File "/code/program.py", line 904, in compute_minimum_eigenvalue
2021-12-03T04:45:09.595395474Z     opt_params, opt_value, nfev = optimizer.optimize(
2021-12-03T04:45:09.595401207Z   File "/code/program.py", line 646, in optimize
2021-12-03T04:45:09.595407494Z     return self._minimize(objective_function, initial_point)
2021-12-03T04:45:09.595413165Z   File "/code/program.py", line 525, in _minimize
2021-12-03T04:45:09.595417922Z     get_learning_rate, get_perturbation = self.calibrate(loss_callable, initial_point)
2021-12-03T04:45:09.595424860Z   File "/code/program.py", line 325, in calibrate
2021-12-03T04:45:09.595434722Z     delta = loss(initial_point + c * pert) - \
2021-12-03T04:45:09.595436303Z   File "/code/program.py", line 511, in loss_callable
2021-12-03T04:45:09.595451383Z     return self._sampler.convert(loss, params=value_dict).eval().real
2021-12-03T04:45:09.595461759Z   File "/usr/local/lib/python3.8/site-packages/qiskit/opflow/converters/circuit_sampler.py", line 218, in convert
2021-12-03T04:45:09.595474656Z     sampled_statefn_dicts = self.sample_circuits(circuit_sfns=circs, param_bindings=p_b)
2021-12-03T04:45:09.595516125Z   File "/usr/local/lib/python3.8/site-packages/qiskit/opflow/converters/circuit_sampler.py", line 329, in sample_circuits
2021-12-03T04:45:09.595528665Z     results = self.quantum_instance.execute(
2021-12-03T04:45:09.595541801Z   File "/usr/local/lib/python3.8/site-packages/qiskit/utils/quantum_instance.py", line 398, in execute
2021-12-03T04:45:09.595546844Z     circuits = self.transpile(circuits)
2021-12-03T04:45:09.595546844Z   File "/usr/local/lib/python3.8/site-packages/qiskit/utils/quantum_instance.py", line 345, in transpile
2021-12-03T04:45:09.595605722Z     transpiled_circuits = compiler.transpile(
2021-12-03T04:45:09.595622338Z   File "/usr/local/lib/python3.8/site-packages/qiskit/compiler/transpiler.py", line 293, in transpile
2021-12-03T04:45:09.595640749Z     circuits = parallel_map(_transpile_circuit, list(zip(circuits, transpile_args)))
2021-12-03T04:45:09.595654453Z   File "/usr/local/lib/python3.8/site-packages/qiskit/tools/parallel.py", line 164, in parallel_map
2021-12-03T04:45:09.595654453Z     raise error
2021-12-03T04:45:09.595696117Z   File "/usr/local/lib/python3.8/site-packages/qiskit/tools/parallel.py", line 154, in parallel_map
2021-12-03T04:45:09.595709633Z     results = list(future)
2021-12-03T04:45:09.595715634Z   File "/usr/local/lib/python3.8/concurrent/futures/process.py", line 484, in _chain_from_iterable_of_lists
2021-12-03T04:45:09.595724927Z     for element in iterable:
2021-12-03T04:45:09.595732138Z   File "/usr/local/lib/python3.8/concurrent/futures/_base.py", line 619, in result_iterator
2021-12-03T04:45:09.595740561Z     yield fs.pop().result()
2021-12-03T04:45:09.595740561Z   File "/usr/local/lib/python3.8/concurrent/futures/_base.py", line 437, in result
2021-12-03T04:45:09.595740561Z     return self.__get_result()
2021-12-03T04:45:09.595740561Z   File "/usr/local/lib/python3.8/concurrent/futures/_base.py", line 389, in __get_result
2021-12-03T04:45:09.595740561Z     raise self._exception
2021-12-03T04:45:09.595740561Z qiskit.exceptions.QiskitError: "Cannot unroll the circuit to the given basis, ['ccx', 'cp', 'cswap', 'csx', 'cu', 'cu1', 'cu2', 'cu3', 'cx', 'cy', 'cz', 'delay', 'diagonal', 'h', 'id', 'initialize', 'mcp', 'mcphase', 'mcr', 'mcrx', 'mcry', 'mcrz', 'mcswap', 'mcsx', 'mcu', 'mcu1', 'mcu2', 'mcu3', 'mcx', 'mcx_gray', 'mcy', 'mcz', 'multiplexer', 'p', 'pauli', 'r', 'rx', 'rxx', 'ry', 'ryy', 'rz', 'rzx', 'rzz', 's', 'sdg', 'swap', 'sx', 'sxdg', 't', 'tdg', 'u', 'u1', 'u2', 'u3', 'unitary', 'x', 'y', 'z', 'kraus', 'roerror', 'save_amplitudes', 'save_amplitudes_sq', 'save_density_matrix', 'save_expval', 'save_expval_var', 'save_probabilities', 'save_probabilities_dict', 'save_stabilizer', 'save_state', 'save_statevector', 'save_statevector_dict', 'set_density_matrix', 'set_stabilizer', 'set_statevector', 'snapshot']. Instruction circuit-36_dg not found in equivalence library and no rule found to expand."

How can we reproduce the issue?

 Here's my main setup (click to expand)
from qiskit_nature.drivers import Molecule
from qiskit_nature.drivers.second_quantization import PSI4Driver

molecule = Molecule(geometry=
    [['H', [0., 0., 0.]],
     ['H', [0., 0., 0.735]]],
    charge=0, multiplicity=1)

basis = "sto-3g"
driver = PSI4Driver.from_molecule(molecule=molecule, basis=basis)

from qiskit.utils import QuantumInstance
from qiskit import IBMQ

IBMQ.load_account()
provider = IBMQ.get_provider(group='open')
backend = provider.get_backend("ibmq_qasm_simulator")
qins = QuantumInstance(
    backend=backend,
    shots=1024,
    optimization_level=2,
)

# VQEClientUCCFactory is adapted from VQEUCCFactory; see below
solver = VQEClientUCCFactory(
    quantum_instance=qins,
    provider=provider,
    optimizer=dict(
        name="QN-SPSA",
        maxiter=100,
        resamplings={1: 100},
    ),
    measurement_error_mitigation=True,
)

def solve(driver, solver):
    from qiskit_nature.problems.second_quantization.electronic import ElectronicStructureProblem
    problem = ElectronicStructureProblem(driver)

    from qiskit_nature.mappers.second_quantization import ParityMapper
    from qiskit_nature.converters.second_quantization import QubitConverter
    mapper = ParityMapper()
    converter = QubitConverter(mapper=mapper, two_qubit_reduction=True)

    from qiskit_nature.algorithms import GroundStateEigensolver
    calc = GroundStateEigensolver(converter, solver)

    r = calc.solve(problem)
    return r.total_energies[0],

if __name__ == "__main__":
    print(solve(driver, solver))

The VQEClientUCCFactory mentioned in the code above is a copy of VQEUCCFactory with method get_solver modified
https://github.com/Qiskit/qiskit-nature/blob/8d2b0eb1606620ed45211653ed20ab78335a39bc/qiskit_nature/algorithms/ground_state_solvers/minimum_eigensolver_factories/vqe_ucc_factory.py#L187-L233
the VQE constructor part of VQEUCCFactory.get_solver is changed to:
        vqe = VQEProgram(
            ansatz=ansatz,
            optimizer=self.optimizer,
            initial_point=self.initial_point,
            backend=self.quantum_instance.backend,
            #gradient=self.gradient,
            #expectation=self.expectation,
            #include_custom=self.include_custom,
            callback=self.callback,
            shots=self.quantum_instance._run_config.shots,
            **self._kwargs, # provider, measurement_error_mitigation
        )

        return vqe

What should happen?
It should run and return the final total energy.
Any suggestions?
Not sure why there is a gate named circuit-36_dg found during the transpilation (see the exception above).

Hi @Contextualist! I have also seen this error before, thanks for raising it! You can get it to work be calling .decompose() on your final ansatz before returning from your custom VQECientUCCFactory.
I will leave this issue open as this is likely something we should fix internally but the above workaround should make things work for you in the meantime. Let me know if this still does not help :+1:

Thanks for your prompt response, @mrossinek ! I tried to do the following edit for the VQEUCCFactory.get_solver:
+       ansatz = ansatz.decompose()
        vqe = VQEProgram(
            ansatz=ansatz,
            optimizer=self.optimizer,

However, I am still seeing the same error.  What you actually need to do is to transpile the circuit with a subset of supported basis gates. I did something similar in a workshop whose notebook I posted as a Gist, here (cell 26). Basically you can try the following:
from qiskit import transpile

basis_gates = ["rx", "ry", "rz", "sx", "cx"]
transpiled_ansatz = transpile(ansatz, basis_gates=basis_gates, optimization_level=0)

I just tried it out. I can confirm that the basis gate transpilation workaround works. Thanks!

The source of it was Qiskit/qiskit-terra#7429, which still persists, but since Qiskit 0.33 the UCCSD ansatz uses the new PauliEvolutionGate which doesn't construct a circuit with empty gates anymore. So in brief, this bug shouldn't exist anymore.
I tried it myself but, @Contextualist, would you mind trying with the latest Qiskit versions as well?

Thank you, @Cryoris ! I just tested with the following settings:

Qiskit version: 0.34
Qiskit Nature version: 0.3.0

and the bug cannot be reproduced with the original setup


TypeError: reference.stopAndPersist is not a function

Following fuse.js generates an error in my build:
const {
  EnvPlugin,
  FuseBox,
  QuantumPlugin,
  VuePlugin,
  WebIndexPlugin,
} = require('fuse-box');

const isProduction = process.env.NODE_ENV === 'production';

const fuse = FuseBox.init({
  homeDir: 'src',
  output: 'build/$name.js',
  hash: isProduction,
  cache: !isProduction,
  plugins: [
    EnvPlugin({ NODE_ENV: isProduction ? 'production' : 'development' }),
    isProduction && QuantumPlugin({ uglify: true }),
    VuePlugin(),
    WebIndexPlugin(),
  ],
});

fuse.bundle('vendor').instructions(`~ index.ts`);
fuse.bundle('app').instructions(`!> [index.ts]`);
fuse.run();

generates
Launching quantum core
  → Generating abstraction, this may take a while
  → Abstraction generated
  → Process bundle vendor
  → Process package default
  →   Files: 0
  → Process package vue
  →   Files: 1
  → Process package process
  →   Files: 1
  → Process package object-assign-polyfill
  →   Files: 1
  → Process bundle app
  → Process package default
  →   Files: 1
  → Render bundle vendor
  → Render bundle app
  ⠋ Uglifying vendor...TypeError: reference.stopAndPersist is not a function
    at Log.stopSpinner (/Users/me/Development/project/node_modules/fuse-box/dist/commonjs/Log.js:160:23)
    at BundleWriter.uglifyBundle (/Users/me/Development/project/node_modules/fuse-box/dist/commonjs/quantum/plugin/BundleWriter.js:55:23)
    at realm_utils_1.each (/Users/me/Development/project/node_modules/fuse-box/dist/commonjs/quantum/plugin/BundleWriter.js:110:26)
    at iterateMap (/Users/me/Development/project/node_modules/realm-utils/dist/commonjs/each.js:43:34)
    at /Users/me/Development/project/node_modules/realm-utils/dist/commonjs/each.js:59:17
    at /Users/me/Development/project/node_modules/realm-utils/dist/commonjs/each.js:63:14
    at Promise (<anonymous>)
    at Object.exports.Each [as each] (/Users/me/Development/project/node_modules/realm-utils/dist/commonjs/each.js:9:12)
    at BundleWriter.process (/Users/me/Development/project/node_modules/fuse-box/dist/commonjs/quantum/plugin/BundleWriter.js:97:30)
    at producer.generateAbstraction.then.then.then.then.then (/Users/me/Development/project/node_modules/fuse-box/dist/commonjs/quantum/plugin/QuantumCore.js:75:32)

Especially the { uglify: true } part in QuantumPlugin({ uglify: true }). If I remove { uglify: true } then the build runs but the generated bundle is not minified.

Should be fixed here -<EMAIL_ADDRESS>


DB seed for users and role

Dear Foyzul Karim
please
create seed for users and roles
Thanks.
Your name in Arabic
Foyzul : فيض الله
means : God's gift or God's Excess Giving or  Generous of God
Karim : كريم
means :Generous

@mrs01dev I have added a proper data seeding process. You can seed data using npm run db:seed command. For details, please check our readme file.
I am closing this issue.


Auto format messing up file

⚠ Please verify that this bug has NOT been reported before.

[X] I checked all existing issues and didn't find a similar issue

Description
Sometimes the formatting messes up and deletes part of the file, usually when there is an error (syntax error etc. in the code detected by lsp), this happens with clangd sometimes, and throws this error:
Error executing vim.schedule lua callback: ...-unwrapped-0.9.0/share/nvim/runtime/lua/vim/lsp/util.lua:501: Invalid 'start_col': out of range
stack traceback:
	[C]: in function 'nvim_buf_set_text'
	...-unwrapped-0.9.0/share/nvim/runtime/lua/vim/lsp/util.lua:501: in function 'apply_text_edits'
	...rapped-0.9.0/share/nvim/runtime/lua/vim/lsp/handlers.lua:318: in function 'handler'
	...eovim-unwrapped-0.9.0/share/nvim/runtime/lua/vim/lsp.lua:1394: in function ''
	vim/_editor.lua: in function <vim/_editor.lua:0>

Possible Solution
I looked at the source and this is how you're doing the formatting:
            if vim.g.formatsave then
              if client.supports_method("textDocument/formatting") then
                local params = require'vim.lsp.util'.make_formatting_params({})
                client.request('textDocument/formatting', params, nil, bufnr)

              end
            end

I have frankly never seen this, I'm guessing it's really old code? Neovim provides vim.lsp.buf.format() which doesn't cause the same problem, so I think it's better to switch to that
👟 Reproduction steps
not sure if this is easily reproduced:

use clangd
write a c++ file with some kind of obvious syntax error (e.g. missing ;)
save

👀 Expected behavior
format normally.
Running :lua vim.lsp.buf.format() to format it manually first fixes the issue
😓 Actual Behavior
neovim throws an error and the formatting is messed up, possibly deleting parts of the code.
💻 Metadata

system: "x86_64-linux"  - host os: Linux 6.2.10-zen1-1-zen, Arch Linux, noversion, rolling  - multi-user?: yes  - sandbox: yes  - version: nix-env (Nix) 2.14.1  - channels(py): "home-manager, nixpkgs"  - nixpkgs: /home/py/.nix-defexpr/channels/nixpkgs

📝 Relevant log output
Error executing vim.schedule lua callback: ...-unwrapped-0.9.0/share/nvim/runtime/lua/vim/lsp/util.lua:501: Invalid 'start_col': out of range
stack traceback:
	[C]: in function 'nvim_buf_set_text'
	...-unwrapped-0.9.0/share/nvim/runtime/lua/vim/lsp/util.lua:501: in function 'apply_text_edits'
	...rapped-0.9.0/share/nvim/runtime/lua/vim/lsp/handlers.lua:318: in function 'handler'
	...eovim-unwrapped-0.9.0/share/nvim/runtime/lua/vim/lsp.lua:1394: in function ''
	vim/_editor.lua: in function <vim/_editor.lua:0>

I haven't been able to look into this yet, but I think this is a problem with the formatter. I've had the exact same issue with helix where it deleted a section of my C++ code when formatting was requested.
Will check.

Hmm, I'm not able to reproduce this error. What LSP are you using for C++, clangd?

@horriblename could you confirm if this happens on other languages as well?

ah sorry I missed the notification, I am using clangd for C++, and it doesn't seem to happen in other languages
it seems to be harder to reproduce than I thought, I'll try to find something reproducible and also try ccls the next few days then report back

Thanks! I've experienced the same issue for a really short duration, but am not able to reproduce. If we could find reliable reproduction steps, I'll try to crack on it soon.

I have this issue still. When I'm done with keybinds (hopefully today), I can take a look.

Can't reproduce anymore, however using vim.lsp.buf.format() solves the problem of files showing as unsaved after formatting finishes. However, it freezes the editor until the formatting is finished, which can be quite annoying with painfully slow formatters eslint, prettier...

vim.lsp.buf.format() has some weird issues for me, I'll keep using the current implementation as it seems to have stopped breaking files.

i think it has something to do with mismatched indentation settings between nvim and the lsp (e.g. tabs vs spaces, tab sizes), but it's still not reproducible. Imma try using correct indentation and see if the issue persists

Looking at this deeper now. Seems the current implementation calls prettier 4 times for me on save...

and also is async, which isn't really that recommended.
I made some changes to it that use code from the null-ls wiki, and I've PRd it in #77. Would be nice if you could try it out @horriblename (just neovim-flake.url = "github:n3oney/neovim-flake/patch/fix-formatting";, doesn't require any config changes, but beware, it's based on release/v0.4, so if you're not using that (which you should, it has custom keybind support!), sorry.)

Fixed by #77, will be in main with 0.4.


error while setting up DM

I received this error while going through the DM setup:
googlece5877_student@cloudshell:~/advanced-kubernetes-bootcamp/dm-setup (qwiklabs-gcp-f9008da2cc63b81c)$ gcloud deployment-manager deployments create --config workshop.yaml adv-bc-$(date +%s)
The fingerprint of the deployment is EWIlUgcwxyLmlSYvyuOy9A==
Waiting for create [operation-1530022889459-56f8c36d30d39-5af38a2c-952c9943]...failed.
ERROR: (gcloud.deployment-manager.deployments.create) Error in Operation [operation-1530022889459-56f8c36d30d39-5af38a2c-952c9943]: errors:

code: RESOURCE_ERROR
location: /deployments/adv-bc-1530022888/resources/student-vm-21561737771-waiter
message: '{"ResourceType":"runtimeconfig.v1beta1.waiter","ResourceErrorCode":"504","ResourceErrorMessage":"Timeout
expired."}'

Looks like Istio was installed on the central cluster but not on the east cluster.  Errors below
Jun 26 14:28:03 student-vm-21561737771 startup-script: INFO startup-script: + helm install -n istio --namespace=istio-system --set sidecar-injector.enabled=true install/kubernetes/helm/istio
Jun 26 14:28:04 student-vm-21561737771 startup-script: INFO startup-script: Error: release istio failed: Service "istio-ingressgateway" is invalid: spec.ports[2].nodePort: Invalid value: 31400: provided port is already allocated
Jun 26 14:28:04 student-vm-21561737771 startup-script: INFO startup-script: Return code 1.
Jun 26 14:28:04 student-vm-21561737771 startup-script: INFO Finished running startup scripts.
Also, spinnaker is not installed on the spinnaker cluster possibly due to the error above

Re ran after @henrybell ran through it and no problems.  Closing this issue for now


Value shown wrong (value *100)

There seems to be a problem as mentioned before.
The account value is shown way to high (*100). So instead of 1.000€ MoneyMoney shows 100.000€.
Looks like a nice invest, but leads to uselessness.

Will be handled in https://github.com/EmDee/moneymoney-bondora/issues/12


gRPC-Go HTTP/2 Rapid Reset

Describe the issue you're reporting
Summary
In affected releases of gRPC-Go, it is possible for users to send HTTP/2 requests, cancel them, and send subsequent requests, which is valid by the HTTP/2 protocol, but would cause the gRPC-Go server to launch more concurrent method handlers than the configured maximum stream limit.
Detail
This was addressed by #6703 and has been included in patch releases: 1.56.3, 1.57.1, 1.58.3. It is also included in the latest release, 1.59.0.
Along with applying the patch, users should also ensure they are using the grpc. MaxConcurrentstreams server option to apply a limit to the server's resources used for any single connection.

I'm working on this and will create a PR soon


image on dragging is floatable

how can I stop moving?
And is it possible to support RTL?

You need to change panning options, there is velocity which have to be false in your case 😉


[B17] No way to provide enough infusion stability without other mods

I haven't been using any other mods that use RF, and it seems like there isn't a way to provide enough stability to make even a moderate-instability infusion safe. There needs to be a way to make infusion more reasonable without needing to add another mod just to generate enough RF to make the stabilizers useful.
Some ideas:

Increase the limit on the number of candles that can add to stability. Diminishing returns could still encourage the use of stabilizers, such as needing another 20 candles to match the effect of the first 10, then 40, and then 80. You could have 80 or 160 be the lower limit of candle effectiveness, as that would require hundreds of candles in order to make a significant difference for infusions with high instability.
Have a bonus for having multiple kinds of stabilizing objects. This could be implemented as a separate cap for each kind, so having 10 red candles and 10 blue candles would be more effective than having 20 red candles, optionally with diminishing returns.
Give the stabilizers a bonus when they're connected to the vis generators. I don't know the intricacies of how the RF system works, but this could be as simple as checking if there is a vis generator directly behind the stabilizer.
Increase how much of a buffer the stabilizers can provide. Right now, with 4 stabilizers and 16 candles even if I let it become fully stable before starting the infusion, infusing a ring to +1 runic shield quickly burns through what little buffer there was and goes to dangerously unstable.
Increase how many vis generators can be attached to a stabilizer. I don't think there's a way to use more than one vis generator with a stabilizer unless you have another mod that has things to transmit RF

@aycfes that's something I forgot to put in - making it possible to use multiple vis generators per stabilizer. I tried a couple ways, but none of them worked.

Maybe RF ports on all 5 free sides? Or a rudimentary cable. How much RF/t can a stabilizer take anyways. Id prefer 1 stabilizer with 5 generators over 3 stabilizers and 3 generators. Stabilizers are expensive.

Ive never had issues with infusion instability, was that changed when the stabilizers were added?
A full 10x10 floor of candles under the altar never caused any issues for me.

@Morinor Azanor mentioned in https://github.com/Azanor/thaumcraft-beta/issues/974#issuecomment-396523409 that as of beta 17 having more than 10 candles wouldn't do anything. That's why I was doing testing on this - I wanted to give feedback on that change.

in my opinion, the best way to solve this is to add an RF battery, that way the stabilizers can go full power for a limited time, making it way better but not op like the occult castles of tc 4&5.


Adding database and restarting biometric service

First, thanks for putting this lib in the public domain.
There is an issue with WBF that when you try to add database, it won't actually get created until windows biometric service is restarted. Some dirty workarround is to restart biometric service (see https://social.msdn.microsoft.com/Forums/vstudio/en-US/ea69bb0e-e534-4873-8c5f-5476b554ca28/winbio-private-pool-opensession?forum=windowssecurity), maybe there is some better way to do this. Admin right are required for all this.
Also, if you add database and then try to remove it without restarting biometric service, it will fail when trying to delete database file beacuse there is no file at given path (at RemoveDatabase, File.Delete(database.FilePath);)

Thanks for reporting the issue.
The second part should not really be a problem since File.Delete() does not throw an exception if the file to be deleted does not exist.

About the second part, it didn't work for me because Exception was thrown and database was not deleted from registry. I had to put that code into try catch block to delete database successfully.
Example:

Did you check what type of exception is thrown?


An error occurs when an image of 512 size is given as input.

Hello.I really aprreciate for your project.
However, The following error occurs when a 512-size image is input at Attention class.

dots = dots + relative_bias
RuntimeError: The size of tensor a (1024) must match the size of tensor b (196) at non-singleton dimension 3.

https://github.com/chinhsuanwu/coatnet-pytorch/blob/d3ef1c3e4d6dfcc0b5f731e46774885686062452/coatnet.py#L155
Why  this error is occured? How do I edit your code when I want to resize the image?
Thank you!

Hi @jeongHwarr
If you are not using images with size 224x224, you should modify the first argument in CoAtNet.
For example,
net = CoAtNet((512, 512), 3, num_blocks, channels, num_classes=1000)

@chinhsuanwu  Oh.. my.. I forgot that! I really really thank you so much! Have a good day. Thank you for your contribution!


Broken yaml parsing.

Exception #0 (Exception): Notice: Undefined variable: line in ../vendor/magento/zendframework1/library/Zend/Config/Yaml.php on line 292
https://github.com/magento/zf1/blob/4df018254c70b5b998b00a8cb1a30760f831ff0d/library/Zend/Config/Yaml.php#L292

Also, foreach ($lines as $n => $line) is not equal to while (list($n, $line) = each($lines)) (from original file https://github.com/zendframework/zf1/blob/136735e776f520b081cd374012852cb88cef9a88/library/Zend/Config/Yaml.php#L292). Since it does reset(), and also in PHP7 foreach loop doesn't utilize array pointer.

Yaml parsing is very slow as well. It would be better to use any other Yaml parser than the ZF1 yaml parser.


1.6.0 Horizontal Birch/Cherry Bar Textures

The Horizontal Birch Bars have the same texture as the Horizontal Crossed Birch Bars, as do the Horizontal Cherry Bars and the Horizontal Crossed Cherry Bars.
Screenshots

This will be fixed in the next release, since I'm switching to a different bars models.


Handle external file changes

Currently external file changes to source files are not handled.
When files are changed externally (e.g. through git), then the language server should trigger reparsing those files if they're open.

This is already handled if the editor (client) recognizes it.
VScode calls the didChangeWatchedFiles and didChange for files that are open (in tabs) and only didChangeWatchedFiles for files that are not opened.


[MLS Spec change] Remove encrypted sender data from ciphertext AAD

Description of the changes
Remove encrypted sender data from ciphertext AAD
Link to the exact changes
https://github.com/mlswg/mls-protocol/pull/423

Looks like this was addressed in #293.

Looks like this was addressed in #293.


⚠ Spryr has degraded performance

In 37d583d, Spryr (https://spryr.com) experienced degraded performance:

HTTP code: 200
Response time: 4519 ms

Resolved: Spryr performance has improved in be4efa9 after 8 minutes.


Update KTX2 support to use JS instead of WASM for parsing the KTX2 container

PR #7640 adds support for KTX2, but all the decoding is happening on the main thread. The code is using libktx.js/wasm to do the decoding. This lib expects a webgl context to be passed in. This prevents the code from being called from a web worker and is a bit bigger than it needs to be. PR https://github.com/KhronosGroup/KTX-Software/pull/172 adds some JS code to parse the KTX2 container and only use WASM to decode the data into the appropriate GPU format. This should hopefully allow the decoding to happen in a web worker. The resulting decoded data can then be transferred to the main thread to upload to the GPU.

Done


[jax2tf] Disable complex convolution test on GPU: crash in TF

Is it possible that this would also happen on TPU?

For some reason I do not see this failure on TPU.


MRG FIX: Remove deprecated code

+110 / -1307 isn't bad :)
I expect a few Travis errors because I haven't run tests, and Travis will get them done faster than my laptop.

Coverage increased (+0.05%) to 90.4% when pulling 26eadb5b515cb06358effb28628fda1a29b9f61b on Eric89GXL:deprecations into ee8ea224252b740289f09bf117d2ab33f752e3ba on mne-tools:master.

@dengemann ready for review/merge from my end :) Should probably be the first thing we go for for 0.10 so people don't mess with deprecated stuff

@Eric89GXL looks good to me. But the mutable defaults we have in 0.9 code can be considered bug makers.

I can fix it in this PR. I think backporting a fix will be a bit overkill. It's been that way for a long time, and I don't think we or PySurfer actually modifies the dict.

I think backporting a fix will be a bit overkill. It's been that way for a long time, and I don't think we or PySurfer actually modifies the dict.

Fine by me but please fix it here. This is why we started with this defaults stuff in the first place which we recently polished.

@dengemann all better, feel free to merge if you're happy

Thanks @Eric89GXL !!!


Silent change in behavior for tasks that extend AbstractArchiveTask

Tasks that extend AbstractArchiveTask in 5.1 or later may no longer work as expected.
Expected Behavior
Behavior should be maintained or should fail loudly.
Current Behavior
Depending on how the task is implemented, we may now silently ignore what the custom task does.
Context
Before 5.1, none of the built-in AbstractArchiveTask-based tasks (Zip, Tar, Jar, Ear, War) used the Provider API for their major properties (file name, classifier, extension, etc).
In 5.1, we added Provider API based equivalents and deprecated the old methods/properties. The old methods are implemented on top of the new Provider API methods and internally we use the new methods.
In Android and other plugins, we've seen a couple of problems fall out of that:

https://github.com/gradle/gradle/issues/8328 - This was fixed upstream in Android
https://gradle-community.slack.com/archives/CA7UM03V3/p1549056159397100 - refers to the nebula-ospackage plugins.

The issue is caused by two different patterns:

The Android AarBundle task overrides AbstractArchiveTask.getArchiveName so that the archive name can be calculated dynamically/on-demand.  Since the AbstractArchiveTask no longer looks at archiveName when determining the output file name changes to AarBundle.archiveName are ignored.
The nebula-ospackage plugin uses Convention mapping to override AbstractArchiveTask.getArchiveName, among other things. In a similar way to AarBundle, the convention mapping is ignored.

The "fix" so far has been for the affected plugins to change their code to use the Provider API where possible.  Since this impact wasn't considered when we added the Provider APIs, we could...

Roll everything back
Use the old methods internally to keep convention mapping/overrides in the loop.
Detect this situation and fail

I think 2 is possible, but we may be giving up some simplicity.

I believe the shadow plugin was also affected by the convention mapping.

My plugin has also few tasks extending Zip task and I also observed it.
https://github.com/Cognifide/gradle-aem-plugin/blob/master/src/main/kotlin/com/cognifide/gradle/aem/pkg/tasks/Compose.kt#L163
I am setting corrected baseName within task construction phase (task is being registered / not created) but Gradle's Base Plugin is overriding it on line https://github.com/gradle/gradle/blob/master/subprojects/plugins/src/main/java/org/gradle/api/plugins/BasePlugin.java#L113
As an effect, my corrected base name default is gone after upgrading Gradle, because configureEach from Base Plugin is of course called later. Now I am confused, how can I set my corrected base name default value which will be still overriddable via build script.
Any thoughts on that?

Any ETA?

@pun-ky that may have been added around the same time as convention and it was overlooked. I think that should be convention and not set.  Would you be interested in submitting a PR?

Yep, I will try to create my first PR here, but I am wondering if still 3rd party plugins like mine will need to be updated after changing set to convention in mentioned place. If there will be convention custom plugins will be able to override that default convention as I am understanding this new API. But still the change introduced forces plugin devs to align, right? So that more than this 2 lines need to be changed in my potential PR, because we are considering eliminating this silent regression at all? In other words, if there is more work to do, I am not sure if I will find a fix in my limited time.

Looks like it's just changing set to convention.
I wonder if it shouldn't actually be done in AbstractArchiveTask itself, to set the convention as soon as possible, in case plugin wants to override convention...

my plugin is also affected. i had to use this ugly workaround for lack of laziness, and you adding laziness this way broke my code. i actually haven't tested my plugin in 5.1+, but i was investigating the longevity of my current hack and found this issue.
take a look:
/*
 * DexPatcher - Copyright 2015-2019 Lanchon
 * (GNU General Public License version 3 or later)
 *
 * DexPatcher is free software: you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published
 * by the Free Software Foundation, either version 3 of the License,
 * or (at your option) any later version.
 */

package lanchon.dexpatcher.gradle.tasks

import groovy.transform.CompileStatic

import lanchon.dexpatcher.gradle.Utils

import org.gradle.api.file.RegularFile
import org.gradle.api.file.RegularFileProperty
import org.gradle.api.tasks.Internal
import org.gradle.api.tasks.OutputFile
import org.gradle.api.tasks.bundling.Zip

// FIXME: This apparently does not work on Gradle 5.1 or later.
// (See: https://github.com/gradle/gradle/issues/8401)

@CompileStatic
class LazyZipTask extends Zip {

    @OutputFile final RegularFileProperty archiveFile

    LazyZipTask() {
        archiveFile = project.layout.fileProperty()
        archiveFile.set project.<RegularFile>provider {
            Utils.getRegularFile(project, super.getArchivePath())
        }
    }

    @Internal
    public File getArchivePath() {
        return archiveFile.get().asFile;
    }

}

there is:

a name clash over archiveFile.
getArchivePath() being ignored (i guess, haven't tried).

i want to support both Gradle 4 and 5:

one way is to add properties and a doFirst action that reads them and sets the old style fields. this is hacky and probably incorrect.
a cleaner way is to keep the current code (add properties, override getArchivePath) but also reflect the existence of the new style properties. and if they are there, set them to mirror the value of the added properties. this is correct but needs reflection.

any other way to support laziness on Gradle 4 and 5?

@Lanchon The Zip task now supports lazy configuration in 5.1+ so your "hack" as you call it shouldn't be necessary anymore.

@JLLeitschuh, thanks but that's irrelevant. as i stated:

i want to support both Gradle 4 and 5

Here is a workaround to support archive laziness in Gradle 4 and 5.1+. It is supposed to compile under both Gradle 4 and 5.1+. Note that this code has not yet been tested under Gradle 5.1, but is expected to work.
/*
 * DexPatcher - Copyright 2015-2019 Lanchon
 * (GNU General Public License version 3 or later)
 *
 * DexPatcher is free software: you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published
 * by the Free Software Foundation, either version 3 of the License,
 * or (at your option) any later version.
 */

package lanchon.dexpatcher.gradle.tasks

import groovy.transform.CompileDynamic
import groovy.transform.CompileStatic

import lanchon.dexpatcher.gradle.Utils

import org.gradle.api.file.Directory
import org.gradle.api.file.DirectoryProperty
import org.gradle.api.provider.Property
import org.gradle.api.tasks.Internal
import org.gradle.api.tasks.bundling.Zip
import org.gradle.util.GradleVersion

@CompileStatic
class LazyZipTask extends Zip {

    // Conditionally enable workaround for Gradle 5.1 bug (https://github.com/gradle/gradle/issues/8401).
    private static final boolean GRADLE_5_1 = (GradleVersion.current() >= GradleVersion.version('5.1'))

    // Enable workaround for Gradle < 5.1 unexpected behavior seemingly related to convention implementation.
    private static final boolean DESTINATION_DIR_WORKAROUND = true

    // Client must configure the output archive only using these properties:
    @Internal final Property<String> lazyArchiveFileName
    @Internal final DirectoryProperty lazyDestinationDirectory

    LazyZipTask() {
        if (GRADLE_5_1) {
            // On Gradle >= 5.1 simply alias existing properties.
            lazyArchiveFileName = gradle_5_1_getArchiveFileName()
            lazyDestinationDirectory = gradle_5_1_getDestinationDirectory()
        } else {
            // On Gradle < 5.1 create new properties and override existing getters.
            lazyArchiveFileName = project.objects.property(String)
            lazyArchiveFileName.set project.<String> provider {
                super.getArchiveName()
            }
            lazyDestinationDirectory = project.layout.directoryProperty()
            if (!DESTINATION_DIR_WORKAROUND) {
                lazyDestinationDirectory.set project.<Directory> provider {
                    Utils.getDirectory(project, super.getDestinationDir())
                }
            }
        }
    }

    @CompileDynamic
    private Property<String> gradle_5_1_getArchiveFileName() {
        return this.getArchiveFileName()
    }

    @CompileDynamic
    private DirectoryProperty gradle_5_1_getDestinationDirectory() {
        return this.getDestinationDirectory()
    }

    @Override @Internal public String getArchiveName() {
        if (GRADLE_5_1) {
            return super.getArchiveName()
        } else {
            return lazyArchiveFileName.get()
        }
    }

    @Override @Internal public File getDestinationDir() {
        if (GRADLE_5_1) {
            return super.getDestinationDir()
        } else {
            if (!DESTINATION_DIR_WORKAROUND) {
                return lazyDestinationDirectory.get().asFile
            } else {
                super.destinationDir = lazyDestinationDirectory.get().asFile
                return super.getDestinationDir()
            }
        }
    }

}

UPDATE: although my plugins developed against 4.10.1 do not trigger deprecation warnings there, they have multiple issues with Gradle 5.1, including some that superficially look like this bug but involving other non-archive tasks. Gradle 5.1 is not my top priority so i'll postpone testing of the above code.

affects also 5.4,
I tried with setting
open class MyTask : Zip() {
    init {
        archiveBaseName.convention(project.provider { "${project.rootProject.name}-${Formats.dateFileName()}" })
    }

    // ...
}

but I need to use set here instead of convention, because my convention is still being overridden by https://github.com/gradle/gradle/blob/master/subprojects/plugins/src/main/java/org/gradle/api/plugins/BasePlugin.java#L113
as I understand this, I need to assign convention separately as it is Gradle Base plugin doing, not in MyTask init block / construction phase (most probably it will work)
   project.tasks.register("myTask", MyTask::class.java)
   project.tasks.withType(MyTask.class).configureEach {
                 archiveBaseName.convention(project.provider { "${project.rootProject.name}-${Formats.dateFileName()}" })
   }

this looks confusing for me, because I cannot have all task specific stuff defined inside task class / need to think about conventions / lazy API which can affect my task code from outside.

workaround:
this LazyZipTask is tested to work on Gradle versions earlier than and later than 5.1.


Updated the runtime to python-3.6.2

Updated the runtime to python-3.6.2 as python-2.7.10 is not supported anymore in the latest version of python_buildpack
python_buildpack                         10         true      false    python-buildpack-v1.5.22.zip
DEPENDENCY MISSING IN MANIFEST: python 2.7.10
It looks like you're trying to use python 2.7.10.
Unfortunately, that version of python is not supported by this buildpack.
The versions of python supported in this buildpack are:

3.6.2
3.6.1
3.5.3
3.5.2
3.4.6
3.4.5
3.3.6
3.3.5
2.7.13
2.7.12
If you need further help, start by reading: https://github.com/cloudfoundry/python-buildpack/releases.

Was this tested to see that 3.6 still worked with the code that was in there?

I did push the application after changing the runtime and it worked fine.


fix for #658

It seems the tryActivate function is a source point for every possible callback. In order to prevent taking dependencies on observables accessed in that callbacks, the call should be wrapped into ko.ignoreDependencies.

Is there any chance of fixing this?


Added handling of multiple tasks referring to the same JS function

A proposed resolution to issue https://github.com/gulpjs/gulp/issues/1159

I like this a lot.  Not a lot of code and solves the problem we are running into.  However, I think this breaks the gulp --tasks command line option because we pass the results of .tree() directly to the archy module and I don't think it accepts an array as a label

@daizenberg thoughts?

Regarding the broken --tasks, couldn't we simply add the follow snippet, or something similar, here
if(_.isArray(meta.tree.label))
  return '[' + meta.tree.label.toString() + ']';
else
  return meta.tree.label;

Fixed by #50.  Thanks for submitting this implementation.  It got us thinking about the best way to solve.


virtualenv issues: `venv' is marked deactivated. Need to use --force option. Why?

1) Using the pyenv virtualenv wrapper
Why do I get this message when trying to activate a virtual env after creating it?
pyenv-virtualenv: 'venv' is marked deactivated. use 'pyenv activate --force venv' to activate forcibly'.
vagrant@dev:~$ pyenv versions
  system
* 2.7.10 (set by PYENV_VERSION environment variable)
vagrant@dev:~$ pyenv virtualenv 2.7.10 venv
New python executable in /home/vagrant/.pyenv/versions/2.7.10/envs/venv/bin/python2.7
Also creating executable in /home/vagrant/.pyenv/versions/2.7.10/envs/venv/bin/python
Installing setuptools, pip, wheel...done.
Ignoring indexes: https://pypi.python.org/simple
Requirement already satisfied (use --upgrade to upgrade): setuptools in /home/vagrant/.pyenv/versions/2.7.10/envs/venv/lib/python2.7/site-packages
Requirement already satisfied (use --upgrade to upgrade): pip in /home/vagrant/.pyenv/versions/2.7.10/envs/venv/lib/python2.7/site-packages
vagrant@dev:~$ pyenv activate venv
pyenv-virtualenv: `venv' is marked deactivated. use `pyenv activate --force venv' to activate forcibly.
vagrant@dev:~$ pyenv activate --force venv
pyenv-virtualenv: activate venv
pyenv-virtualenv: prompt changing will be removed from future release. configure `export PYENV_VIRTUALENV_DISABLE_PROMPT=1' to simulate the behavior.
(venv) vagrant@dev:~$ pyenb which python

2) Using virtualenv directly
I tried to use virtualenv directly instead of using the pyenv wrapper but why do I get this message pyenv-virtualenv: deactivate venv2 when trying to activate it the virtualenv way?
Can we use virtualenv normally?
vagrant@dev:~$ pyenv shell 2.7.10
vagrant@dev:~$ pyenv versions
  system
* 2.7.10 (set by PYENV_VERSION environment variable)
vagrant@dev:~$ virtualenv venv2
New python executable in venv2/bin/python2.7
Also creating executable in venv2/bin/python
Installing setuptools, pip, wheel...done.
vagrant@dev:~$ source venv2/bin/activate
pyenv-virtualenv: deactivate venv2
(venv2)vagrant@dev:~$

Thanks

pyenv-virtualenv persists deactivated version in PYENV_DEACTIVATE to prevent it to be activated once after manual activation. Just use --force to activate it regardless of PYENV_DEACTIVATE.

It is kind of a bug at least unintended behaviour. I fixed it in 47feedc9347be88c3056809073ee631b7b86cb02

Thanks for the responses.
I'm not sure to understand what "deactivated" means since I just created the virtualenv in this case and I use the pyenv command?
pyenv virtualenv 2.7.10 venv
pyenv activate venv

I suspect you have used the name of 'venv' before and it was in PYENV_DEACTIVATE. Try it again with newly created shell.

I made a test with a freshly built VM so no other virtualenvs were created before and it still does that (see below.)
vagrant@dev:~$ pyenv virtualenv venv
...
vagrant@dev:~$ pyenv activate venv
pyenv-virtualenv: activate venv
pyenv-virtualenv: prompt changing will be removed from future release. configure `export PYENV_VIRTUALENV_DISABLE_PROMPT=1' to simulate the behavior.
(venv) vagrant@dev:~$ pyenv deactivate
pyenv-virtualenv: deactivate 2.7.10/envs/venv
vagrant@dev:~$ pyenv activate venv
pyenv-virtualenv: `venv' is marked deactivated. use `pyenv activate --force venv' to activate forcibly.
vagrant@dev:~$

Also, why are there two virtual envs listed (2.7.10/envs/venv and venv) when creating a virtualenv?
vagrant@dev:~$ pyenv versions
  system
* 2.7.10 (set by PYENV_VERSION environment variable)
  2.7.10/envs/venv
  venv

Thanks

It is because you activated once then deactivated it. You just need to specify --force to re-activate the virtualenv if it already marked deactivated.
In that case, venv is a symlink prepared for backward compatibility. The real name virtualenv is at $(pyenv root)/versions/2.7.10/envs/venv and you can use both of them to use the virtualenv.

Sorry, I'm not following. I understand the force option but with virtualenv, you can activate/deactivate a virtualenv as much as you want since the purpose is to work in a virtualenv and then exit and then go back, etc: source venb/bin/activate and deactivate
Why is this behavior different in the pyenv context? What does deactivate mean then?
Thanks

It's different impl. If you want something to change, read and write code.


Update . to : for all chown coomands in deb/rpm build templates

Description
Update . to : for all chown coomands in deb/rpm build templates
Issues Resolved
Closes https://github.com/opensearch-project/opensearch-build/issues/4612
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Looks like the issue was created for debian only. Does this also apply to RPM?

Looks like the issue was created for debian only. Does this also apply to RPM?

In general . is an older syntax where : is modern.
For username with . the older syntax will actually have issues.
This is just to make sure everything is updated. Thanks.


Add CRV StepPointMCs to S2 output

Hi @brownd1978,
You have proposed changes to files in these packages:

JobConfig

which require these tests: build.
@Mu2e/fnalbuild-users, @Mu2e/write have access to CI actions on main.
:hourglass: The following tests have been triggered for fdf5d2c6a2367ecc4c96988a09d12cdbf1c33d87: build  (Build queue is empty)
About FNALbuild. Code review on Mu2e/Offline.

:sunny: The build tests passed at fdf5d2c6a2367ecc4c96988a09d12cdbf1c33d87.

Test
Result
Details

test with
:white_check_mark:
Command did not list any other PRs to include

merge
:white_check_mark:
Merged fdf5d2c6a2367ecc4c96988a09d12cdbf1c33d87 at ab5ee77a42fbc556d2728c6d1bed41c547d99f09

build (prof)
:white_check_mark:
Log file. Build time: 14 min 59 sec

ceSimReco
:white_check_mark:
Log file.

g4test_03MT
:white_check_mark:
Log file.

transportOnly
:white_check_mark:
Log file.

POT
:white_check_mark:
Log file.

g4study
:white_check_mark:
Log file.

cosmicSimReco
:white_check_mark:
Log file.

cosmicOffSpill
:white_check_mark:
Log file.

ceSteps
:white_check_mark:
Log file.

ceDigi
:white_check_mark:
Log file.

muDauSteps
:white_check_mark:
Log file.

ceMix
:white_check_mark:
Log file.

rootOverlaps
:white_check_mark:
Log file.

g4surfaceCheck
:white_check_mark:
Log file.

FIXME, TODO
:white_check_mark:
TODO (0) FIXME (0) in 0 files

clang-tidy
:white_check_mark:
0 errors 0 warnings

N.B. These results were obtained from a build of this Pull Request at fdf5d2c6a2367ecc4c96988a09d12cdbf1c33d87 after being merged into the base branch at ab5ee77a42fbc556d2728c6d1bed41c547d99f09.
For more information, please check the job page here.
Build artifacts are deleted after 5 days. If this is not desired, select Keep this build forever on the job page.


Add principal_direction_extents to _fst features.

@eleftherioszisis Since you added the principal direction extent feature, do you have any comments on whether the duplicated points at section boundaries can make a difference or explain the discrepancies seen between this code and the point-tree one?

Hmm, I am unsure on how the calculation of the pca will be affected from the duplication of the section boundaries.
I think that it would stir the covariance ellipsoid towards the section points due to the fact that these points are encountered twice on the same position. In other words the spatial distribution of the point cloud is changed due to the duplicate points.
If duplicate points are artificially introduced in the test trees, do the results change a lot?

That makes sense. I guess the order of the points doesn't matter, right? I ask because I can also remove the duplicates by skipping the first point of each section, but then I would have to add back the initial neurite trunk points. If the order doesn't matter this should be quite straight forward.

If by order you mean the way you parse the tree, then yes it doesn't matter because the function uses a collection of points, not the tree itself.
Wouldn't it have been better if the duplicate points are removed in the loading of the neuron? I find it kind of inefficient having to remove them each time one needs to parse the tree and it may possibly lead to strange bugs due to the fact that the tree will be parsed regardless of the existence of duplicate points. I don't know exactly the mechanics of the section neurons, thus this is more of a question than a suggestion.

[Current coverage][cc-pull] is 90.76%

Merging [#337][cc-pull] into [master][cc-base-branch] will decrease coverage by -0.35%

@@             master       #337   diff @@
==========================================
  Files            45         45
  Lines          2068       2077     +9
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
+ Hits           1884       1885     +1
- Misses          184        192     +8
  Partials          0          0

Powered by Codecov. Last updated by [1ef97c7...61675a5][cc-compare]
[cc-base-branch]: https://codecov.io/gh/BlueBrain/NeuroM/branch/master?src=pr
[cc-compare]: https://codecov.io/gh/BlueBrain/NeuroM/compare/1ef97c7f9cbacdd93db884ea136f5494e775404a...61675a577d939a17b500996576a67f232f2bd589
[cc-pull]: https://codecov.io/gh/BlueBrain/NeuroM/pull/337?src=pr

It is fixed by removing the duplicate points. Regarding removing them on loading, the sections need these points (I actually have to add them when parsing SWC data.)


Metaclass TypeError

TypeError: metaclass conflict: the metaclass of a derived class must be a (non-strict) subclass of the metaclasses of all its bases

To Reproduce
Steps to reproduce the behavior:

I am using Python 3.9 under a windows 10 machine
Spapros is pip-installable without issues
when trying  "import spapros as sp"  I get the error described above. Where does this error come from? Stacktrace provides this info:

Expected behavior
importing the spapros package with success and managing to at least run "print(f"spapros=={sp.version}")"

System

OS:  [Windows 10 pro]
Language Version: [e.g. Python 3.9]
No virtual environment.

Additional context

Should be fixed now with the new release (0.1.2).
Wrt your code snippet pls try
import spapros as sp
print(f"spapros=={sp.__version__}")


Bump shell version number to reflect latest published version

Minor update to bump the version number of the shell to match has been published

Codecov Report
Base: 36.79% // Head: 36.80% // Increases project coverage by +0.00% :tada:

Coverage data is based on head (504108c) compared to base (de1969a).
Patch has no changes to coverable lines.

Additional details and impacted files
@@           Coverage Diff           @@
##           master    #7198   +/-   ##
=======================================
  Coverage   36.79%   36.80%
=======================================
  Files         986      986
  Lines       17642    17642
  Branches     4543     4543
=======================================
+ Hits         6492     6493    +1
+ Misses      11150    11149    -1

Flag
Coverage Δ

e2e
47.31% <ø> (+<0.01%)
:arrow_up:

merged
36.80% <ø> (+<0.01%)
:arrow_up:

unit
5.20% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

shell/plugins/dashboard-store/mutations.js
54.96% <0.00%> (-3.32%)
:arrow_down:

shell/plugins/dashboard-store/resource-class.js
47.32% <0.00%> (-0.31%)
:arrow_down:

shell/utils/validators/index.js
31.14% <0.00%> (+0.81%)
:arrow_up:

shell/models/provisioning.cattle.io.cluster.js
64.03% <0.00%> (+0.94%)
:arrow_up:

shell/plugins/steve/subscribe.js
67.85% <0.00%> (+1.09%)
:arrow_up:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Cordova file plugin works only once after installation

Hi. I'm using cordova file plugin for my app. Here is my code and it alerts me after installing app.
$cordovaFile.getFreeDiskSpace().then(function (success) {
  alert("disk space: " + success);
}, function (error) {
  alert("error disk space :" + error);
});

But after closing the app and reopening again, app crashes and becomes just a blank page.
Any idea?

Hello, thanks for opening an issue with us! Since this seems to be an issue with that plugin i would recommend that you open an issue on that plugin's repo. Thanks!

Thank you. But I couldn't be able to find the issue part of that repo.


Make guest username, uid, home directory configurable

Also disallows the "admin" username by default (because it is a builtin user in Ubuntu), but can be overridden by setting it explicitly in lima.yaml.
user:
  username: john
  uid: 1000
  homeDir: "/home/{{.User}}"

The code also implements support for setting user.gid but doesn't document it because cloud-init has no way to set it. We'll have to implement this ourselves in our ci scripts (if we want it).

Another change is that {{.User}} and {{.UID}} in host templates now expand to the host values and not the guest values. Note that on Windows the host user is something like runner\runneradmin and host uid something like S-1-5-21-2897396845-3571823323-1290545657-500 (on GitHub runner).

Setting the homeDir does not work yet with alpine-iso because lima-init hardcodes the home directory to /home/$USER.linux.
Fixes #2117
Fixes #2037
Implements #2622
Replaces #2378

I recommend using "Hide whitespace" for reviewing this PR, especially for osutil/user.go.

Should there be an option to avoid "mirroring" the host values, and go with the default ones from the cloud.cfg?

The code also implements support for setting user.gid but doesn't document it because cloud-init has no way to set it. We'll have to implement this ourselves in our ci scripts (if we want it).

In terms of features, it probably would be more useful to have "groups" (extra groups) than "gid" (not used so much)

Should there be an option to avoid "mirroring" the host values, and go with the default ones from the cloud.cfg?

I don't know how we would set up ssh without knowing the username. If we can figure this out, then I think we should support this.

In terms of features, it probably would be more useful to have "groups" (extra groups) than "gid" (not used so much)

I have removed all code related to gid, so we can figure out the correct schema in due time.

I'm wondering if {{.Comment}} should be supported in host/guest templates. It would be easy to add, but I can't think of an actual use-case.

I believe I've addressed all feedback now, PTAL
There are 2 open issues that should probably be done "later":

Optionally don't add an additional user at all (but how do we set up ssh keys?)
Add {{.Comment}} to host and guest templates (but why?)

I'm wondering if {{.Comment}} should be supported in host/guest templates. It would be easy to add, but I can't think of an actual use-case.

I don't actually know the use case (even finger has been removed, for "pinky") - it was just that all the cloud-config examples had gecos...


Not getting email for "Send Inventory Source Notification E-mail".

Bug report
Title
Not getting email for "Send Inventory Source Notification E-mail".
Issue Description
Not getting email for "Send Inventory Source Notification E-mail".
Preconditions
1. framework Version- 1.0.0

Steps to reproduce
1. step1- CReate a inventory source and create product for that inventory source.
2. step2- Place order and generate shipment from that inventory.

Expected result
Email notification should receive if it is enabled from Email grid.
Actual result
Not getting email for inventory.

Fixed


Publish 12/08/2021, 10:30 AM

Docs Build status updates of commit c6ea18d:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

sharepoint/sharepoint-ps/sharepoint-online/Request-SPOUpgradeEvaluationSite.md
:white_check_mark:Succeeded
View (sharepoint-ps)

sharepoint/sharepoint-ps/sharepoint-online/Restore-SPODataEncryptionPolicy.md
:white_check_mark:Succeeded
View (sharepoint-ps)

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


Support Rust 1.31

Timely 0.9 builds with rust 1.32, but not rust 1.31. As far as I can tell, it is not using any important features available in 1.32, but not 1.31. The main issue seems to be that it uses the new syntax for module imports.
If I create a PR to restore 1.31 compatibility, will it be accepted and become timely 0.9.1?
The reason I care about one minor version so much is because RHEL (which is what our build farm runs on) currently supports 1.31. The build farm must work offline, so installing the toolchain with rustup is not an option.

Here is the proposed patch
diff --git a/communication/src/lib.rs b/communication/src/lib.rs
index 7af0714..b12d8e0 100644
--- a/communication/src/lib.rs
+++ b/communication/src/lib.rs
@@ -102,10 +102,10 @@ use serde::{Serialize, Deserialize};
 #[cfg(not(feature = "bincode"))]
 use abomonation::Abomonation;

-pub use allocator::Generic as Allocator;
-pub use allocator::Allocate;
-pub use initialize::{initialize, initialize_from, Configuration, WorkerGuards};
-pub use message::Message;
+pub use self::allocator::Generic as Allocator;
+pub use self::allocator::Allocate;
+pub use self::initialize::{initialize, initialize_from, Configuration, WorkerGuards};
+pub use self::message::Message;

 /// A composite trait for types that may be used with channels.
 #[cfg(not(feature = "bincode"))]
@@ -188,4 +188,4 @@ fn promise_futures<T>(sends: usize, recvs: usize) -> (Vec<Vec<Sender<T>>>, Vec<V
     }

     (senders, recvers)
-}
\ No newline at end of file
+}
diff --git a/kafkaesque/src/lib.rs b/kafkaesque/src/lib.rs
index 39ec51b..01ad1d2 100644
--- a/kafkaesque/src/lib.rs
+++ b/kafkaesque/src/lib.rs
@@ -13,7 +13,7 @@ use rdkafka::consumer::{Consumer, BaseConsumer, DefaultConsumerContext};
 use rdkafka::config::FromClientConfigAndContext;

 pub mod kafka_source;
-pub use kafka_source::kafka_source as source;
+pub use self::kafka_source::kafka_source as source;

 struct OutstandingCounterContext {
     outstanding: Arc<AtomicIsize>,
diff --git a/sort/src/lib.rs b/sort/src/lib.rs
index 0653a28..088e367 100644
--- a/sort/src/lib.rs
+++ b/sort/src/lib.rs
@@ -16,11 +16,11 @@ mod stash;
 mod batched_vec;
 mod swc_buffer;

-pub use lsb::Sorter as LSBRadixSorter;
-pub use lsb_swc::Sorter as LSBSWCRadixSorter;
-pub use msb::Sorter as MSBRadixSorter;
-pub use msb_swc::Sorter as MSBSWCRadixSorter;
-pub use swc_buffer::SWCBuffer;
+pub use self::lsb::Sorter as LSBRadixSorter;
+pub use self::lsb_swc::Sorter as LSBSWCRadixSorter;
+pub use self::msb::Sorter as MSBRadixSorter;
+pub use self::msb_swc::Sorter as MSBSWCRadixSorter;
+pub use self::swc_buffer::SWCBuffer;

 /// An unsigned integer fit for use as a radix key.
 pub trait Unsigned : Ord {
diff --git a/timely/src/lib.rs b/timely/src/lib.rs
index 192b43c..d3438b3 100644
--- a/timely/src/lib.rs
+++ b/timely/src/lib.rs
@@ -67,8 +67,8 @@ extern crate timely_communication;
 extern crate timely_bytes;
 extern crate timely_logging;

-pub use execute::{execute, execute_directly, execute_from_args, example};
-pub use order::PartialOrder;
+pub use self::execute::{execute, execute_directly, execute_from_args, example};
+pub use self::order::PartialOrder;

 pub use timely_communication::Configuration;

@@ -110,4 +110,4 @@ impl<T: Clone+'static> Data for T { }
 /// The `ExchangeData` trait extends `Data` with any requirements imposed by the `timely_communication`
 /// `Data` trait, which describes requirements for communication along channels.
 pub trait ExchangeData: Data + communication::Data { }
-impl<T: Data + communication::Data> ExchangeData for T { }
\ No newline at end of file
+impl<T: Data + communication::Data> ExchangeData for T { }

Sorry for the delay here. I'm away for the weekend but will try and figure out something for you here.
My understanding of the alternatives are:

Maintain some amount of forward compatibility so that future timely programs / commits can work against older Rust compilers.
Ask people pinned to older compilers to maintain their own forks.

I'm personally hesitant about 1. taking on maintenance burden for software I don't use (and to avoid features I would like to use, like the recent Box<FnOnce> upgrade). I'll chat it up with some local folks with more software maintenance experience than I have and see if I can get a read on the trade-offs.
If you have constraints that prevent option two, let me know!

I completely understand why you're reluctant to maintain backwards/forward compiler compatibility.  Obviously, this is an extra constraint on your development process. The reason I hoped you'd consider it is because I feel it will be important for many others who, like me, want to use differential/timely in production environments. Even working with open source projects, I've encountered that people are reluctant to use rustup and demand that the software compiles with the version of Rust that comes with their distro. Likewise, it is a hard requirement in my company.
Regarding option 2. In cases like the one that started this thread, maintaining my own clone of differential is not a big deal; although I am not sure that using this slightly improved syntax is worth losing compiler compatibility. But once you start using new capabilities like Box<FnOnce>, I'm in trouble, as workarounds get much more complex and worst of all I'll have to keep patching timely/differential to keep up with your development.


modified the api so the creation of custom tennant will work

Fixed the tenants url to /master/api/providers
Added the entity_id param to Tenant resource, so the delete would work correctly

No, there is not yet. I have begun working on it but do not have the environment set to run the tests. I Will talk with jsmadis to solve it.


[SEC] Add Support for Security Functionalities

Add support for LinkedIn Learning course's security functionalities, including support for a user login password page.

Finished this a while ago. Closing now.


GitHub provider

I'd like to propose new provider Github.
I uses Github application privateKey and appID to get github accessToken  of format ghs_*
The token can be used to access GH repositories, pull/push to registry, etc.
Can be used for tekton auth with GH instead of using personal access tokens'
Checklist

[x] I have read the contribution guidelines
[x] All commits are signed with git commit --signoff
[x] My changes have reasonable test coverage
[x] All tests pass with make test
[x] I ensured my PR is ready for review with make reviewable

@moolen I also plan to extend github provider to pull github secrets and vars in a few next iterantions.
Please let me know if you something else should be fixed before it can be merged.
I may have issue with DCO signoff git rebase HEAD~75 --signoff results in multiple manual rebase  conflicts. Would appreciate advice on how to pass it

@moolen, I moved changes to the new PR and  properly sign , can you please check and approve or comment the new PR
Closed in favor of #3115


project may contain real AWS account numbers

In some places you are clearly using example account numbers, such as<PHONE_NUMBER>11,<PHONE_NUMBER>22, etc.
However, you might want to check these files:

tests/test_identity_policy_schema.py
tests/test_identity_policy_provider.py

fixed. thank you!


[stable/jenkins] MissingPropertyException : Script Security plugin issue

Is this a request for help?:
I found a problem.
and I found a solution.

Is this a BUG REPORT or FEATURE REQUEST? (choose one):
BUG REPORT and FEATURE REQUEST
add InstallPlugins script-security:1.44

Version of Helm and Kubernetes:
$ helm version
Client: &version.Version{SemVer:"v2.10.0", GitCommit:"9ad53aac42165a5fadc6c87be0dea6b115f93090", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.10.0", GitCommit:"9ad53aac42165a5fadc6c87be0dea6b115f93090", GitTreeState:"clean"}

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.2", GitCommit:"bb9ffb1654d4a729bb4cec18ff088eacc153c239", GitTreeState:"clean", BuildDate:"2018-08-07T23:17:28Z", GoVersion:"go1.10.3", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.3", GitCommit:"2bba0127d85d5a46ab4b778548be28623b32d0b0", GitTreeState:"clean", BuildDate:"2018-05-21T09:05:37Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}

Which chart:
stable/jenkins
What happened:
groovy.lang.MissingPropertyException: No such property: logRotator for class: groovy.lang.Binding
	at groovy.lang.Binding.getVariable(Binding.java:63)
	at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onMethodCall(SandboxInterceptor.java:130)
	at org.kohsuke.groovy.sandbox.impl.Checker$1.call(Checker.java:155)
	at org.kohsuke.groovy.sandbox.impl.Checker.checkedCall(Checker.java:159)
	at com.cloudbees.groovy.cps.sandbox.SandboxInvoker.methodCall(SandboxInvoker.java:17)
	at WorkflowScript.run(WorkflowScript:4)

What you expected to happen:
build succeed
How to reproduce it (as minimally and precisely as possible):
Remove jenkins
Reinstall stable/jenkins
Build anything
Anything else we need to know:
I found a same issue.
https://issues.jenkins-ci.org/projects/JENKINS/issues/JENKINS-53421?filter=allopenissues
https://plugins.jenkins.io/script-security Version 1.45 (Sep 4, 2018)
'Downgrade to 1.44'
Master:
  InstallPlugins:
    - script-security:1.44

https://issues.jenkins-ci.org/browse/JENKINS-53420


Remake + fixes of #44, minor improvements, fix previous remake typo.

Please merge after #46, includes #44 (rebased on top of it)

closed since conflicts and rebased commits that are actually in master already.
See PR #6 instead


Start-BcContainer - docker logs (docker : Get-CIMInstance : Call was canceled by the message filter. )

Describe the issue
Since today some of our containers do not start anymore. It does not happens for alle containers.
Scripts used to create container and cause the issue
Start-BcContainer $containername

Full output of scripts
BcContainerHelper version 3.0.7
BcContainerHelper emits usage statistics telemetry to Microsoft
WARNUNG: Die Namen einiger importierter Befehle auf Modul "BcContainerHelper" enthalten nicht genehmigte Verben, sodass deren Auffindbarkeit erschwert werden kann.  Sie können durch Eingeben von "Get-Verb" eine Liste der genehmigten Verben anzeigen.

docker : Get-CIMInstance : Call was canceled by the message filter.
In C:\Program Files\WindowsPowerShell\Modules\BcContainerHelper\3.0.7\ContainerHandling\Start-NavContainer.ps1:21 Zeichen:15
+     $logs = @(docker logs $containerName)
+               ~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (Get-CIMInstance...essage filter. :String) [], RemoteException
    + FullyQualifiedErrorId : NativeCommandError

Additional context
The error seems to be caused by the following line.
https://github.com/microsoft/navcontainerhelper/blob/edf72b7532de60f93251926328eb17173021c3eb/ContainerHandling/Start-NavContainer.ps1#L21
The container can be started by invoking docker start <id>.

what happens if you use
docker logs $containerName
manually - do you get the log output from the container?

PS C:\Windows\system32> docker logs kise-bc14-dw
Using artifactUrl https://bcartifacts.azureedge.net/onprem/14.36.48675.0/de
Using installer from C:\Run\130
Copying Platform Artifacts
c:\dl\onprem\14.36.48675.0\platform
Copying Application Artifacts
Copying Database
Copying Installers
c:\dl\onprem\14.36.48675.0\de\Installers
Copying TestToolKit
c:\dl\onprem\14.36.48675.0\de\TestToolKit
Copying UpgradeToolKit
c:\dl\onprem\14.36.48675.0\de\UpgradeToolKit
Copying Extensions
c:\dl\onprem\14.36.48675.0\de\Extensions
Installing Business Central
Installing Url Rewrite
Installing OpenXML
Installing DotNetCore
Starting Local SQL Server
Starting Internet Information Server
Copying Service Tier Files
Copying Web Client Files
Copying Windows Client Files
Copying PowerShell Scripts
Copying ConfigurationPackages
Copying Test Assemblies
Copying TestToolKit
Copying UpgradeToolKit
Copying Extensions
Copying ClientUserSettings
Copying ReportBuilder
Restoring CRONUS Demo Database
Determining Database Collation
Changing Database Server Collation to Latin1_General_100_CI_AS
Restoring CRONUS Demo Database
Installing C:\NAVDVD\Installers\DE\RTC\RoleTailoredClient.Local.De.msi
Skipping C:\NAVDVD\Installers\DE\WebHelp\WebHelp.Local.De.msi
Modifying Business Central Service Tier Config File for Docker
Creating Business Central Service Tier
Installing SIP crypto provider: 'C:\Windows\System32\NavSip.dll'
Installation took 136 seconds
Installation complete
Initializing...
Setting host.containerhelper.internal to xxx.xx.112.1 in container hosts file
Starting Container
Hostname is kise-bc14-dw
PublicDnsName is docker.xxx.de
Using AccessControlService Authentication
Certificate File Thumbprint 965BE54B08B9AB67FBE0C37775CEB423DE511C8F
Import Certificate to LocalMachine\my
Modifying Service Tier Config File with Instance Specific Settings
Modifying Service Tier Config File with settings from environment variable
Setting ValidAudiences to 00000000-0000-0000-0000-000000000000;https://api.businesscentral.dynamics.com
Setting DisableTokenSigningCertificateValidation to True
Setting ExtendedSecurityTokenLifetime to 24
Setting ClientServicesCredentialType to NavUserPassword
Setting EnableTaskScheduler to True
Setting PublicODataBaseUrl to https://docker.xxx.de/kise-bc14-dwrest/odata
Setting PublicSOAPBaseUrl to https://docker.xxx.de/kise-bc14-dwsoap/ws
Setting PublicWebBaseUrl to https://docker.xxx.de/kise-bc14-dw
Starting Service Tier
Registering event sources
Creating DotNetCore Web Server Instance
Using license file 'c:\run\my\license.flf'
Import License
Creating http download site
Setting SA Password and enabling SA
Creating admin as SQL User and add to sysadmin
Creating SUPER user
Assign Premium plan for ADMIN
Container IP Address: xxx.xx.120.120
Container Hostname  : kise-bc14-dw
Container Dns Name  : docker.xxx.de
Web Client          : https://docker.xxx.de/kise-bc14-dw/
Dev. Server         : https://docker.xxx.de
Dev. ServerInstance : NAV
Setting kise-bc14-dw to xxx.xx.120.120 in host hosts file

Files:
http://docker.xxx.de:8080/ALLanguage.vsix

Container Total Physical Memory is 511.9Gb
Container Free Physical Memory is 305.2Gb

Initialization took 64 seconds
Ready for connections!
remove C:\NAVDVD
Initializing...
Setting host.containerhelper.internal to xxx.xx.112.1 in container hosts file
Restarting Container
PublicDnsName unchanged
Hostname is kise-bc14-dw
PublicDnsName is docker.xxxde
Using AccessControlService Authentication
Starting Local SQL Server
Starting Internet Information Server
Starting Service Tier
Container IP Address: xxx.xx.126.200
Container Hostname  : kise-bc14-dw
Container Dns Name  : docker.xxx.de
Web Client          : https://docker.xxx.de/kise-bc14-dw
Dev. Server         : https://docker.xxx.de
Dev. ServerInstance : NAV
Setting kise-bc14-dw to xxx.xx.126.200 in host hosts file

Files:
http://docker.xxx.de:8080/ALLanguage.vsix

Container Total Physical Memory is 511.9Gb
Container Free Physical Memory is 307.8Gb

Initialization took 15 seconds
Ready for connections!
Initializing...
Setting host.containerhelper.internal to xxx.yy.32.1 in container hosts file
Restarting Container
PublicDnsName unchanged
Hostname is kise-bc14-dw
docker : Get-CIMInstance : Call was canceled by the message filter.
In Zeile:1 Zeichen:1
+ docker logs kise-bc14-dw
+ ~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (Get-CIMInstance...essage filter. :String) [], RemoteException
    + FullyQualifiedErrorId : NativeCommandError

PublicDnsName is docker.xxx.de
Using AccessControlService Authentication
Starting Local SQL Server
At C:\Run\start.ps1:46 char:16
WARNING: Waiting for service 'SQL Server (SQLEXPRESS) (MSSQL$SQLEXPRESS)' to
start...
WARNING: Waiting for service 'SQL Server (SQLEXPRESS) (MSSQL$SQLEXPRESS)' to
start...
WARNING: Waiting for service 'SQL Server (SQLEXPRESS) (MSSQL$SQLEXPRESS)' to
start...
Starting Internet Information Server
Starting Service Tier
Container IP Address: xxx.yy.47.49
+ $cimInstance = Get-CIMInstance Win32_OperatingSystem
+                ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (root\cimv2:Win32_OperatingSystem:
   String) [Get-CimInstance], CimException
    + FullyQualifiedErrorId : HRESULT 0x80010002,Microsoft.Management.Infrastr
   ucture.CimCmdlets.GetCimInstanceCommand

Container Hostname  : kise-bc14-dw
Container Dns Name  : docker.xxx.de
Web Client          : https://docker.xxx.de/kise-bc14-dw
Dev. Server         : https://docker.xxx.de
Dev. ServerInstance : NAV
Setting kise-bc14-dw to xxx.yy.47.49 in host hosts file

Files:
http://docker.xxx.de:8080/ALLanguage.vsix

Container Total Physical Memory is 511.9Gb
Container Free Physical Memory is 323.3Gb

Initialization took 318 seconds
Ready for connections!

our sever was updated this weekend.
We will try to rollback updates today evening hoping that it'll work again.

Are these "old" containers?
Are they process or hyperv isolation?
If you create a new container - can you then stop and start it?

Yes, these were "old" containers - created before the windows update.
They were created with process isolation. (We din't set any specific isolation - the default is "process isolation", isn't it?).
Yes newly created containers can be started and stopped.

At out company, there are about 60 pipelines that stopped working. Please fix this asap

@matthias-planzer - this seems to be a different problem, you would need to create a new issue with the full output of your failing pipeline. We will be generating new generic images today for the updated container OS' - this might also fix your issue, but you should not be in a position, where you cannot work if the host is updated before the new generic image is published, then you might have this problem every month.
The problem @pri-kise has is that he has created a number of process isolation containers (where the container and the host shares the core). Then he stops the containers, updates the host and re-starts the host.
This sometimes works - and sometimes the changes in the OS is significant enough for this to fail.
This is not something I can fix.

@pri-kise that is a coincidence, I cannot tell you why - it is kind of like copying the content of c:\windows from one version of windows on top of another. Some things might work - some things might not.
In general, my recommendation has always been to save the script, which creates the container - not the container.
If you need long running containers, hyperv is your friend as this removes the dependency on the host OS.


Spawn handling

How can I make Multiverse spawn you at the default spawn in the default world 'flatroom' whenever you die, no matter what world you died in?
I have set the thing in essentials config to "lowest" (so multiverse handles spawning)

This can be done by using respawninworld.


[BUG] Not appearing the rendering mode option on fastflags

Acknowledgement of preliminary instructions

[X] I have read the preliminary instructions, and I am certain that my problem has not already been addressed.

What problem did you encounter?
Wanted to change the rendering mode but it just disappeared, i cant find it, did it got removed or something?

this is what i see

https://github.com/pizzaboxer/bloxstrap/releases/tag/v2.5.4

oh, thanks


NJsonSchema.CodeGeneration.CSharp.CSharpGenerator not available in nuget package

Using nuget package 10.1.24 this item is not available:
var generator = new CSharpGenerator(schema);
There is no  "CodeGeneration" under namespace "NJsonSchema"
Even though I can clearly see this in the source code.  Any idea what's wrong?

It was in other nuget packages.


Issue with "Preferences / Restore to Default"

I just found an issue with the LogViewer.
Pressing the "Restore Defaults" button causes the confirmation box to appear, but pressing "No" results in crash / close of the entire LogViewer application!

That makes it very uncomfortable if you misclick on that button and then try to cancel the operation.
Also i would like to suggest a feature to toggle to a "dark" theme instead, so data can be read over a longer amount of time without hurting your eyesight. Currently i need to set all of the "background" colors for all log types by myself. But that works only to the point where a Querry results in less then an entire page of results. The empty space is then white.

For the dark theme: pull requests are always welcome :)

May I ask why you plan to spend several hours reading log files from Monal?

Very good. Thank you for addressing suggestions!


Increase test coverage in migration/version_spec

This changes the mocking level in migration/version_spec, to cover more code path in rspec.

Codecov Report

:exclamation: No coverage uploaded for pull request base (51e3281fd8c0f0bfb920c418004554c94bc7e5c4@51e3281). Click here to learn what that means.
The diff coverage is n/a.

@@                             Coverage Diff                             @@
##             51e3281fd8c0f0bfb920c418004554c94bc7e5c4      #50   +/-   ##
===========================================================================
  Coverage                                            ?   96.70%
===========================================================================
  Files                                               ?       24
  Lines                                               ?      851
  Branches                                            ?        0
===========================================================================
  Hits                                                ?      823
  Misses                                              ?       28
  Partials                                            ?        0

Continue to review full report at Codecov.

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


Update docs to show parquet files need to be serialised with version 1.0 to be visible in the Azure ML studio

[Enter feedback here]
When saving parquet files as mltables, with one of the following ways, the file data is not viewable
# Assume we are going to save a pandas dataframe once split into train/test sets

# 1 doesn't work
df.to_parquet(Path(output_dir, "data.parquet"))

# nor 2
df.to_parquet(Path(output_dir, "data.parquet"), engine='pyarrow')

# nor 3
pyarrow_table = pa.Table.from_pandas(df)
pq.write_table(pyarrow_table, Path(output_dir, "data.parquet"))

# and finally save the MLTable file
table = mltable.from_parquet_files(paths=[{"pattern": "./*parquet"}])
table.save(Path(output_dir), overwrite=True)

Error:

However, if I explicitly use the Parquet version:
# Note the `version` flag within the `pq.write_table` function
pyarrow_table = pa.Table.from_pandas(df)
pq.write_table(pyarrow_table, Path(output_dir, "data.parquet"), version="1.0")

# and finally save the MLTable file
table = mltable.from_parquet_files(paths=[{"pattern": "./*parquet"}])
table.save(Path(output_dir), overwrite=True)

We can view the data:

Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: 916be6d5-bb68-5606-d124-66d56878c9c0
Version Independent ID: c03b4af4-1a7e-00bd-46c3-658c86b8d95a
Content: Working with tables in Azure Machine Learning - Azure Machine Learning
Content Source: articles/machine-learning/how-to-mltable.md
Service: machine-learning
Sub-service: mldata
GitHub Login: @samuel100
Microsoft Alias: samkemp

@adriantorrie
Thanks for your feedback! We will investigate and update as appropriate.

@adriantorrie
I've delegated this to @samuel100, a content author, to review and share their valuable insights.

Any updates?


feat: implement force logging entry

Hi guys
As issue: #1149
I want to force some log entry to logging regardless of its level
So we can pass force for custom users

We can use a different logger instance for this use case instead of changing the package public api