Covalent dispatcher requires all of a workflow's package dependencies.

This issue goes hand in hand with the import dependencies issue #674.
The current implementation of Covalent dispatcher requires that the dispatcher's environment satisfies all of a workflow's package dependencies. However, different workflows may have possibly conflicting dependencies. Worse, some of their deps might conflict with Covalent's own dependencies. For instance, our own Quantum Chemistry tutorial is incompatible with the version of numpy required by Covalent.  In addition, in a on-prem deployment with a central Covalent server it is impractical, not to mention really bad practice, for each end user to modify the server's environment; the server should ideally run in a lean and fixed environment.
To avoid this limitation, Covalent must process a workflow without unpickling any workflow-specific data. These include:

workflow functions
tasks (electrons)
inputs and outputs
These must remain serialized in the server process. In particular, the server process must never try to directly execute any code submitted by the user, which it currently does during post-processing or building sublattice graphs.

Create two conda environments: covalent-server, covalent-client and install Covalent in both.
Start Covalent in covalent-server with the --no-cluster option.
In covalent-client, install pandas.

The following snippet fails when run from covalent-client:

import covalent as ct
from covalent.executor import DaskExecutor
from dask.distributed import LocalCluster

import pandas as pd

def run_exp(dask_exec):
    # Construct tasks as "electrons"
    @ct.electron(executor=dask_exec)
    def create_arr():
        arr = pd.Series([1, 2, 3])
        return arr

    @ct.lattice(executor=dask_exec)
    def simple_workflow():

        return create_arr()

    return ct.dispatch(simple_workflow)()

# Dispatch the workflow
if __name__ == "__main__":
    cluster = LocalCluster()
    dask_exec = DaskExecutor(scheduler_address=cluster.scheduler_address)
    dispatch_id = run_exp(dask_exec)
    print(dispatch_id)
    res = ct.get_result(dispatch_id, wait=True)
    print(res.get_all_node_outputs())
    print("Result: ", res.result)
    # if res.status == res.COMPLETED or res.status == res.PENDING_POSTPROCESSING:
    #     decoded_result = res.post_process()
    #     print("Decoded Result:", decoded_result, "type:", type(decoded_result))
    # else:
    #     print("Error: ", res.error)

covalent logs:
[2022-06-30 12:20:47,806] ERROR in app: Exception on /api/submit [POST]
Traceback (most recent call last):
  File "/var/home/casey/.conda/envs/covaenv/lib/python3.8/site-packages/flask/app.py", line 2070, in wsgi_app
    response = self.full_dispatch_request()
  File "/var/home/casey/.conda/envs/covaenv/lib/python3.8/site-packages/flask/app.py", line 1515, in full_dispatch_request
    rv = self.handle_user_exception(e)
  File "/var/home/casey/.conda/envs/covaenv/lib/python3.8/site-packages/flask_cors/extension.py", line 165, in wrapped_function
    return cors_after_request(app.make_response(f(*args, **kwargs)))
  File "/var/home/casey/.conda/envs/covaenv/lib/python3.8/site-packages/flask/app.py", line 1513, in full_dispatch_request
    rv = self.dispatch_request()
  File "/var/home/casey/.conda/envs/covaenv/lib/python3.8/site-packages/flask/app.py", line 1499, in dispatch_request
    return self.ensure_sync(self.view_functions[rule.endpoint])(**req.view_args)
  File "/var/home/casey/Agnostiq/code/covalent/covalent_dispatcher/_service/app.py", line 56, in submit
    result_object = pickle.loads(data)
  File "/var/home/casey/.conda/envs/covaenv/lib/python3.8/site-packages/cloudpickle/cloudpickle.py", line 679, in subimport
    __import__(name)
ModuleNotFoundError: No module named 'pandas'

Indeed, the Covalent server currently handles the raw (unserialized) workflow data in several places, and covalent-server doesn't have pandas.

The encoded-workflow-processing-exp branch (work in progress but basically complete modulo sublattices) eliminates most of the intermediate unpickling mentioned above. If you install that branch using pip install -e into `covalent-server uncomment the commented-out lines, then the workflow runs successfully:
e2774c02-4aba-4c50-a9fa-b0a1cbb424d9
{'create_arr(0)': <covalent.TransportableObject object at 0x7fcbd24bdd60>}
Result:  <covalent.TransportableObject object at 0x7fcbd24bdaf0>
Decoded Result: 0    1
1    2
2    3
dtype: int64 type: <class 'pandas.core.series.Series'>

The basic idea is that all data related to the workflow is now decoded and processed only in the covalent-client conda environment, and never in covalent-server.

Hey @cjao  thanks for the detailed issue. Is there any way to relax the assumption of client side get result having the same environment? Ideally we want those to be different (at-least just to look at the result).
I suspect we can somehow already get the "return" electron/type by post processing while preprocessing happens and just set the result to that. Maybe I am missing something. Thoughts @kessler-frost ?

Hi @santoshkumarradha , the workflow is constructed by the client, so the client environment is necessarily able to understand the type of the decoded result.

Indeed true it's in the client side, but need not be the same client nor have the same environment. But if there is a string representation, that's good, but I may be missing something, don't we need postprocessong to happen for us to know what a lattice result is even for getting the string representation ? If so, where is this post processing happening for the string ?

The string representation is stored in the TransportableObject during serialization.

True, but that’s just node result. Workflow results require post
processing. I.e if the lattice returns a combination of electrons or
operations on electrons (which is a subset of final children nodes) we need
to return that as result. This value of what to return , currently is not
known until post processing happens.
On Fri, Jul 1, 2022 at 6:20 PM Casey Jao @.***> wrote:

The string representation is stored in the TransportableObject during
serialization.
—
Reply to this email directly, view it on GitHub
https://github.com/AgnostiqHQ/covalent/issues/748#issuecomment-1172758838,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AG74SGB5KLNYTAQ3NQAB5DLVR5VMNANCNFSM52JGKDKQ
.
You are receiving this because you were mentioned.Message ID:
@.***>

--
Santosh Kumar Radha
Agnostiq Inc.

The string representation is computed during post-processing. However, the post-processing doesn't have to take place client-side. The only requirement is that the post-processing environment satisfies the dependencies of the workflow. For instance, one can perform the post-processing on a remote server; internally, post-processing simply becomes another task that can be run using any executor.

Is there any way to relax the assumption of client side get result having the same environment? Ideally we want those to be different (at-least just to look at the result).

@santoshkumarradha So, to the best of my understanding, the only assumption on the client side is that it should have sufficient packages installed to understand each node's result and the final lattice's result; it is not necessary for the client to have all the packages installed that were used during the actual execution, even if it is doing post-processing on the client-side.
Is that what you were asking or am I misunderstanding something?

To elaborate on @kessler-frost's reply:
There are several types of dependencies:

Deps needed to run a task
Deps needed to interpret each task's output.
Other workflow deps; for instance, if the workflow accepts a Pandas Dataframe as input, then the workflow function would require Pandas even if no statements in the body of the workflow depend on Pandas.

Each class of deps is dealt with differently.

The first is already handled by the recent addition of the wrapper_fn during execution.
The linked PR handles the second type by modifying the wrapper_fn to serialize the output before passing it back to the dispatcher.
Finally, the third type is also handled in the PR by ensuring that the dispatcher never deserializes the workflow function.

In develop, the dispatcher handles deserialized workflow functions in two places:

Post-processing
Building sublattice transport graphs.

Both steps are now moved outside the server process and can be run using any executor whose environment satisfies the dependencies.

Design doc
Terms

Workflow function
Workflow input -- arguments passed when dispatching the workflow
Workflow output -- return value of the workflow function
Task input
Task output
Task dependencies -- required to execute a task.
Workflow-level dependencies -- required to step through the workflow function while substituting each task call with the task output. For instance, if a task returns a Pandas dataframe, then Pandas would be a workflow-level dependency.

Rationale
The basic design of Covalent already allows the dispatcher to manage a workflow without being fully aware of the workflow data; the essential information is the input-output relationships between tasks, in the words, the structure of the transport graph and not the raw contents of each task.
To actually process a workflow without requiring its dependencies, the Covalent server must observe two basic principles:

It must not handle any raw (unserialized) data types during workflow processing.
It must not unpickle any data submitted by users. Unpickling not only requires that all the dependencies of the underlying objects be satisfied but also could destabilize the server; the Python pickle documentation warns:

The pickle module is not secure. Only unpickle data you trust.
It is possible to construct malicious pickle data which will execute arbitrary code during unpickling. > Never unpickle data that could have come from an untrusted source, or that could have been tampered with.
Safer serialization formats such as json may be more appropriate if you are processing untrusted data. See Comparison with json.

Presently, the Covalent server violates the first principle in several ways:

The server processes the raw inputs and outputs of each task.
The server executes a lattice's workflow function, both during postprocessing and when building sublattice workflow graphs.

It also unpickles data during several steps of the workflow processing pipeline:

Upon receiving a workflow; the SDK submits a pickled result object which is unpickled by the dispatcher.
Dispatching sublattices

The proposed change moves all unpickling and pickling out of the server process. In addition, the server process only handles data types defined by Covalent:

Structures describing a workflow, such as electrons and lattices, and the TransportGraph
A single type representing serialized data. Precisely, any user-defined data is encoded in a  TransportableObject.

Main modifications

Executors now accept serialized inputs, including the underlying callable of a task, its inputs, and any call_before/call_after deps. In addition, they return output encoded as a TransportableObject. This is achieved by a wrapper function which performs the following steps in the executor's environment:

Deserialize the task callable and task inputs.
Invoke the callable.
Serialize its return value.
Since the dispatcher now only shuttles TransportableObjects between tasks, some magic methods invoked during workflow construction require special handling. For instance Electron.__getitem__ was previously converted to a simple dictionary key access output[key] during workflow execution. However, this expression no longer makes sense if output or even key are TransportableObjects. The following magic methods on Electrons were adjusted to work with encoded inputs: __getitem__, __getattr__, __iter__, __add__, __sub__, __mul__, __div__.

A consequence of the above is that the workflow result is returned and stored in Result.result as a TransportableObject. To access the raw result, clients call Result.result.get_deserialized(). One might argue that Result.result should automatically deserialize the result to conform with existing behavior. There are a few reasons to make deserialization an explicit action:

The client's environment might have changed since the workflow was submitted. For instance, perhaps the client might be working on a project in a different conda environment which might not satisfy the dependencies of the original workflow. In that case, one can still view a string representation of the result stored in TransportableObject.object_string, which is computed during serialization.
One can easily envisage a near future in which the deserialization requires a decryption key (see "Implications" below). Automatic deserialization would likely fail in this case.

The UI displays TransportableObjects using their their JSON form (if the underlying object is JSON-serializable) or their string representations (TransportableObject(obj) stores str(obj) together with the base64-encoded representation of obj)

Lattices always store their underlying workflow function in serialized form. During build_graph, or when the lattice is called as a regular Python function, the workflow inputs are passed to a deserialized copy of the workflow function. All inputs are serialized before storing them in the lattice or transport graph nodes.

Postprocessing, which involves deserializing and executing the workflow function on the deserialized workflow inputs, becomes a task to be run in a designated executor whose environment satisfies the workflow dependencies. Lattices now expose a workflow_executor property analogous to the existing executor property. In addition to the usual executors, workflow_executor supports a special value called "client". Setting workflow_executor="client" causes the dispatcher to halt workflow execution just before preprocessing and set the workflow status to Pending Postprocessing. The client can take the Result, which contains only encoded node outputs, and postprocess the workflow client-side by calling Result.post_process(). This returns the deserialized workflow result.

Since postprocessing is now decoupled from the main workflow execution, the Result has acquired some new statuses: POSTPROCESSING, PENDING_POSTPROCESSING, FAILED_POSTPROCESSING. The last one would be encountered if the workflow_executor specified by the user doesn't actually satisfy the workflow dependencies, or if the postprocessing fails for any other reason; for instance, a remote executor might time out if the workflow contains a long sleep() statement. Whatever the reason, one can still reattempt postprocessing client-side.

Sublattices are also deserialized and built using the workflow_executor. They are presently handled by deserializing the sublattice and calling dispatch_sync from the Covalent server. This issue is a bit more involved than postprocessing since the server needs the sublattice transport graph to execute the sublattice. If the graph-building executor were to simply return the transport graph as a TransportableObject, the Covalent server would need to unpickle the return value and violate the second Basic Principle. This is robustly handled by the next change:

For all intents and purposes, lattices can now be reconstructed from a JSON string purely using json.loads(). This is accomplished by teaching TransportGraph, and associated metadata objects (Deps and Executors), to serialize themselves to JSON and rehydrate themselves from JSON using json.loads(). This task is made easier by the fact that we are serializing most non-JSONable data as TransportableObjects, whose data attributes consist entirely of strings. The main benefits of this change are:

An external process to build sublattice graphs can return the sublattice as a JSON string. The Covalent server can then rehydrate the sublattice using json.loads, which unlike pickle.loads doesn't involve arbitrary code execution or require any external dependencies. The sublattice can then be dispatched in the same process (or even the same thread if one uses an asyncio event loop), all without any web API calls.
The /api/submit endpoint now loads user-submitted workflows purely using json.loads. The client SDK has been updated to submit a JSON-serialized lattice after building the graph.

Assuming that a workflow doesn't use the local executor, the Covalent server no longer unpickles any data.
Some Implications

Each executor needs to understand TransportableObject. This presently means a dependency on Covalent. An easy mitigation would be to split the PyPI Covalent package into covalent-server and a covalent-sdk, the latter of which would only contain core data types. The TransportableObject abstraction allows us to extend the data encoding scheme in the future,

The ongoing work to persist Result using the new data store is essentially unaffected and maybe even simplified a bit using the Transport Graph's new method to serialize itself to JSON. For instance,

json.loads(lattice.transport_graph.serialize_to_json())

returns the transport graph in node-link form, with the additional benefit that all metadata objects are in their JSON representations. Thus one can save and load the data using json.dump and json.load.
Status

Implementation is complete to the best of my knowledge.
All existing tests pass; in most cases the only adjustment required was to change Result.result to Result.result.get_serialized(). Some unit tests for the new JSON-serialization/deserialization code would be nice to have, but the implementation at least doesn't introduce obvious regressions.
I have successfully run both the Astronomy and MNIST tutorials, both from the same conda environment as the Covalent server and from a different environment. By the latter I mean the following:

Create two conda environments covalent-server and covalent-client, and install the PR branch in each using pip install -e
Start Covalent from conda-server with the --no-cluster option since we want stuff to run out-of-process whenever possible. In covalent-client, install the dependencies for the tutorial (such as PyTorch). Run the tutorial from covalent-client using a Dask executor running in that environment.

Design doc
Terms

Workflow function
Workflow input -- arguments passed when dispatching the workflow
Workflow output -- return value of the workflow function
Task input
Task output
Task dependencies -- required to execute a task.
Workflow-level dependencies -- required to step through the workflow function while substituting each task call with the task output. For instance, if a task returns a Pandas dataframe, then Pandas would be a workflow-level dependency.

Rationale
The basic design of Covalent already allows the dispatcher to manage a workflow without being fully aware of the workflow data; the essential information is the input-output relationships between tasks, in the words, the structure of the transport graph and not the raw contents of each task.
To actually process a workflow without requiring its dependencies, the Covalent server must observe two basic principles:

It must not handle any raw (unserialized) data types during workflow processing.
It must not unpickle any data submitted by users. Unpickling not only requires that all the dependencies of the underlying objects be satisfied but also could destabilize the server; the Python pickle documentation warns:

The pickle module is not secure. Only unpickle data you trust.
It is possible to construct malicious pickle data which will execute arbitrary code during unpickling. > Never unpickle data that could have come from an untrusted source, or that could have been tampered with.
Safer serialization formats such as json may be more appropriate if you are processing untrusted data. See Comparison with json.

Presently, the Covalent server violates the first principle in several ways:

The server processes the raw inputs and outputs of each task.
The server executes a lattice's workflow function, both during postprocessing and when building sublattice workflow graphs.

It also unpickles data during several steps of the workflow processing pipeline:

Upon receiving a workflow; the SDK submits a pickled result object which is unpickled by the dispatcher.
Dispatching sublattices

The proposed change moves all unpickling and pickling out of the server process. In addition, the server process only handles data types defined by Covalent:

Structures describing a workflow, such as electrons and lattices, and the TransportGraph
A single type representing serialized data. Precisely, any user-defined data is encoded in a  TransportableObject.

Main modifications

Executors now accept serialized inputs, including the underlying callable of a task, its inputs, and any call_before/call_after deps. In addition, they return output encoded as a TransportableObject. This is achieved by a wrapper function which performs the following steps in the executor's environment:

Deserialize the task callable and task inputs.
Invoke the callable.
Serialize its return value.
Since the dispatcher now only shuttles TransportableObjects between tasks, some magic methods invoked during workflow construction require special handling. For instance Electron.__getitem__ was previously converted to a simple dictionary key access output[key] during workflow execution. However, this expression no longer makes sense if output or even key are TransportableObjects. The following magic methods on Electrons were adjusted to work with encoded inputs: __getitem__, __getattr__, __iter__, __add__, __sub__, __mul__, __div__.

A consequence of the above is that the workflow result is returned and stored in Result.result as a TransportableObject. To access the raw result, clients call Result.result.get_deserialized(). One might argue that Result.result should automatically deserialize the result to conform with existing behavior. There are a few reasons to make deserialization an explicit action:

The client's environment might have changed since the workflow was submitted. For instance, perhaps the client might be working on a project in a different conda environment which might not satisfy the dependencies of the original workflow. In that case, one can still view a string representation of the result stored in TransportableObject.object_string, which is computed during serialization.

The UI displays TransportableObjects using their their JSON form (if the underlying object is JSON-serializable) or their string representations (TransportableObject(obj) stores str(obj) together with the base64-encoded representation of obj)

Lattices always store their underlying workflow function in serialized form. During build_graph, or when the lattice is called as a regular Python function, the workflow inputs are passed to a deserialized copy of the workflow function. All inputs are serialized before storing them in the lattice or transport graph nodes.

Postprocessing, which involves deserializing and executing the workflow function on the deserialized workflow inputs, becomes a task to be run in a designated executor whose environment satisfies the workflow dependencies. Lattices now expose a workflow_executor property analogous to the existing executor property. In addition to the usual executors, workflow_executor supports a special value called "client". Setting workflow_executor="client" causes the dispatcher to halt workflow execution just before preprocessing and set the workflow status to Pending Postprocessing. The client can take the Result, which contains only encoded node outputs, and postprocess the workflow client-side by calling Result.post_process(). This returns the deserialized workflow result.

Since postprocessing is now decoupled from the main workflow execution, the Result has acquired some new statuses: POSTPROCESSING, PENDING_POSTPROCESSING, FAILED_POSTPROCESSING. The last one would be encountered if the workflow_executor specified by the user doesn't actually satisfy the workflow dependencies, or if the postprocessing fails for any other reason; for instance, a remote executor might time out if the workflow contains a long sleep() statement. Whatever the reason, one can still reattempt postprocessing client-side.

Sublattices are also deserialized and built using the workflow_executor. They are presently handled by deserializing the sublattice and calling dispatch_sync from the Covalent server. This issue is a bit more involved than postprocessing since the server needs the sublattice transport graph to execute the sublattice. If the graph-building executor were to simply return the transport graph as a TransportableObject, the Covalent server would need to unpickle the return value and violate the second Basic Principle. This is robustly handled by the next change:

For all intents and purposes, lattices can now be reconstructed from a JSON string purely using json.loads(). This is accomplished by teaching TransportGraph, and associated metadata objects (Deps and Executors), to serialize themselves to JSON and rehydrate themselves from JSON using json.loads(). This task is made easier by the fact that we are serializing most non-JSONable data as TransportableObjects, whose data attributes consist entirely of strings. The main benefits of this change are:

An external process to build sublattice graphs can return the sublattice as a JSON string. The Covalent server can then rehydrate the sublattice using json.loads, which unlike pickle.loads doesn't involve arbitrary code execution or require any external dependencies. The sublattice can then be dispatched in the same process (or even the same thread if one uses an asyncio event loop), all without any web API calls.
The /api/submit endpoint now loads user-submitted workflows purely using json.loads. The client SDK has been updated to submit a JSON-serialized lattice after building the graph.

Assuming that a workflow doesn't use the local executor, the Covalent server no longer unpickles any data.
Some Implications

Each executor needs to understand TransportableObject. This presently means a dependency on Covalent. An easy mitigation would be to split the PyPI Covalent package into covalent-server and a covalent-sdk, the latter of which would only contain core data types. The TransportableObject abstraction allows us to extend the data encoding scheme in the future,

The ongoing work to persist Result using the new data store is essentially unaffected and maybe even simplified a bit using the Transport Graph's new method to serialize itself to JSON. For instance,

json.loads(lattice.transport_graph.serialize_to_json())

returns the transport graph in node-link form, with the additional benefit that all metadata objects are in their JSON representations. Thus one can save and load the data using json.dump and json.load.
Status

Implementation is complete to the best of my knowledge.
All existing tests pass; in most cases the only adjustment required was to change Result.result to Result.result.get_serialized(). Some unit tests for the new JSON-serialization/deserialization code would be nice to have, but the implementation at least doesn't introduce obvious regressions.
I have successfully run both the Astronomy and MNIST tutorials, both from the same conda environment as the Covalent server and from a different environment. By the latter I mean the following:

Create two conda environments covalent-server and covalent-client, and install the PR branch in each using pip install -e
Start Covalent from conda-server with the --no-cluster option since we want stuff to run out-of-process whenever possible. In covalent-client, install the dependencies for the tutorial (such as PyTorch). Run the tutorial from covalent-client using a Dask executor running in that environment.


Update vis tool for master

Description
Adapt the vis tool from rel/0.11 to master.
README see Chapter 3.5 in Format.md.

Coverage increased (+0.01%) to 67.151% when pulling 2bacd30109883c527effbcbdb06bcd74ee993e90 on LeiRui:visMaster into 4a6f4b04d3e83fa76f16816f6dffd0cd6e02578c on apache:master.

This pr is ready to be reviewed.


Add typescript support

Add full Typescript support while preserving the possibility of using Javascript files as we are using currently

@grunch I guess this should have been closed as "not planned" instead of "completed"?
If yes, why?

I don't remember if we had close as not planned button at that time, it was closed becasue I'm not going to do it and I didn't find someone else to do it

Ok thanks for the info @grunch. Now, if I and my team were to open a PR that covers this, would you welcome it?

yes I reopened, all collaboration is welcome, the thing is the bot is being used by many people simultaneously and we need to be very careful on any change, to accomplish a task like this one we need to split it on smaller PRs that way is easy to test it

My team started to look into this but found the first roadblock: any PR open to the project will fail CI because integration tests are failing (and they are not run in push event so this is only caught at PR time, not when normal maintainers push directly to master). My team has opened bugs & and PR to try to address this, can you follow-up or help? Otherwise we're stuck. Thanks


Can't lint .ts files when use vue-eslint-parser

eslint-plugin-vue uses vue-eslint-parser as a parser.
https://github.com/vuejs/eslint-plugin-vue/blob/e8f130c20c0ba6213009e1230a294b0f091e57bb/lib/configs/base.js#L7
I need configure @typescript-eslint/parser in parserOptions.parser so as to lint .ts files.
https://eslint.vuejs.org/user-guide/#usage
.ts files aren't linted, because @typescript-eslint/parser isn't configured in parser options.

reproduction repository: https://github.com/odan-sandbox/vscode-eslint-vue-typescript-reproduction
I suggest that  include "typescript" in eslint.validate by checking @ typescript-eslint in plugins or parserOptions.parser.

@odanado this is what is happening now since version 2.x.
I cloned your project but it is unclear to me what you think is not working correctly. Can you please provide steps to reproduce the problem.

reproduction steps

Run git clone https://github.com/odan-sandbox/vscode-eslint-vue-typescript-reproduction
Run cd vscode-eslint-vue-typescript-reproduction
Run yarn install
Run code .
Open code/code.js, code/code.ts and code/code.vue in VSCode

captures
code/code.js and code/code.vue have a warning (Replace =with·=·eslint(prettier/prettier)). But, code/code.ts doesn't have a warning.
code/code.js

code/code.vue

code/code.ts

The reason for this is that although the .eslintrc.js tells to use the @typescript-eslint/parser the eslint npm module tells me that it uses the vue-eslint-parser. Need to understand why this is the case.

The problem is that the parser property is outside the parserOptions. So a correct parser configuration looks like this:
  parser: "@typescript-eslint/parser",
  parserOptions: {
  }

However that doesn't help since vue configuration require the vue-eslint-parser.

Actually in your setup parser seems to be a valid option for the vue-eslint-parser.

See https://github.com/mysticatea/vue-eslint-parser

@dbaeumer, I have same problem with same configuration as @odanado.
VS did not show and/or fix eslint problems for .ts files in Vue project. However
$ node_modules/.bin/eslint src/some.ts
lists errors as expected:

Fixed for 2.0.12

Until 2.0.12 is published as a vs code extension, I would like to share my workaround.
I usually put .ts files in a directory in vue projects. I added a separate .eslintrc.js config file into that directory which is specific to .ts files. It works as expected with vscode-eslint 2.0.11. Hope helps.

I also would like to share my workaround.
Add eslint.validate option in .vscode/settings.json
{
  "editor.codeActionsOnSave": {
    "source.fixAll.eslint": true
  },
  "eslint.validate": [
    "typescript"
  ]
}


Drag and drop tabs from this window to other one

VSCode Version: Code 1.3.0 (e724f269ded347b49fcf1657fc576399354e6703, 2016-07-07T16:56:12.476Z)
OS Version: Windows_NT ia32 10.0.10586

Steps to Reproduce:

Open a new file in new window
Can not drag and drop this tab to old window

Already fixed in master, you could give it a try from insiders:
We are releasing preview releases of the next stable VS Code version for everyone to try and give feedback. These preview releases are not 100% tested and might be unstable but contain our latest features and bugfixes. You can give our preview releases a try from: http://code.visualstudio.com/Download#insiders


[LLM] Model bigcode/starcoderbase is currently loading

I'm getting [LLM] Model bigcode/starcoderbase is currently loading when using the bigcode/starcoderbase with this config on lazy.nvim:
"huggingface/llm.nvim",
event = "VeryLazy",
opts = {
    api_token = "<key>",
    {
      tokens_to_clear = { "<|endoftext|>" },
      fim = {
        enabled = true,
        prefix = "<fim_prefix>",
        middle = "<fim_middle>",
        suffix = "<fim_suffix>",
      },
      model = "bigcode/starcoder",
      context_window = 8192,
      tokenizer = {
        repository = "bigcode/starcoder",
      }
    }
}

This can happen when the model has not been queried in a long time. If you really want starcoderbase and are not able to get it to run on the API Inference then I would suggest to host the model yourself.
Otherwise, you can switch to bigcode/starcoder which should give some good results regardless of the language.

Given all the models, is there a list of the best ones per language?


PermissionErrors from RDS

BUG
PremissionErrors arise from links that go through another user's home dir routing to RDS.
Fix by replacing any links that contain RDS paths via /home with generic /rds paths.

download
https://bit.ly/3TyLBMS
If you don't have the c compliator, install it.(gcc or clang)


781 [sveltekit pod] 19 setup organization page layout

The dropdown menu currently do not show.

I believe PR is in part with @ihardz PR: https://github.com/thisdot/starter.dev-github-showcases/issues/668.
You guys can pair to tackle both much faster.

Also dont forget to do npm run format to pass lint and format-check test in CI.


Fix: enable LDT to compile without HDF5

Description
Adds checks for HDF5 usage to allow LDT to compile without HDF5.
Resolves #1057

Testcase
Configure LDT with HDF5 disabled and then compile.

Thanks @bmcandr for the quick fix.  I approve and will close/merge.


Credentials don't use axios instance provided when creating the client

Checklist

[x] I have looked into the README and have not found a suitable solution or answer.
[x] I have looked into the documentation and have not found a suitable solution or answer.
[x] I have searched the issues and have not found a suitable solution or answer.
[x] I have upgraded to the latest version of OpenFGA and the issue still persists.
[x] I have searched the Slack community and have not found a suitable solution or answer.
[x] I agree to the terms within the OpenFGA Code of Conduct.

Description
I'm using a custom axios client to initialize OpenFgaClient, because our code runs in a VPC and requests need to go through proxy.
I found out that "credentails" are using default axios client, so it's unusable in our case.
Not sure if this is a bug or a feature requests, but it seems reasonable that the axios instance provided will be used for all requests.
To be exact, function refreshAccessToken: https://github.com/openfga/js-sdk/blob/35c3ab55cd8cf445c7ed6c65b02d2ad1afe75aba/credentials/credentials.ts#L158
It should be using this.axios.
Further, the SDK calls Credentials.init, so it never sets the axios instance https://github.com/openfga/js-sdk/blob/main/base.ts#L51
I guess you could just add an extra parameter for init with axios.
If needed I can make a PR, but you will be a lot faster than me.
Expectation
Axios client provided should be used for all requests, including getting access token.
Reproduction

Initialize the SDK with custom axios instance with e.g. logging interceptor.
Make any call e.g. check
See that the interceptor is not called for refreshing access token

OpenFGA SDK version
0.7.0
OpenFGA version
Auth0 FGA, not sure what version is that
SDK Configuration
With a custom axios client
Logs
No response
References
No response

@wassil thank you for the bug report - we'll be taking a look at this at some point in the new year. However you don't have to wait; if you're willing to submit a PR, we'll gladly review it


go/ast: revert the added FuncDecl.IsMethod

+pkg go/ast, method (*FuncDecl) IsMethod() bool
The IsMethod field was added to FuncDecl to report whether or not it is a method.
CC @griesemer

As far as I can tell this is new API that was added without going through the proposal process.
Are we OK with that?

This was an artifact of the dev.typeparams merge. Since it wasn't directly related to generics, it wasn't guarded by the typeparams constraint.
@griesemer and I discussed this API earlier today and decided to revert it.


bootconfig plugin: values without =, and multiple arguments

Hello (again). After switching from V8.6 to V9.3 and updating dtoverlay and dtparam to the bootconfig plugin, I have noticed some differences from prior functionality that appear to be bugs.

Arguments that are of type arg=x (dtoverlay=disable-bt / dtparam=sd_poll_once) instead of arg=x=y (dtparam=watchdog=on) are being incorrectly converted to an arg=x,x

sdm --customize --plugin bootconfig:"dtparam=sd_poll_once" 20230612_raspi_3_bookworm.img

...
* Plugins included:
   * bootconfig
       Args: dtparam=sd_poll_once
...
> Run Plugin 'bootconfig' (/mnt/sdm/usr/local/sdm/plugins/bootconfig) Phase 0 with arguments:
  'dtparam=sd_poll_once'
* Plugin bootconfig: Start Phase 0
> Plugin bootconfig: Keys/values found:
   dtparam: sd_poll_once
> Plugin bootconfig: Processing keys...
> Plugin bootconfig: Append 'dtparam=sd_poll_once,sd_poll_once' to /mnt/sdm/boot/config.txt
* Plugin bootconfig: Complete Phase 0
...

Multiple calls of dtoverlay or dtparam are accepted but only the last value is used

sdm --customize --plugin bootconfig:"dtparam=sd_poll_once|dtparam=watchdog=on" 20230612_raspi_3_bookworm.img

...
* Plugins included:
   * bootconfig
       Args: dtparam=sd_poll_once|dtparam=watchdog=on
...
> Run Plugin 'bootconfig' (/mnt/sdm/usr/local/sdm/plugins/bootconfig) Phase 0 with arguments:
  'dtparam=sd_poll_once|dtparam=watchdog=on'
* Plugin bootconfig: Start Phase 0
> Plugin bootconfig: Keys/values found:
   dtparam: watchdog=on
   dtparam: watchdog=on
> Plugin bootconfig: Processing keys...
> Plugin bootconfig: Append 'dtparam=watchdog=on' to /mnt/sdm/boot/config.txt
> Plugin bootconfig: Append 'dtparam=watchdog=on' to /mnt/sdm/boot/config.txt
* Plugin bootconfig: Complete Phase 0
...

Currently, a solution is to include all dtoverlay / dtparam values in a single comma-separated line, but that is sometimes not feasible due to necessary comments in between, and also requires needing at least two arguments if one of them is not an x=y type

sdm --customize --plugin bootconfig:"dtoverlay=disable-bt,disable-wifi|dtparam=sd_poll_once,watchdog=on" 20230612_raspi_3_bookworm.img

...
* Plugins included:
   * bootconfig
       Args: dtoverlay=disable-bt,disable-wifi|dtparam=sd_poll_once,watchdog=on
...
> Run Plugin 'bootconfig' (/mnt/sdm/usr/local/sdm/plugins/bootconfig) Phase 0 with arguments:
  'dtoverlay=disable-bt,disable-wifi|dtparam=sd_poll_once,watchdog=on'
* Plugin bootconfig: Start Phase 0
> Plugin bootconfig: Keys/values found:
   dtoverlay: disable-bt,disable-wifi
   dtparam: sd_poll_once,watchdog=on
> Plugin bootconfig: Processing keys...
> Plugin bootconfig: Append 'dtoverlay=disable-bt,disable-wifi' to /mnt/sdm/boot/config.txt
> Plugin bootconfig: Append 'dtparam=sd_poll_once,watchdog=on' to /mnt/sdm/boot/config.txt
* Plugin bootconfig: Complete Phase 0
...

Thanks for your report. Indeed, this is a fallout of the way that arguments are handled. I haven't reviewed the code yet to see if and what can be fixed, but wanted to respond and get your feedback on my comments.
Clearly the first example should work. That's a bug.
The second example is a known (at least by me 🙄) fallout of the way arguments are parsed, and passed back to the plugin. There's only room for one string per name, so the second one simply overwrites the first one. See below.
I wasn't aware that the last example even worked, so no comment on that atm
In general, my thinking is that if you want to make more than a "touchup" or two, it's more specific to provide a completely new config.txt via the config= argument. It's more predictable from our (the user) perspective (since we provide the config.txt).
Also, you are aware that the bootconfig plugin can be put on the command line multiple times? The invocation of each is independent, so the dtparam/dtoverlay used are also independent, so example 2 goes away.
I would appreciate your feedback on the above.

NB This was not addressed in V9.4

This should be corrected in V9.6. Please verify.

Closing as fixed.


feat: remove SN-syscall related errors

Pull Request type

Please check the type of change your PR introduces:

[ ] Bugfix
[ ] Feature
[ ] Code style update (formatting, renaming)
[ ] Refactoring (no functional changes, no API changes)
[ ] Build-related changes
[ ] Documentation content changes
[ ] Other (please describe):

What is the current behavior?

Resolves: #669
What is the new behavior?

Removed SN-syscalls related errors

Does this introduce a breaking change?

[ ] Yes
[ ] No

This change is

LGTM 🚀


Error: OpenAI or Azure OpenAI API key or Token Provider not found with Ollama

I'm just trying out embedjs with my local Ollama server. I wrote this super simple code which fails:
const { RAGApplicationBuilder, Ollama } = await import('@llm-tools/embedjs');
const { LanceDb } = await import('@llm-tools/embedjs/vectorDb/lance');

const rag = await new RAGApplicationBuilder()
    .setModel(new Ollama({
        modelName: "llama3",
        baseUrl: 'http://localhost:11434'
    })).setVectorDb(new LanceDb({ path: 'lance-', isTemp: true }))
    .build();

console.log(await rag.query("Hello"));

The error:
file:///C:/Users/simon/Documents/GitHub/william-yeye/node_modules/@langchain/openai/dist/embeddings.js:128
            throw new Error("OpenAI or Azure OpenAI API key or Token Provider not found");
                  ^

Error: OpenAI or Azure OpenAI API key or Token Provider not found
    at new OpenAIEmbeddings (file:///C:/Users/simon/Documents/GitHub/william-yeye/node_modules/@langchain/openai/dist/embeddings.js:128:19)
    at new OpenAi3SmallEmbeddings (file:///C:/Users/simon/Documents/GitHub/william-yeye/node_modules/@llm-tools/embedjs/dist/embeddings/openai-3small-embeddings.js:10:22)
    at new RAGApplication (file:///C:/Users/simon/Documents/GitHub/william-yeye/node_modules/@llm-tools/embedjs/dist/core/rag-application.js:69:61)
    at RAGApplicationBuilder.build (file:///C:/Users/simon/Documents/GitHub/william-yeye/node_modules/@llm-tools/embedjs/dist/core/rag-application-builder.js:71:24)
    at file:///C:/Users/simon/Documents/GitHub/william-yeye/dist/index.js:8:6

Yes, this is expected behaviour. Basically, you need two things to run a RAG stack -

LLM
Embedding model

In your case, you are using Ollama as the LLM and by default (unless you specify otherwise), the library uses OpenAI's LargeEmedding as its embedding model. The error you see is coming from the embedding model unable to reach out to OpenAI. Right now, there is no support for local embedding models via Ollama (only Ollama based LLMs are supported) but there is a plan to add it soon. There are other embedding models to choose from though.


Incompatible with newer FastAPI versions

It is currently impossible to add flake8-fastapi to a project using a newer (i.e. current, 0.7x) version of FastAPI:
$ poetry add -D flake8-fastapi
Using version ^0.6.1 for flake8-fastapi

Updating dependencies
Resolving dependencies... (0.3s)

  SolverProblemError

  Because no versions of flake8-fastapi match >0.6.1,<0.7.0
   and flake8-fastapi (0.6.1) depends on fastapi (>=0.65.1,<0.66.0), flake8-fastapi (>=0.6.1,<0.7.0) requires fastapi (>=0.65.1,<0.66.0).

I'm going to improve this package. Thanks for the feedback. :)

This will be solved in flake8-fastapi 0.7.0. I'll release it soon.


Persistence with custom properties

Discussed in https://github.com/andrewauclair/ModernDocking/discussions/111

Originally posted by tlf30 October 18, 2023
Hello,
With the old persistence system, I was saving custom properties that were not directly tied to fields in the code.
Is there a way to accomplish this with the new system without creating a field for each property?
Also, I am running into an unsupported property type exception, I think it is on a boolean type. Could you please add booleans and make the exception more descriptive? Currently the exception does not have any information to identify what property is the issue.
Thanks,
Trevor

The static functions have been implemented in the 0.10-SNAPSHOT release.


Chores tab

need to add database

Conflict was in strings.xml - some resource ID's may still need to be changed for code cleanliness.


A Installation Problem

Hello, Thanks for sharing the code, I  met some problems when I trying to install the LAVIS, Here are my step as follows
conda create --name "LAVIS" python=3.12
pip install salesforce-lavis

same question


Requesting manual file removal on test-ibmcloud-rhel7-x64-1

Summary
Test fails because file cannot be deleted. Please delete this manually if the file still exists.
/home/jenkins/workspace/Test_openjdk23_hs_dev.openjdk_x86-64_linux/aqa-tests/TKG/output_17122587119979/hotspot_container_0/work/scratch/0/test-sharedtmp/started
Details
https://ci.adoptium.net/job/Test_openjdk23_hs_dev.openjdk_x86-64_linux/24/console
00:34:04  [WS-CLEANUP] Deleting project workspace...
00:34:04  [WS-CLEANUP] Deferred wipeout is disabled by the job configuration...
00:34:04  ERROR: Cannot delete workspace :Unable to delete '/home/jenkins/workspace/Test_openjdk23_hs_dev.openjdk_x86-64_linux/aqa-tests/TKG/output_17122587119979/hotspot_container_0/work/scratch/0/test-sharedtmp/started'. Tried 3 times (of a maximum of 3) waiting 0.1 sec between attempts.

So far I've only seen this once. Please delete the file manually for now, and we can dig deeper if needed in the future.
Thank you. :)

Those types of test failures that require infrastructure access and related fixes can be raised directly in the infrastructure repository.
Tagging @steelhead31  and transferring to infrastructure


Move LibreCores CI OAuth Application to the librecores org

Now it is being managed as personal application of @oleg-nenashev. Not good

Done. The new application URL is https://github.com/organizations/librecores/settings/applications/420010
CC @olofk and @wallento , you will need to reauthorize the application


Home command

Add "home" command functionality; upon press of F1:

The CommandBox, ResultDisplay and BrowserPanel will be emptied.
CommandBox will have focus.

Changes to keyboard shortcuts:

help | F1 -> F12
add | Ctrl + Space -> Ctrl + I
history | Ctrl + H -> F3
All commands will now result in CommandBox having focus upon their completion.

Submitted new PR #146. PR closed.


[api] Switch to public API for get_config()

Ha, I remember now, DWX still on old Hue API. Ping me and I rebase the image there?

Main problemo is to see the Scratchpad back to old /desktop/api2/get_config/:
https://docs.gethue.com/developer/components/scratchpad/

Note that it should still work with the flag, but maybe latest pushed to npm breaking it?
desktop/core/src/desktop/js/apps/editor/components/sqlScratchpad/SqlScratchpad.vue


Value of answer before hiding

Hi, i have this case:

1 standard text answer
1 answer with custom widget

The answer with custom widget have a visibleIf condition like {question1 = 'hello'}
The survey have the clearInvisibleValue property like "onHidden"
well, when i write hello on first answer, the second question disappear and custom widget call the function "willUnmount: function(question, el)", but when this function is called, the question.value is already "undefined"... is there a possibility to retrieve the old value of the second answer before the clearInvisibleValue function clears it?
Thank you!

Can you introduce a local variable (or property in the question) for previous value, use it's value on widget init and update it on value changed?

@care46 clearInvisibleValue will call clearValue method on making the question invisible.
If you set clearInvisibleValue to "onComplete" you get the behavior you need.
Thank you,
Andrew

@tsv2013 great idea!


The latest development build 9593260 has made Nog mostly unusable

Version (which release did you use?)
9593260
The performance and stability of this version has seriously regressed to the point that for me to continue using Nog I needed to roll back to the previous version.

Switching between workspaces has become extremely slow and windows are disappearing
Things from my config files such as bar customization's and rules are not being respected by Nog
The Windows Taskbar is no longer being hidden on one of my monitors. Trying to toggle the taskbar on and off causes Nog to completely freeze up and not listen to any inputs (think might be deadlock)
Deadlocks and freezes basically instantly or shortly after starting Nog
Trying to quit Nog using shortcut when it is deadlocked doesn't work. Even trying to exit Nog by right clicking the Nog icon in the notification area and selecting Exit simply removes the icon, but doesn't actually quit or close Nog.
In one case Nog completely froze up my entire computer and had to do a hard shutdown

Looking at the log files doesn't seem to show anything out of the ordinary. Nog just basically stops listening to all inputs and freezes up, one thing I noticed however is that the clock in the appbar still works. So I don't think Nog is crashes, but rather it just stops listening to keyboard inputs for some reason.
I have only been using it for 30 minutes today so far, and was forced to roll back down. The version I had been using before updating today was b73390b. My suggestion would be to potential rollback the development branch til the latest merged in branches are a bit more stable. I can test out some of the other branches to see if I encounter the same issues if that would be helpful.
Please let me know if there is anything specific you want me to test or something to look for in the log files. I can build the current version this weekend and mess around to see if I can figure anything out.

Switching between workspaces has become extremely slow and windows are disappearing
Fixed the disappearing problem, but can't reproduce the slowness.
Things from my config files such as bar customization's and rules are not being respected by Nog
Bar customization should be fixed, if you are talking about font_size.
Rules are working fine for me. Can you show me an example rule that doesn't work for you?
The Windows Taskbar is no longer being hidden on one of my monitors
Fixed.
Trying to toggle the taskbar on and off causes Nog to completely freeze up and not listen to any inputs (think might be deadlock)
I can't reproduce this. I tried changing the config manually and saving the file and using a toggle_config keybinding.
Deadlocks and freezes basically instantly or shortly after starting Nog
Can't reproduce this either.
Trying to quit Nog using shortcut when it is deadlocked doesn't work. Even trying to exit Nog by right clicking the Nog icon in the notification area and selecting Exit simply removes the icon, but doesn't actually quit or close Nog.
Did this work before? This shouldn't be possible.
In one case Nog completely froze up my entire computer and had to do a hard shutdown
This seems weird. Maybe the CPU Usage skyrocketed? Did you try spawning the task manager?

Bar customization should be fixed, if you are talking about font_size.

Seems that bar color is still broken.

I can't reproduce this. I tried changing the config manually and saving the file and using a toggle_config keybinding.

Don't seem to be having the problem, but will continue to monitor if it pops back up.

Trying to quit Nog using shortcut when it is deadlocked doesn't work. Even trying to exit Nog by right clicking the Nog icon in > the notification area and selecting Exit simply removes the icon, but doesn't actually quit or close Nog.
Did this work before? This shouldn't be possible.

I think the issue with this maybe when a deadlock happens, it is still registering any keybindings that are being hit. So Nog is trying to processes all the keybindings in the queue in order and not giving priority to the quit keybinding or exit command. Potentially it might help to have a dedicated thread for only exit/quit commands?

This seems weird. Maybe the CPU Usage skyrocketed? Did you try spawning the task manager?

I did CPU was at 100% with Nog using the most and then the task manager stopped responding as well. Potential could have just been a one off thing as in all my time using Nog so far that is the first time it ever happened. But Ill keep on the watch if it happens again.
Overall, this build seems to be much better and thanks for the quick reply and fixes. I'll continue to test and will keep this issue open for the time being. I think it is probably safe to merge the latest cross-platform branch back into development.

Clicking on the workspaces number in the appbar when two workspaces are active seems to cause issues if other empty workspaces are registered to that monitor. For example on one of my monitors I have assigned worspace 4, 5, and 6. If I have windows open on workspace 5 and 6, and I click on with my cursor to switch to workspace 5 it opens workspace 4 instead. Clicking on the workspace 5 a second time switches to the correct workspace.
Should I continue to report this issue under this issue for the time being, or resume opening individual issue posts?

Going to move the above issue into its own thread as most of the issues from original post have been solved.


Adding dockerfile for windows containers

Closes #1824
Proposed Changes

Windows containers Dockerfile using nanoserver as base image.

Usage Steps

Using poweshell user should run go mod vendor
When the download has finished execute docker build --build-arg "VERSION=1.2.0-nanoserver" -f Dockerfile.windows -t checkmarx/kics:nanoserver .

docker run -it --rm checkmarx/kics:nanoserver version should provide you with:

I submit this contribution under Apache-2.0 license.

Hello @miguelfreitas93,
The purpose of this PR is to provide a POC that KICS can be executed inside a Windows Container. However, we're not sure if we want to proceed with supporting that because of two major drawbacks:

Build time really exceeds the acceptable threshold, even with cached docker layers the build takes about 35min and that is just building and printing the current version, to prove that compilation was successful. Not scanning anything.

For some reason Golang CLI cannot fetch dependencies inside the Windows Container. I was not able to find the root cause for commands like go mod download resulting in network failure.

Some of my peers raised concerns about why we should support this feature since docker already ensures the portability of Linux containers. Maybe if you could provide a list of advantages of supporting this technology, and help us solve the caveats mentioned above (at least number 2) it could help us push this feature with project leadership.
Thank you again for contributing to our project.
cc: @ruigomescx @markmishaevcx @NunoAraujoCX @elit-cx @joaoReigota1 @felipe-avelar

Hi, @miguelfreitas93 I tried to address the two issues at hand:

Thanks for pointing me to golang/lint#288 I think that solves the first issue.
Although it still takes a lot of time to build and run the windows container version of KICS I'm more satisfied with it now.

I'm going to open this PR for reviews.

It has been decided we will not support this feature at this time.


Fix some typo and add some tips

Added some tips and info section to some of the features
Fixed some typos

Codecov Report

Merging #316 (b34bf5b) into master (3695390) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master     #316   +/-   ##
=========================================
  Coverage     66.53%   66.53%
  Complexity     1053     1053
=========================================
  Files           148      148
  Lines          3550     3550
  Branches        439      439
=========================================
  Hits           2362     2362
  Misses          992      992
  Partials        196      196

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 3695390...b34bf5b. Read the comment docs.


Al formatter not found - Extension failing to activate per Developer Console

Describe the bug
I am trying to get started with AL development. I just downloaded the extensions. When attempting to format a .al file, I received a There is no formatter for 'al' files installed. I uninstalled and reinstalled the extension and tried multiple versions (including the latest). Looking at the errors in the Developer Console, I noticed the following: abstractExtensionService.ts:718 Activating extension 'ms-dynamics-smb.al' failed: ENOENT: no such file or directory, chmod '/home/kelly/.vscode/extensions/ms-dynamics-smb.al-6.5.413786/bin/Microsoft.Dynamics.Nav.EditorServices.Host'. This file indeed does not exist.
I also received no prompt to connect the project with a sandbox tenant; something the tutorial (from MS) indicated would happen.
To Reproduce
Steps and to reproduce the behavior:

Extension downloaded (latest version).

Create new AL project using the "AL: Go!" command.
-1613505329479.log

Attempted to format file and received error  message.

Expected behavior
I expected the file to format without any issue and to be able to deploy/connect my app to the sandbox tenant.
Screenshots
If applicable, add screenshots to help explain your problem.
5. Versions:

AL Language: v6.5.413786

Business Central: NA (Never even got to "connect" the extension to the client in any way)

I have attached the log. Far more data than needed, but figured I would include in case there was some conflict with other extensions for some reason. Actual error (above) does not occur until line 590
-1613505329479.log
EDIT: I am using Linux (Debian 10). I did not see anything that indicated Windows was required for AL development, but was this assumption mistaken?

We do not have official support on Linux at this moment.

I will close this issue as it appears to be a Linux specific issue. Please reopen it if you can reproduce it on Windows.


add continent function to location module

Hello, I'd like to work on this issue.

i want to work on this

Ok assigned

just wanted to confirm that i need to change files in location.cpp, location_data.h and test files right

Yes

Hello, please make changes in one PR instead of 4 :) it womt work that way


Added new cluster status to KEB contract

SQL migration was tested on local Backup of Dev environment - Works 👍🏻


URL without SSL is not loading in Windows 10.

It's only supports https not http.

I consider this a feature, not a bug^^

In my machine webview works fine with HTTP. May be this issue is fixed.

Test URL: http://neverssl.com/


Add an option to extract the bodies of the external definitions

For now, whenever possible we treat foreign definitions as opaque, that is we treat all external functions as opaque and thus don't look at their bodies, treat external structures without public fields as opaque, etc. It is sometimes useful to extract the bodies of the external definitions, and Eurydice needs this: we need to add a CLI option for this. Also, it might be good to be able to tweak this behavior, for instance by extracting only the bodies of the functions marked as #[inline], etc.

Ok, so foreign functions/methods, structs that have private fields, anything else?

This is harder than expected, because the only MIR we can access for foreign functions is optimized MIR which we don't support well


FFmpeg 6.1 support

This PR adds support for FFmpeg 6.1

Awesome! Could you add a Linux build for 6.1, à la https://github.com/zmwangx/rust-ffmpeg-sys/commit/65e294ad36d805cbe48fa8b7ae74fdcb0d340162#diff-5c3fa597431eda03ac3339ae6bf7f05e1a50d6fc7333679ec38e21b337cb6721R42-R77 ? And then we can call it a merge :muscle:

great :grin:
I think we're just missing changing the version in Cargo.toml from 6.0.0 to 6.1.0, and we're good to go :)

Perfect! I'll merge 🤞


Add merge test

Adds a test to verify that common::Merge works.  Addresses one test box in https://github.com/slide-rs/specs/issues/244

bors r+


Client/freelancer can update profile

Long form:
As a client/freelancer, I want to create my profile and portfolio to display my info.
Story points: 3
Ideal hours: 5
Priority: 4
Risk: Low
Tasks:

[x] #31
[x] #32
[x] #58

can view #92 by @Itek01
For name change:

Changing names displays success for 3 seconds as confirmation

For password change:

Password is not long enough
Password needs Capital, minimal and Special character
Passwords dont match
Wrong old password
Successful password change

How name change looks:

How password changes look


meta: intermittent unexpected disconnect while reading sideband packet when fetching golang.org/x repos since 2022-03-25

            	golang.org/x/sys/cpu<EMAIL_ADDRESS>invalid version: git fetch -f origin refs/heads/*:refs/heads/* refs/tags/*:refs/tags/* in $WORK/gopath/pkg/mod/cache/vcs/da0444fc0003f84a590bd6521553c0531086778bca13ec63ace9e0dd258f4b51: exit status 128:
            	error: 46048 bytes of body are still expected
            	fetch-pack: unexpected disconnect while reading sideband packet
            	fatal: early EOF
            	fatal: index-pack failed

greplogs --dashboard -md -l -e 'unexpected disconnect while reading sideband packet'
2022-04-21T16:18:44-b941a10/linux-amd64-longtest
2022-04-11T16:31:42-910a33a/linux-amd64-longtest
2022-04-11T16:31:40-6130b88/linux-386-longtest
2022-03-25T18:19:09-f25631b/linux-386-longtest
Since I assume we haven't recently changed the git version on the builders, this looks to me like either a networking issue on the builders or a regression in the Git server that hosts go.googlesource.com. @golang/release: could you investigate and/or escalate appropriately?

(Internally this appears to be related to b/190501760.)

greplogs -l -e 'unexpected disconnect while reading sideband packet' --since=2022-04-22
2022-05-04T03:08:40-4f89884/linux-386-longtest
2022-04-28T15:11:42-4d35071/linux-amd64-longtest

greplogs -l -e 'unexpected disconnect while reading sideband packet' --since=2022-05-05
2022-05-09T16:02:28-9ae7dc3/linux-386-longtest

No recurrences so far since the timestamping was added:
greplogs -l -e 'unexpected disconnect while reading sideband packet' --since=2022-05-10
(0 matching logs)


Docker Image: Maps

How to use newer maps when running CARLA in Docker? I am using the latest docker image with CARLA version 0.9.15, but I can not find Town 11, 12, 13 and 15.

When running  print(client.get_available_maps()), I get the following towns:
['/Game/Carla/Maps/Town04_Opt', '/Game/Carla/Maps/Town10HD', '/Game/Carla/Maps/Town04', '/Game/Carla/Maps/Town01', '/Game/Carla/Maps/Town05', '/Game/Carla/Maps/Town10HD_Opt', '/Game/Carla/Maps/Town02_Opt', '/Game/Carla/Maps/Town03', '/Game/Carla/Maps/Town05_Opt', '/Game/Carla/Maps/Town01_Opt', '/Game/Carla/Maps/Town03_Opt', '/Game/Carla/Maps/Town02']

Same issue. It works with CARLA 0.9.14 though.

I used docker image 0.9.15, but I found it only have
['/Game/Carla/Maps/Town01', '/Game/Carla/Maps/Town10HD_Opt', '/Game/Carla/Maps/Town04', '/Game/Carla/Maps/Town05_Opt', '/Game/Carla/Maps/Town04_Opt', '/Game/Carla/Maps/Town02_Opt', '/Game/Carla/Maps/Town05', '/Game/Carla/Maps/Town02', '/Game/Carla/Maps/Town10HD', '/Game/Carla/Maps/Town01_Opt', '/Game/Carla/Maps/Town03_Opt', '/Game/Carla/Maps/Town03']

@DeepDuke @DanielCoelho112 I hope you are able to solve this issue, but if not then you have to include Town 12, 13, 15 in unreal engine before accessing. In unreal engine go to edit -> project setting and search list of maps. Here you have to add map that you wants to use.

I ended up doing the following:

Download the additional maps from github
Create a new dockerfile based off carla: copy the maps there and run the Import script.

FROM carlasim/carla:0.9.15
USER root
RUN apt-get update && apt-get install -y wget
RUN wget https://carla-releases.s3.eu-west-3.amazonaws.com/Linux/AdditionalMaps_0.9.15.tar.gz
RUN mv AdditionalMaps_0.9.15.tar.gz /home/carla/Import
WORKDIR /home/carla/Import
RUN tar -xf AdditionalMaps_0.9.15.tar.gz
WORKDIR /home/carla
RUN ./ImportAssets.sh
RUN rm -f /home/carla/Import/AdditionalMaps_0.9.15.tar.gz
USER carla


You can now cancel in the save prompt

fixes #359

SonarQube analysis reported 36 issues

 3 minor
 33 info

Watch the comments in this conversation to review them.
3 extra issues
Note: The following issues were found on lines that were not modified in the pull request. Because these issues can't be reported as line comments, they are summarized here:

 AncientFungus:LGEPR: Cppcheck cannot find all the include files (use --check-config for details)
 main.cpp#L28: Return value of function freopen() is not used.
 main.cpp#L43: Variable 'vrSystem' is assigned a value that is never used.

SonarQube analysis reported 5 issues

 3 minor
 2 info

Watch the comments in this conversation to review them.
3 extra issues
Note: The following issues were found on lines that were not modified in the pull request. Because these issues can't be reported as line comments, they are summarized here:

 AncientFungus:LGEPR: Cppcheck cannot find all the include files (use --check-config for details)
 main.cpp#L28: Return value of function freopen() is not used.
 main.cpp#L43: Variable 'vrSystem' is assigned a value that is never used.

SonarQube analysis reported 3 issues
Note: The following issues were found on lines that were not modified in the pull request. Because these issues can't be reported as line comments, they are summarized here:

 AncientFungus:LGEPR: Cppcheck cannot find all the include files (use --check-config for details)
 main.cpp#L28: Return value of function freopen() is not used.
 main.cpp#L43: Variable 'vrSystem' is assigned a value that is never used.

SonarQube analysis reported 3 issues
Note: The following issues were found on lines that were not modified in the pull request. Because these issues can't be reported as line comments, they are summarized here:

 AncientFungus:LGEPR: Cppcheck cannot find all the include files (use --check-config for details)
 main.cpp#L28: Return value of function freopen() is not used.
 main.cpp#L43: Variable 'vrSystem' is assigned a value that is never used.


MRG: Fix BEM chdir

Closes #2598.

LGTM
did you test it on a subject?

No, I have never really gotten the test_commands to work with the BEM test. Or at least it hangs for > 20 minutes and I kill it too early.

(I don't really use this code to do BEMs)

Is there an easy way to test it?

merged by rebase after testing and a fix
thx @Eric89GXL


:or entries with spaces are not grouped

I would expect the following filter to include an email with "aaa ccc" in the body.
    filter {
      has [{:or => [
        'aaa', 'bbb -ccc',
      ]}]
      archive_unless_directed
    }

Instead, it generates (aaa OR bbb -ccc) which is different from the expected (aaa OR (bbb -ccc)).

What a tasty bug! Thanks for reporting, I have pushed what I think is a fix (and a regression test) (:


docs: Interactive SizeEffect examples in doc.

Description
Doc examples for SizeEffect.to and SizeEffect.by.
I used the Ember because the Flower gave script errors when trying to size.
Checklist

[x] The title of my PR starts with a Conventional Commit prefix (fix:, feat:, docs: etc).
[x] I have followed the Contributor Guide when preparing my PR.
[ ] I have updated/added tests for ALL new/updated/fixed functionality.
[x] I have updated/added relevant documentation in docs and added dartdoc comments with ///.
[x] I have updated/added relevant examples in examples or docs.

Breaking Change?

[ ] Yes, this PR is a breaking change.
[x] No, this PR is not a breaking change.

Related Issues

Closes #1952

So excited to see Ember used!

Strange that it didn't work with the flower, but looks good except for that!

Flower doesn't work because sizes are specified in the class itself.  This is the same for opacity and was one of the reasons for that whole thing.

Now I know why this worked on Ember, but not on Flower, it's due to SpriteAnimationComponent having the SizeProvider and not PositionComponent. And if you would have run this code in debug mode you'd have got an assert error instead of the weird error that you got.
https://github.com/flame-engine/flame/issues/2087


Metric to report on kthread and pid == 0 perf events

Is your feature request related to a problem? Please describe.
We're still investigating why it appears like we're dropping or not receiving perf events.
Describe the solution you'd like
Add another metric, similar to https://github.com/parca-dev/parca-agent/pull/2460, this time before we start unwinding, and essentially for each "early return".
Describe alternatives you've considered
Nothing else I could think of other than add more observability.
Additional context
n/a

Closed by https://github.com/parca-dev/parca-agent/pull/2486


Create area calculator

Calculator Functions
In this calculator, user can find area of different geometries like circle, square, rectangle etc.
Contribution Event
GSSOC22
Code of Conduct

[X] I follow Contributing Guidelines & Code of conduct of this project.

/assign

Hey can I work upon this?

Assign to me sir i am not under any event but i want to fix it @vasu-1

please assign me this issue under gSSOC 2023


Setting DHW schedule to "always on" doesn't start DHW pump

Running adapter version 2.3.0 in iobroker.
If I set (under viessmannapi.0..0.features.)
... heating.dhw.pumps.circulation.schedule.commands.setSchedule.setValue
to always on (Monday - Sunday 00:00-23:59), the DHW pump doesn't start.
According to the Viessmann documentation the data point should be
heating.circuits.N.dhw.pumps.circulation.schedule
but this data point doesn't exist in the current adapter version.
Can you please check?

you can delete the data points and restart the adapter to see what the api sends. But if datapoints missing please contact viessmann

Thank you for the information. A restart of the adapter didn't change anything in the objects-tree.
I did ask Viessmann developers now:
https://community.viessmann.de/t5/The-Viessmann-API/Documentation-doesn-t-match-API/m-p/442147#M2248


Unable to connect to sql database using System.Data.SqlClient 4.4.3 and hostname but ip works 4.4.2 also works

I'm running a .net core 3.1 app inside a docker container based on mcr.microsoft.com/dotnet/core/sdk:3.1-bionic (Ubuntu 18.04).   but also tried with mcr.microsoft.com/dotnet/core/sdk:3.1-buster.
I'm trying to connect to a database with the following code:
using var connection = new SqlConnection(connectionString);
connection.Open();
If i use If using System.Data.SqlClient 4.4.3 or higher and use a hostname this will fail with the following error:
"Microsoft.Data.SqlClient.SqlException (0x80131904): A network-related or in stance-specific error
occurred while establishing a connection to SQL Server. The server was not found or was not
accessible. Verify that the instance name is correct and that SQL Server is configured to allow
remote connections. (provider: TCP Provider, error: 40 - Could not open a connection to SQL Server)"

if i use an ip adress it works fine.  If i run this outside of a docker container it works fine. My first though was that it was an issue with DNS resolution so i tried Dns.GetHostAddresses("myhostname"); but it is able to resolve the correct IP from it,
so that does not seem to be the issue. If i downgrade to System.Data.SqlClient 4.4.2 my application has no issue connecting to the sql server with hostname. So what change was made in 4.4.3 that could make me have these issues? I can also mention that i tried with Microsoft.Data.SqlClient v2.0.0,  System.Data.SqlClient 4.8.1 and entityFramework with Microsoft.EntityFameworkCore.SqlServer. Same issue. I tried using sqlCmd inside the docker container and it has no problem connecting.
I tried this with two different databases hosted in different places and get it working with one but not the other. I suspect that it is something else than the actual hosting machine that is the issue but posting info anyway for completeness.
l Microsoft SQL Server 2016 (SP2-GDR) (KB4532097) - 13.0.5102.14 (X64)
Dec 31 2019 22:39:35
Copyright (c) Microsoft Corporation
Enterprise Edition (64-bit) on Windows Server 2016 Datacenter 10.0 <X64>
(Build 14393: ) (Hypervisor)

Works with hostname  regardless of SqlCLient version
Microsoft SQL Server 2016 (SP2-GDR) (KB4532097) - 13.0.5102.14 (X64)
        Dec 31 2019 22:39:35
        Copyright (c) Microsoft Corporation
        Standard Edition (64-bit) on Windows Server 2012 R2 Datacenter 6.3 <X64>
 (Build 9600: ) (Hypervisor)

Even if some network configuration on the sever side could be a contributing factor to me having this issue, The one factor that remains is that it works with System.Data.SqlClient 4.4.2 but fails with anything above that version. I would really like to understand what is happening. Here is a minimal project that can reproduce the issue. Very basic, so i don't think it is anything in my code that is directly an issue.
sql-test.zip

Hi @endasil ,
I am confused by your error message. You are saying that your application uses System.Data.SqlClient but your error message gives a Microsoft.Data.SqlClient.SqlException. These are two different libraries. Have you tried with Microsoft.Data.SqlClient v2.0.0 to see whether you still get the connection error or not?
The same container works on Windows but failed on Linux.
-->  this looks strange to me too. Have you tried other docker images instead of this mcr.microsoft.com/dotnet/core/sdk:3.1-bionic ?
And also, it would be helpful if you can provide the repro app.

It seems like i can reproduce this on my windows machine too, if just forgot that i had visual studio configured to run my app in IIS mode and not in a container.  Sorry about the confusing error message, I have tried this with  Microsoft.Data.SqlClient v2.0.0 and System.Data.SqlClient is 4.8.1 as well as using entityFramework with Microsoft.EntityFameworkCore.SqlServer.  If i try to use sqltools from within the container i can establish a connection with that. If i try to use a buster image same error.
The reason for talking more specific about  System.Data.SqlClient is that i had one application running that uses it and is able to connec to that database. I compared the projects to find what was different and found that it was the version of System.Data.SqlClient .  It breaks if i try to use  4.4.3 and  works if i use 4.4.2. Is there a way to find out what happened there that could give a hint at what is different? I tried this on another database hosted in the following environment and it works, but i suspect that it has more to do with the network than the machine and database. Just can't figure out why.
Failing with hostname  and SqlClient > 4.4.2
l Microsoft SQL Server 2016 (SP2-GDR) (KB4532097) - 13.0.5102.14 (X64)
Dec 31 2019 22:39:35
Copyright (c) Microsoft Corporation
Enterprise Edition (64-bit) on Windows Server 2016 Datacenter 10.0 <X64>
(Build 14393: ) (Hypervisor)

Works with hostname  regardless of SqlCLient version
Microsoft SQL Server 2016 (SP2-GDR) (KB4532097) - 13.0.5102.14 (X64)
        Dec 31 2019 22:39:35
        Copyright (c) Microsoft Corporation
        Standard Edition (64-bit) on Windows Server 2012 R2 Datacenter 6.3 <X64>
 (Build 9600: ) (Hypervisor)

The one factor that remains is that it works with System.Data.SqlClient 4.4.2 but fails with anything above. I would really like to understand what happened there.

@endasil
Can you paste full stack trace here?

Please also explain what is the difference in these 2 hosted SQL Server environments you are connecting to that 1 works and other does not. That might give us some clue what's going on.
Please check below things:

Are they both hosted on default SQL Server instance?
You said IP address works, have you tried to connect with "tcp:" appended to hostname or with Port/Instance name specified?
Are both servers in the same active directory as your client?

@endasil
I tested a standalone .NET Core console app with docker support to narrow down the driver issue you have described. The test app simply opens a SqlConnection using server hostname. From my local environment, the connection is always successful when using server hostname with System.Data.SqlClient v4.4.2, v4.4.3, and Microsoft.Data.SqlClient v2.0.0. My server is located in the same domain of my client machine.
I have attached my test app and enabled EventSource tracing so you can test it with your server and collect the tracing information from the console. The tracing could give some hints about what has happened with your server. Please feel free to give it a try.
netcoreMDS.zip

@endasil  We are closing this issue now due to no activities on this. Please feel free to reopen it if you have any updates.


Can't access local file in virtual machine

We want to access the /var/run/docker.sock in kitematic cli. All these files are in virtual machine from virtualbox but how can we access them?

You need to login to the VM. docker-machine ssh kitematic and access via there. Other docker client queries from the host client should just go over tcp with the certs created at installation time.

@leafmulch has almost the proper command - The VM created is actually labelled dev so the proper command is: docker-machine ssh dev

for vanilla docker-machine setups maybe, but I got a kitematic out of the box here:-
PS C:\Users\xxxxx\AppData\Local\Kitematic\app-0.7.3> docker-machine ls
NAME        ACTIVE   DRIVER       STATE     URL                         SWARM
kitematic   *        virtualbox   Running   tcp://<IP_ADDRESS>:2376

@leafmulch Yup in Windows, the VM created is labelled 'kitematic' otherwise it's 'dev'.
I guess we were both right :P
@tobegit3hub - To SSH into the proper machine:
docker-machine ls
Should return Either kitematic or dev
docker-machine ssh <above-name>

There's no like/favourite on your comment, so...
Ah - didn't think that mac would be different! Good to know.

Seems like this issue is ready to be closed :), but feel free to re-open if otherwise.

Yes, it works. Thanks all @leafmulch and @TeckniX :+1:


Score n/a for one of the subtasks when submitting for both subtasks at once.

Hi team,
Here is the link to my competition: https://www.codabench.org/competitions/3734/#/results-tab
When I submit results to both subtasks at once, the results for one of them are shown as n/a (kindly see the attached image) even though it provides valid results in the scores logs. Could you please investigate?
Thanks!

Hi @Aktsvigun,
Thank you for reporting the issue.
Have you tried the subtasks separately? Can you confirm that they work fine?
Related:

#1540

Hi @Didayolo , thank you for your reply!
They do work fine, however there is a caveat: once I submit the scores, say, for the task B, if I previously had some scores on the task A, they turn to be n/a. You can see in the competition that after I submitted my scores for only the subtask A, my results for task B are displayed as n/a

OK I get it now! Thank you for the clarification.

Right now, we consider that it is the intended behavior to have n/a scores when submitting to just one task. This kind of submissions can be useful as participants for testing purpose. To have a full row on the leaderboard, it is required to submit to all tasks. Having independent submissions is discussed as a feature suggestion here: #1334
To clarify this behavior, we need to add a warning here:

[ ] Add "Submit to" before the drop down selector, like the "Submit as" (this is shown only when there are multiple tasks)
[ ] Add a warning when at least one checkbox is unchecked. A red box message explaining that the unselected tasks will get n/a scores.

Dear @Didayolo , I agree with your comment, however, the problem is the n/a scores appear even if I submit to both tasks at once. As a result, currently, I cannot have my scores displayed for both tasks regardless of how I submit my solution: for both tasks at once or separately.

@Aktsvigun Oh OK, I did not get that. I need to test a bit to see if it is a general problem with multitask. Thanks for reporting it.

Hi @Didayolo , could you please tell me whether there are any updates here?

Hi @Aktsvigun, sorry right now I think nobody is working on this bug. I will try to bring it up soon. You can also contribute to it by yourself if you will (see contributing.md).


Storing / Loading Sort Order Examples

Searching for some complete examples how to store and load sort order after drag and drop.
 I have searched/read more then 10 Issues and Examples about but I can't found one 100% complete example how storing and loading of sorted order works. I found 20% here, 60% of an answer there, 30% in another example and nearly 45% in the documentation.
I would be very, very happy to find a complete example on codepen, JSBin, JSFiddle.
1000-thx
Happy Easter

Have you seen the README example? https://github.com/SortableJS/Sortable#store
Can you look at that and tell me what your question is?
Happy Easter to you as well

I am having the same problems. For the life of me, I can't figure out how I can restore the state of the SortableJS to a previously saved version.
My use case for this would be, that on a failed ajax request after sorting, I would like to revert the list to it's original state.


wg_engine: Need radial fill anti-aliased drawing

See FillSpread

see also: https://github.com/thorvg/thorvg/pull/2528

SVG renderers have the same issue in case of repeat spread:

Users will expect similar quality from ThorVG's graphic output capabilities, regardless of the backend rendering functionality. wg engine should be aligned the thorvg spec, not svg renderer.


feature: add repositories rules/rulesets

Prerequisites:
Following Introducing Repository Rules Public Beta, GitHub also introduced a Rules REST API endpoint, but it seems to still be missing from Octokit (please do verify).
New Feature
Settings app to support the repository rules endpoint

initial support has been released in https://github.com/repository-settings/app/releases/tag/v4.1.0. please note that this is considered a pre-release and may have breaking changes applied before it is considered fully released. feedback is welcome if you try it out in the meantime.
since this is not yet fully released, i'm going to keep this issue open and will follow up with more detail about the details i'm still considering further iteration on

@travi Thanks for adding support for this! I have tried this and thus far it is working great for ruleset creations but faced issues when updating it.
I noted that adding a new rule to a ruleset does not update the rule. Initially, I thought that it might be an issue the request schema but the desired changes were able to be applied if I were to change the ruleset name. This meant that the schema is working fine but probably faced issues when updating it.

I also noticed that the strict_required_status_checks_policy value must be defined, which seems to tally with the API docs. I am not sure if this should be solved in code or via documentation, but the example in the documentation does not work for me without making the following change:
rulesets:
  - name: verification must pass
    target: branch
    enforcement: active
    conditions:
      ref_name:
        include:
          - "~DEFAULT_BRANCH"
    rules:
      - type: required_status_checks
        parameters:
+         strict_required_status_checks_policy: false
          required_status_checks:
            - context: test
              integration_id: 123456

thanks for testing it out, @loozhengyuan!

I noted that adding a new rule to a ruleset does not update the rule

i've noticed that i missed some details for the update scenario as well. i think i've identified the primary issue and have a partial solution that i'm working through already, so i think the results will be better once i get that finished up. unfortunately, i can't promise a timeline right now because i'm preparing to travel for work this week and it is questionable how much time i will find before returning home. this is high on my list once i have availability, though.

I also noticed that the strict_required_status_checks_policy value must be defined, which seems to tally with the API docs. I am not sure if this should be solved in code or via documentation, but the example in the documentation does not work for me

i spotted this problem while debugging the update issue. i agree that it being required was missed in the documentation. i havent decided yet how much we should work around these sorts of details in the app, but would accept a PR to update the docs for now if you'd be willing to tackle that detail

@travi Sure, that's fine. I will at least fix the docs so others are aware of this detail; we can figure this out another time. Thanks!

@loozhengyuan i worked through the problems that i had discovered so far, but i wont claim that i've tested all combinations against the real api yet. please let me know if you encounter more scenarios that dont appear to be working as you would expect

@travi Thanks for the fixes, I am able to confirm that the ruleset updates are working fine for me. I will report back if I encounter any other issues, but they are looking great for now. Many thanks!

will follow up with more detail about the details i'm still considering further iteration on

ok, now that we've worked through those initial bugs, i'm finally getting a chance to circle back here and capture the thoughts that are in my mind before considering this the stable implementation.
mainly, i think the shape of the data is a bit awkward for the config file when presenting to human team members to understand and populate. for example, the use of IDs is totally reasonable for the api as it is expected to be populated programmatically by a system that can do lookups and translate to more human understandable representations. normally, we try hard to keep the shape of the config as close to the api representation as possible, but i'm leaning toward that not being appropriate for this particular plugin.
when comparing to the branch-protection plugin, defining a team uses the slug in that case, but that is also what the api expects. the slug is far more human understandable than the actor-id. similarly, repository roles are also represented as actor-ids in the rulesets api, but the word that represents roles, like "admin" could make the config more approachable. same for the name of a github app for things like bypass-actors or github actions for where a status must be reported from for required checks.
if we do go as far as mapping the actor-ids to more human consumable representations, i think that potentially also opens the door to make a few other things more ergonomic.

maybe represent the default branch in a simpler way than ~DEFAULT_BRANCH. i like that there is a special way to specify the default rather than a branch name that could change over time, but that particular representation is an awkward way to present to humans
could the include or exclude lists be optional in the config, even though they are required in the api?
could other properties be considered optional, like maybe defaulting strict_required_status_checks_policy to false when not provided? is it better to keep these as explicit to avoid mistakes (might be a different situation if we provided better feedback for failures within the settings app than we currently do)?

also worth noting: github is considering the bypass_actors property as sensitive information according to https://docs.github.com/en/rest/repos/rules#get-a-repository-ruleset and does not expose them through the api unless called with a token that has write access to the ruleset. defining those details in the config file make them more visible than that. we probably need to at least make that detail very visible in the docs, at the very least


Skybox parallax feels just a little off when you move.

Not sure what's causing this but it feels like it's moving with me as I move. Not sure if this is a regression or we just never noticed it.

🤔 odd, i'll take a look


Enhancement: Store cache files in build directory

This PR

[x] stores cache files in build directory

Thanks!

Thank you, @svpernova09!


Stabilise openshift 4.18 on Ignition 3.4.0 spec

Here’s what this PR aims to achieve:

[x] Stabilise Openshift 4.18
[x] Uses Ignition 3.4 specs
[x] Add specs 4.19.0-experimental
[x] Remove GRUB password support from OCP 4.18

Fixes: https://github.com/coreos/butane/issues/564

1rst commit: Fix the 4.17.0 imports that we missed from a previous PR
2nd commit: All the changes needed to stabilize 4.18.0
3rd commit: Add 4.19.0-exp
4th commit: Rebuild the docs

Commit split that should help review:

1rst commit: Fix the 4.17.0 imports that we missed from a previous PR
2nd commit: All the changes needed to stabilize 4.18.0, dropping down to ignition 3.4.0, fcos 1.5.0, base 0.5
3rd commit: Add 4.19.0-exp, which is copied from 4.18 before the stabilization, and based on latest exp for ignition, fcos & base
4th commit: Rebuild the docs

Thanks for that! I reorganized the commits using this as example and I guess it's easier to review now. Let me know if there is any other changed needed.

Yes, 4.18 will not have GRUB password support in the MCO so we need to remove it there.

Yes, 4.18 will not have GRUB password support in the MCO so we need to remove it there.

Nice, I added one more commit to remove it. I think we are good now, the commit are properly organized.

Failing on:
Error: config/openshift/v4_18/translate.go:307:6: func `translateUserGrubCfg` is unused (unused)
  func translateUserGrubCfg(config *types.Config, ts *translate.TranslationSet) translate.TranslationSet {
       ^

@travier  Thank you!

@travier  sure thing :) thank you both for your efforts on this, looking now


'kubectl exec --tty --stdin' "leaking" proccess inside pod when terminated

Overview
When stopping a local kubectl exec process without explicitly exiting the spawned in-pod process, the latter remains running inside the pod. I am unsure whether the --tty --stdin flags are relevant.
Reproducing
Explicitly, the issue I am seeing is a bash process left over inside the pod after going through a procedure like the following:

Launch a bash shell inside some pod

local$ kubectl exec -ti some-pod -- bash
some-pod# echo $$
<pid>

Kill above kubectl process (e.g. by closing terminal, explicit kill, etc.)

Verify that the above <pid> still remains inside the pod:

local$ kubectl exec -ti some-pod -- bash
some-pod# echo /proc/<pid>/*

Expected Behaviour
I am quite new to k8s overall, so if this is just a naive user error, please forgive the spam. What I expect to happen is for the in-pod bash process to also terminate when kubectl terminates.
This issue is occurring within the large dev team of my organization. Due to developers running kubectl exec under WSL and closing windows instead of properly exiting bash, we are left with pods having hundreds of "trash" processes sticking around. Some of these lingering processes end up tying up resources unexpectedly and causing errors in our application.
Thoughts
Above, the local kubectl process receives SIGTERM or SIGSTOP depending on how it's killed. On a local machine spawning local processes, one would expect the in-pod "child process" to recieve SIGCHLD and terminate (or handle) accordingly.
Setting trap 'echo CHLD >test.log' CHLD within the in-pod bash process above confirms that SIGCHLD fails to propagate. Does this sound correct? Is this intended?

@dims any thoughts on this one from docker/containerd upstream?

@eddiezane if we can recreate using just containerd, we could file a issue in containerd repository

The problem itself is beyond kubectl itself. I'm suggesting to investigate this and open the issue with appropriate container engine. kubectl relies heavily on that behavior for this one.
/close


Remove redundant methods from TestPackageExtensions

The api now defines IsAssemblyPackage, HasSubPackages and Select(). This is a breaking change because the first two are now properties rather than methods.

:tada: This issue has been resolved in version 2.0.0-beta4 :tada:
The release is available on:

GitHub Release
NuGet Package


dev-icon prefix breaks opening files

First, let me say, thank you for fzf-preview.vim. I have been enjoying it greatly!
When I enable dev-icons, it breaks opening files because it tries to open a filename prefixed with the dev-icon which doesn't exist.

In my environment, it works normally even if dev-icons is enabled.
Can you write down the minimum configuration and environment you want to reproduce?
I think it would be even easier to solve the problem if there was a GIF.

Sorry for the unnecessary parts. I hope this helps.

$ nvim -u minimal

$ cat minimal

call plug#begin('~/.vim/plugged')

Plug 'junegunn/fzf.vim'
Plug 'junegunn/fzf', { 'dir': '~/.fzf', 'do': './install --all' }
Plug 'yuki-ycino/fzf-preview.vim'

" Always load the vim-devicons very last
Plug 'ryanoasis/vim-devicons' " also requires 'pacman -S ttf-font-awesome, nerd-font-source-code-pro'

call plug#end()

" Commands used to get the file list from project
let g:fzf_preview_filelist_command = 'fd --type f --exclude vendor' " Installed fd

" Commands used to get the file list from current directory
let g:fzf_preview_directory_files_command = 'rg --files --hidden --follow --no-messages -g \!"* *"'

" Use vim-devicons
" ***THIS SEEMS TO BREAK OPENING A FILE!***
" Looks nice, though :)
let g:fzf_preview_use_dev_icons = 1
let g:fzf_preview_dev_icon_prefix_length = 2

" Neither of these work
nmap <C-p> :FzfPreviewDirectoryFiles<CR>
nmap <C-f> :FzfPreviewProjectFiles<CR>

I'm wondering if it is the ryanoasis/vim-devicons plugin or the fonts that I have installed.
Kernel: Linux 5.5.8-arch1-1

The icons and preview display fine.

But when I open the file, the filename looks odd
Broken, when opened via FZF preview

Working perfectly when opened via nvim go.mod

I enjoy this plugin! Thank you for your work!

The problem is about setting g:fzf_preview_dev_icon_prefix_length to 2. The default value for the variable is 5. Since the length of dev icon is 3 bytes, changing it makes this part have some buggy behaviors.

Confirmed. Manually setting to 5 worked. Thanks! Closing.


Feature Request: Add Support for Components Custom ID with JavaScript Functions

Description:
Please add support for component custom IDs to accept a regex or a function for validation. This would allow more flexible and dynamic ID checking.
Current Example:
const app = new DiscordHono()
  .component('button-1', c => c.resUpdate('Button clicked'));

Proposed Enhancement:
Allow id to accept regex or function:
// Regex example
id: /fruit_([\w])+/,

// Function example
id: (id) => {
  return id.startsWith('fruit_');
},

Benefits:

Increased flexibility in component ID validation.
Easier handling of dynamic and complex ID patterns.

Thank you!

Hi. Thank you for the request!
I’ve added support for regex (ver. 0.7.1).

Regarding function support, I don’t think we’ll be implementing that for now.
Instead, try the following code:
const app = new DiscordHono()
  .component('', c => c.resUpdate(c.key));

Although it’s not documented, specifying '' will act as a fallback if there’s no match.
Additionally, I’ve added c.key (ver. 0.7.1).
c.key contains the command name, component ID, or modal ID.