Add Coding project directories as source for TODO items

Programmers will often leave TODO comments scattered throughout their code when they have a coding project. Ideally you have one source of truth and don't duplicate TODO items in both your code and a separate todo.txt file. Using sleek as a UI frontend for managing TODO comments in coding projects would be a really handy feature.
Describing some parameters for an implementations:

Coding projects can consist of multiple files grouped together in a shared parent directory with optional subdirectories. Therefore, functionality should be added to add a directory as the source of multiple TODO files, similarly to how multiple TODO files have been made possible by #9 . Sleek would then recursively descend into this directory and look for all relevant files.

Coding projects can hold files that are not directly relevant to the developer and these should be ignored (even if they contain todos). Such files are commonly specified in a .gitignore file. Therefore files and directories specified in .gitignore should be ignored.

Comment styles vary by programming language with most languages using either:
hash style # TODO: Example Comment
or:
slash style // TODO: Example Comment /* TODO: Example Comment */
but other styles exist such as well.
Therefore, various commenting styles should be expected based on the extension of the file in question, or possibly a universal regular expression could be used to recognize comments in any language. Only comments that start with TODO: should be imported into the sleek UI, other comments should be ignored.

Ideally, TODO comments should not only be read into Sleek, but also be updatable from Sleek's UI, so Sleek should keep track of the filename, line number, and original string in order to securely patch the source code/script files when making changes to the todo item from the Sleek UI.
If TODO comments are updated from sleek and there were no changes in the source file, then the original string can be replaced by the updated string with a simple find and replace in the original source code/script file assuming there are no duplicate/identical TODO's in different places in the same file, otherwise a specific line can be altered.
If TODO comments are updated in the source file outside of sleek, or comments move places because the surrounding lines are edited in a text editor or IDE, then simply scanning the file again will suffice to have an up to date record of each item. A refresh button for directories added to sleek for monitoring (as mentioned in point 1) is also neccessary, or sleek could keep track of the filenames and hashes and automatically poll for changes every so often. (the automatic solution is preferable)

Handcrafted TODO comments in source files don't typically follow the full spec of todo.txt, but it should just be possible to take the entire string and prepend / append  the relevant sections (priority, creation date, start date, due date, project, context) upon first discovery and then update the source file with the well formed TODO.

TODO comments found in projects directories added in this way should all automatically have the name of the project root directory added as a project (e.g. +mobile-app, if you added a directory mobile-app with source files) if that is not already in the TODO string.

The most high performance / fastest and most feature complete way to quickly recursively search text files in directories while respecting .gitignore files that I know of is ripgrep, a rust command line utility. Perhaps this could be used in the backend and its output used to get the necessary information from the source files in question.
What do you all think?

That would be a win for me as I do leave exactly this kind of comment in my code ;) If it is a feature that would benefit many or attract new users, would be another question. Opinions on this suggestion are most welcome, I will at least think about it.

While the idea is useful, I have to say it seems significantly outside the scope of the todo.txt format and philosophy.
I feel bad raining on your parade, but I wouldn't want the purpose of the app to be diluted. 😕 We don't have that many good todo.txt apps and I wouldn't want the development of Sleek to be sidetracked/bogged down.
However, if @ransome1 thinks it must be done, then maybe in a more general-purpose fork/sibling of Sleek?

In the mean time, there is a very good VS Code extension (which uses ripgrep btw!) that is built around this idea is Todo Tree (GitHub repo).

Thank you for your feedback.

While the idea is useful, I have to say it seems significantly outside the scope of the todo.txt format and philosophy.

I see it exactly the opposite way: this is not a violation of the todo.txt philosophy but its proper application. The todo.txt format works so well for use in source code because source code is plain text, and the reason the TODO comments have to reside in your code and not in a separate file is because they benefit from the context of the surrounding code.
It is precisely this versatility of use cases and seamless integration across applications that the plain text format allows for and excels in that is at the core of the todo.txt philosophy.
While keeping todo's in your source code files is beneficial when you are already working on the code in your text editor / IDE, there is also a good reason why you would want to have your scattered TODO comments aggregated. When it comes to planning your work, your side projects, your whatever else you do, you benefit from having a single source of truth. One window that can give you an overview of every task you've committed to writing, regardless of where it is in your filesystem,  because the relevant context for that decision making process is not your code, but your other tasks /  the rest of your life.

I feel bad raining on your parade

No need to :)  it's precisely this type of constructive criticism that allows projects to make the best decisions for their intended use.

I wouldn't want the purpose of the app to be diluted / confused

Just like people who use a single todo.txt file are not bothered by the addition of the feature to add multiple todo.txt files (resulting from issue #9 ). People wouldn't be bothered by the addition of a feature to add a directory with files out of which todo items are filtered. If you don't use it, it never gets in your way. We're just adding one more way to add plain text files that contain todo's in the todo.txt format.

I wouldn't want the development of Sleek as a todo.txt app to be sidetracked/bogged down.

Initially some resources would have to be invested here, but i don't think the maintenance burden will be high because most of the heavy lifting can be done by the very performant and well maintained ripgrep. The glueing of functionality is a one time effort after which it should just keep working. You may even be the right person to help out with this given your experience building Todo Tree, if you so please.

However, if @ransome1 thinks it must be done, then maybe in a more general-purpose fork/sibling of Sleek?

I think forks and fragmentation are potentially a bad thing for both developers and the community unless the original project is user hostile, in which case forking is a good thing for the community.
The developer(s) of a project benefit form a larger (unified) community because it means more testing / bug reporting gets done by users and the small percentage of people who take the time to report bugs translates to higher absolute numbers of people. Also more funding / donations go to the original developers if they manage to keep their community together. Also the even lower percentage of people  who take the time to contribute code to the project and may potentially become core devs translates into higher absolute numbers if the community is not fragmented.

In the mean time, a very good VS Code extension (which uses ripgrep btw!) that is built around this idea is Todo Tree (GitHub repo).

I'm a happy user. Never thought I'd run into you in the wild, but thank you for making a great extension! As a matter of fact, I'd continue to use your extension even if sleek adds the feature i suggest, because Sleek and Todo Tree fulfil different needs for me. While Todo Tree works great when I'm navigating and working inside one project, it doesn't give me an overview of all of my projects, let alone of non programming tasks I may want to include in my decision making when I'm planning what to do.

Hopefully if @ransome1 gives the OK then we can discuss implementation details, cuz I do want to keep it as simple as possible. I'm definitely not suggesting including a database or anything. Plain text files remain the ground truth. There's just some internal runtime state to keep track of the origins of individual tasks which is not persistent across sessions, similarly to how you already need to keep track of task origins with multiple todo.txt files.

That would be a win for me as I do leave exactly this kind of comment in my code ;) If it is a feature that would benefit many or attract new users, would be another question. Opinions on this suggestion are most welcome, I will at least think about it.

Thank you for your consideration! I've never done any electron development, or I would make a pull request. The most I can do in the short term is help with ideas and I do invest significant time thinking about this.
As the owner of the project, the ability to use this feature personally and any ensuing productivity gains seem like a good enough reason for implementing this feature if there are no overriding concerns. but of course it's important to properly consider it first.

I tend to agree with @9z0 that this would be a bit outside the scope of sleek itself.  Having sleek scan a potentially large body of code with ripgrep on startup would delay startup and would still not guarantee that the list stays up to date.
Instead, why not implement a simple command line tool to scan a set of project directories and extract the TODO comments into a new todo.txt format file?  Then if sleek is extended to read multiple todo.txt files, you could have one such file for your TODO comment items, while keeping other todo items in a separate file.  If you work on linux, it would be simple to use a cron task to update the generated file automatically on whatever schedule you prefer.  This seems like a great way to reduce the complexity of sleek and still have the todo list generated from the code.  Writing such a tool in python or even in bash should be fairly easy.

this is not a violation of the todo.txt philosophy but its proper application. The todo.txt format works so well for use in source code...

I meant the philosophy of a simple text file just for todos, not the syntax itself. It was created precisely for the simplicity. I agree that the syntax could be used in other approaches like yours.
I also understand the need for a // TODO within their own context. I am just saying that monitoring a directory tree of files and scanning for certain lines to include based on certain matching keywords is NOT the todo.txt approach, even if such use deserves an GUI app.

No need to :) it's precisely this type of constructive criticism that allows projects to make the best decisions for their intended use.

👍

If you don't use it, it never gets in your way.

I agree with you, but see my next points.

Initially some resources would have to be invested here, but i don't think the maintenance burden will be high

forks and fragmentation

Theoretically, yes. And I do like apps with features (and have asked @ransome1 for features). The problem (as I have seen myself in many projects) is that:

if  a single app/function A takes 1x time/effort to cover need/approach X, and
a single app/function B takes 1x time/effort to cover need/approach Y,
a single app/function C to cover both X and Y takes a LOT more than 2x.

Which is why I suggested a separate fork (by @ransome1 himself, if he decided to do it. I didn't mean another developer).

given your experience building Todo Tree, if you so please.

That is definitely not me!

@zerodat said:

Having sleek scan a potentially large body of code with ripgrep on startup would delay startup and would still not guarantee that the list stays up to date.

Scanning the directory can be done asynchronously and ripgrep is very performant, it's the fastest tool around for this task. Ripgrep will run in a separate process (or multiple processes for multiple folders) while regular todo.txt files are being parsed and loaded and the UI is being drawn, and in all but the most extreme cases it will have returned its output in a timely manner, which then becomes the equivalent to a regular todo.txt file except with a slightly different parsing stage (cuz of filenames and line numbers in the output).
And even if we had to wait in those extreme cases, it's up to the user to decide if they think having all of their tasks in one well designed UI is worth the additional loading time. Only people that opt in to scan project directories and have extreme volumes of code would have noticeable additional loading time and it may be worth it for them (bear in mind, node_modules and such would be skipped by ripgrep because of .gitignore). But the users with extreme volumes of code would notice delays in any tool they use and will simply have to accept that fact.
The list staying up to date is ensured by  (1) Sleek writing back changes to the source files (filename and line number are provided by ripgrep) and (2) loading source files afresh on each start up of Sleek (+ maybe a refresh button in the UI?). The design parameters I proposed initially can be simplified if we operate under the assumption that files won't be edited simultaneously in Sleek and a different editor (which is probably the same assumption that Sleek already makes when it comes to regular todo.txt files).

Instead, why not implement a simple command line tool to scan a set of project directories and extract the TODO comments into a new todo.txt format file? Then if sleek is extended to read multiple todo.txt files, you could have one such file for your TODO comment items, while keeping other todo items in a separate file. If you work on linux, it would be simple to use a cron task to update the generated file automatically on whatever schedule you prefer. This seems like a great way to reduce the complexity of sleek and still have the todo list generated from the code. Writing such a tool in python or even in bash should be fairly easy.

Thank you for the suggestion. I've thought of that approach, but I found it impractical for the following reason:
If the feature is added, then Sleek would write its changes directly to the relevant source code files, rather than an intermediate file, thus simplifying the process by syncing directly between source file and internal state. In its internal state, Sleek would know and keep track of:

source file path
line number (optional)
original task string
updated task string

That means Sleek could easily:

find the original task string in the corresponding source file
and replace it with the updated task string

If you create an intermediate todo.txt file using a cron job, then Sleek would write an updated task to the intermediate file instead of the source code file the task originated from. Now, in order to persist the changes you made in Sleek you need to prevent the changes from being overwritten by the next run of the cron job. In order to do that, you need to write those changes back to the original source files. So, now you need to figure out what source file path the changed task string belongs to and what the original task string was before it was overwritten by Sleek, but without having a place to store this information safely and without the knowing cooperation of Sleek when it's writing to the intermediate todo.txt file. Good luck :disappointed_relieved:
Such a solution is error prone and overly complex, to the point of being unworkable. Furthermore, such a solution would be inherently brittle, because it will depend on reading/writing behaviour that may change across versions of Sleek, potentially resulting in lost data after updates.
Lastly, such a DIY solution would not benefit the other users of Sleek who might use and benefit from the functionality I proposed if it were implemented, but who may not even have realized that this is a feature they want, because they simply haven't thought of it.

That is definitely not me!

Ooops ! instead of "a very good VS Code extension (which uses ripgrep btw!) that is built" i read "a very good VS Code extension (which uses ripgrep btw!) that i built"

I meant the philosophy of a simple text file just for todos, not the syntax itself. It was created precisely for the simplicity. I agree that the syntax could be used in other approaches like yours.
I also understand the need for a // TODO within their own context. I am just saying that monitoring a directory tree of files and scanning for certain lines to include based on certain matching keywords is NOT the todo.txt approach, even if such use deserves a GUI app.

Fair enough. I see decisions of where to store your tasks (e.g. in how many files, whether to include extra contextual information in a file which is not itself a task) as secondary to whether it is plain text and the syntax is followed. If someone wants to have one todo.txt file for work in which he includes a section of email addresses that aren't themselves a task, but are important context to certain tasks (e.g. sending quotes), and wants to have another todo.txt file for private matters in which he includes a list of films to watch that are not themselves a task, but are context to certain tasks (e.g. planning a party), then I think they are in line with the philosophy. Source code is similar to me, just the ratio of context / task is higher. The aggregation and filtering is then simply one way of choosing to work with the todo.txt format.

Theoretically, yes. [but the sum difficulty of maintaining orthogonal features can be greater than the difficulty of its parts]

It can be depending on how much tension exists between the separate features. In my mind adding the feature I requested could be as simple as only adding a conditional preprocessing step. I'll explain one potential approach:

Run ripgrep on the project folder designated by the user if the source is a folder, not a file.
Use the output of ripgrep as a virtual filesystem out of which Sleek draws the filenames and associated tasks.

ripgrep output looks as follows:
filename1
matching line 1
matching line 2

filename2
matching line 1
matching line 2

[etc.]

Split it on double newline to get filename + tasks groupings.
filename1
matching line 1
matching line 2

Split that one newline and separate the first line from the remaining lines to get filename + tasks

Then proceed like normal, as if you have read the file from a regular todo.txt file and write any changes to the corresponding original file using a find + replace.

If Sleek is implemented much differently from how I imagine, then it could get as complicated as having an entirely separate parallel pipeline without any overlap with the existing pipeline. I guess @ransome1 will be the best judge of how complicated this will get in practice.

Which is why I suggested a separate fork (by @ransome1 himself, if he decided to do it. I didn't mean another developer).

Thanks for clarifying. That's certainly an option to weigh.

Well, @JordyScript , I guess this is a matter of personal taste.  I have large bodies of code that I wouldn't want to scan on startup of an interactive tool.  Also, I don't think I would really want sleek to make changes to source files.  It seems to me that the editor (say, VSCode) is a better tool for finding and updating those TODO comments in the code, and marking them as done once you are finished.  You are likely editing that code anyway to implement the TODO.
So (again, a matter of personal taste), I would use those TODOs in sleek as only a way of keeping track of my outstanding development commitments and deciding what to work on next, not as a code-aware tool in its own right.  Can you give us some examples of the type of changes that you would make to those TODO tasks from within sleek if you had your proposed feature?

Can you give us some examples of the type of changes that you would make to those TODO tasks from within sleek if you had your proposed feature?

Basically, the usage I envision is the planning phase of the tasks and the changes that you would make to the metadata associated with tasks in that process.  So that would include changes to priority, due date, adding/removing contexts and projects, for example. For changing the actual task description it would usually be done in the text editor / IDE environment because those changes likely depend on the context which is absent in sleek, but it occasionally can be done from sleek (if you can reword something, fix a typo, whatever). Creating new tasks, however, would exclusively happen inside of the IDE/text editor environment.
During the planning stage you don't necessarily have your text editor/IDE open yet because you've not actually gotten to the point of executing your tasks, but are deciding what to do and when to do it. (and even if you did have your IDE open, then you still wouldn't be able to see all of your tasks across projects like the proposed Sleek feature would allow for)

Okay, I've had a look through the source code and played with the app some more.
My understanding of how Sleek handles multiple todo.txt files was wrong. You can only view one file at a time, whereas I was hoping you would be able to view your todo's form all files at once.
My understanding of how it reads and writes files was also wrong. File reading is done by a filesystem watcher that reloads the UI with a fresh read from the file upon change. File writing is a complete overwrite of the old file with all tasks when a single task is changed.
So in order to implement my proposed functionality, it would be closer to the worst case scenario than the best case scenario that I mentioned in my previous comment. Which is to say, an entirely separate pipeline would be added that shares little in common with how things are currently done. Or, the app logic itself would need to be redesigned in order to have a more generic solution to the problem of reading/writing todo's that works for single file, multi-file, and project directory with source code. This would then also make it possible to view the contents of multiple todo.txt files at once.
If you wish to keep Sleek as simple as possible, then I  fully respect that decision. I do think the complexity would increase if we did choose to implement the functionality I proposed.
Ripgrep and Sed are enough to get the job done in terms of finding all todo's in a source tree and patching only the specific comments that were changed.
A hash on the output of ripgrep, triggered by a filesystem watcher monitoring the directory, could be used to check if any relevant comments changed and refresh the UI with the updated comments.
filename + line number  + original comment could be used to patch only the comment that was changed using sed.
ripgrep and sed (in some cases) would need to be bundled with the software for this to work, but this should be possible on all platforms.
I've written the necessary cli commands for this to work, but the question is now: does @ransome1 want this. The app's logic would have to be rewritten, but if @ransom1 wants this, I can discuss the necessary changes / the new logic.

I have to admit having misunderstood your initial proposal and only realized it after zerodat mentioned a possible workaround. Initially I thought  this workaround was what you were looking for: A periodically read of a code base and transfer to a separate todo.txt file managed by sleek.
As you saw yourself, sleek is a simple application that only watches one file at a time. This eliminates lots of complexity, is surprisingly performant and works quite well in general.
Although the implementation of your idea doesn’t sound like rocket science, it would still be a major feature. sleek would be watching a huge code directory, needs to be married with ripgrep or similar, needs to be significantly rewritten to be able to handle multiple file watchers, needs various adjustments to the GUI and would need to replace single lines in many sensitive files. In particular the last point is the one I am uncomfortable with.
Beside significant amount of development hours, I am not sure if it would actually be the best solution to approach the problem. As mentioned by 9z0 there seem to be extensions that do this tasks directly within the developers environment. As for Atom, which I use, I stumbled upon a module which does collect all lines starting with „//TODO:“ presents them as actual todos in a nice looking panel. So if there are little extensions in many editors already, I am not fully convinced this would either be a USP for devs or a feature the typical sleek user would want.

Thank you, @ransome1, for your consideration. I've given my best case for the proposed feature, but with your judgment on the matter I'll consider this issue settled then.
After this discussion, however, I'm firmly convinced that an app that implements this feature can be built much more easily than I anticipated. I have to credit you and your project for inspiring me to develop this idea. And thanks to @9z0 and @zerodat for the critical review as well, without which I possibly would not have looked into this deeply enough to come up with an MVP implementation.
Your project is indeed wonderfully simple, and I intend to build an app that is equally elegant and simple but which is built on a different foundation so that it can do the job I want it to do. I may even take some UI/UX design cues from you, cuz you really did make a beautiful app. I hope you will give it a try when I open source it and give me some feedback, and maybe you can point other users that look for similar functionality to my app, seeing as you won't implement this yourself. (@9z0 and @zerodat , you're also welcome to try and give feedback of course)
Until I've built my app, I'll remain a happy user of Sleek. I'll post a link in this issue when I've open sourced it. If you and the other participants are done discussing this issue, then you can close it for the time being. I should be able to still comment here once I've published the app.

@JordyScript thanks a lot, I appreciate your words and I more than welcome your decision to fork sleek and work on the idea (which I still think is pretty good). If you need feedback let me know, I will support you where ever I can. Maybe this is going to be more simple than we thought and can be married with the GUI neatlessly.

@JordyScript Look into this command line tool: https://github.com/jakewarren/fixme

Thanks for the recommendation! I've been a bit busy lately, so have yet to make a serious attempt at implementing (I've played around a bit to get a feel for it, but nothing worth publishing yet). This tool looks useful though it lacks the interactivity I'm looking for. It's helpful to see how others have gone about implementing similar solutions.


Why is the main branch dependabot/nuget/Sandbox/NUnitUwpTestCases/Microsoft.NETCore.UniversalWindowsPlatform-5.4.2?

It's a bit confusing ;)

Also there are changes in dependabot/nuget/Sandbox/NUnitUwpTestCases/Microsoft.NETCore.UniversalWindowsPlatform-5.4.2 that are not in master and visa versa

I had to change repositories and it must have screwed that part up. I switched the default back to "master". Will look at the commit history.

What changes are not in master? The last commit on the dependabot branch looks like it's very old.

This one, I think it's still valid: https://github.com/RandomEngy/UnitTestBoilerplateGenerator/pull/8


highlight_ignore_patterns is nil

Hello, enjoying the plugin thus far! I'm running into an issue with some of the latest commits, specifically 80b7b356 seems to be the culprit.
Error detected while processing VimEnter Autocommands for "*":
Error executing lua callback: ...site/pack/packer/start/tint.nvim/lua/tint/transforms.lua:14: bad argument #1 to 'ipairs' (table expected, got nil)
stack traceback:
        [C]: in function 'ipairs'
        ...site/pack/packer/start/tint.nvim/lua/tint/transforms.lua:14: in function 'transform_color'
        ...share/nvim/site/pack/packer/start/tint.nvim/lua/tint.lua:109: in function 'set_tint_ns'
        ...share/nvim/site/pack/packer/start/tint.nvim/lua/tint.lua:133: in function 'setup_namespaces'
        ...share/nvim/site/pack/packer/start/tint.nvim/lua/tint.lua:353: in function <...share/nvim/site/pack/packer/start/tint.nvim/lua/tint.lua:348>

When checking it out, it appears that the addition of permitting a skip of setup_user_config results in the user_config lacking transforms leading to a nil value being passed to ipairs causing the error above.
For me, a fix that works currently is to remove the ability to skip that setup_user_config, but it seems that may not be optimal given the functionality was added in the first place.

Will take a look, apologies for the issues.

@treatybreaker what is your current config setup? Mind pasting it here?

First off: thanks for the quick response! No need to apologize, you're providing this plugin for free and of your own time given. I appreciate that you created it. 😄
Secondly, here's my configuration (via packer):
use({
    "levouh/tint.nvim",
    config = function()
        require("tint").setup({
            highlight_ignore_patterns = { "WinSeparator" },
            tint = -30,
            saturation = 0.8,
        })
    end,
})

Ahh I see the issue - the function gets called from an :h autocmd which in Lua will have the first argument as a table of data, hence skip_config always being true.

Should be fixed by #23, let me know if not. Cheers for the report and investigation around what caused the issue.

Hey I appreciate the quick!
I was looking at it and I'd like to bounce this idea off of you instead of the current fix implemented (not that there's anything wrong with #23, but I might have a smaller solution):
In the VimEnter autocmds we can just wrap the func callback up in another function and call it like this:
--- Ensure the passed function runs after `:h VimEnter` has run
---
---@param func function The function to call only after `VimEnter` is done
local function on_or_after_vimenter(func)
  if vim.v.vim_did_enter == 1 then
    func()
  else
    vim.api.nvim_create_autocmd({ "VimEnter" }, {
      callback = function()
        func()
      end,
      once = true,
    })
  end
end

This resolves the issue as well.
I literally just considered that not even 30 seconds before you opened that PR.
Just a thought I had, probably missing some functionality I hadn't considered.

Take a look at this branch if you're interested at all. If not then, no problems.
Again thanks for the quick resolution, plugin is pretty hype.


pkg/adaptor/libvirt: adds support for s390x based libvirt hosts

Fixes #1248
This PR creates a domainXML based on the architecture of the target host.
First it finds the architecture via the GetNodeInfo method. Then if the architecture (aka Model) is s390x we'd create the domain XML with the s390x specifics, else it returns the x86_64 version as before.

@wainersm @esposem, can either of you try the PR using the libvirt e2e to ensure we don't break existing code?

Hi @CarstenLeue !
The e2e libvirt tests did not pass on my Fedora 36 x86_64 workstation. @bpradipt I rebased this PR on main, might some recent change (e.g. flexible types) be the cause of the error below?
The pod of the TestLibvirtCreateSimplePod got stuck on ContainerCreating status due the error pod name io.kubernetes.cri.sandbox-name is missing in annotations: unknown as you can see below:
$ kubectl describe pod/nginx
Name:         nginx
Namespace:    default
Priority:     0
Node:         peer-pods-worker-0/<IP_ADDRESS>
Start Time:   Mon, 07 Aug 2023 14:50:01 -0300
Labels:       <none>
Annotations:  <none>
Status:       Pending
IP:
IPs:          <none>
Containers:
  nginx:
    Container ID:
    Image:          nginx
    Image ID:
    Port:           <none>
    Host Port:      <none>
    State:          Waiting
      Reason:       ContainerCreating
    Ready:          False
    Restart Count:  0
    Environment:    <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-ng7nv (ro)
Conditions:
  Type              Status
  Initialized       True
  Ready             False
  ContainersReady   False
  PodScheduled      True
Volumes:
  kube-api-access-ng7nv:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  3607
    ConfigMapName:           kube-root-ca.crt
    ConfigMapOptional:       <nil>
    DownwardAPI:             true
QoS Class:                   BestEffort
Node-Selectors:              katacontainers.io/kata-runtime=true
Tolerations:                 node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                             node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type     Reason                  Age                    From               Message
  ----     ------                  ----                   ----               -------
  Normal   Scheduled               30m                    default-scheduler  Successfully assigned default/nginx to peer-pods-worker-0
  Warning  FailedCreatePodSandBox  4m53s (x113 over 30m)  kubelet            Failed to create pod sandbox: rpc error: code = Unknown desc = failed to create containerd task: failed to create shim task: remote hypervisor call failed: rpc error: code = Unknown desc = pod name io.kubernetes.cri.sandbox-name is missing in annotations: unknown

The CAA logs don't say much more:
$ kubectl logs cloud-api-adaptor-daemonset-km6hw -n confidential-containers-system
+ exec cloud-api-adaptor libvirt -uri 'qemu+ssh://wmoschet@<IP_ADDRESS>/system?no_verify=1' -data-dir /opt/data-dir -pods-dir /run/peerpod/pods -network-name default -pool-name default -socket /run/peerpod/hypervisor.sock
cloud-api-adaptor version v0.7.0-dev
  commit: 096ca64e5a05a878fa74d95cef051762dc917724
  go: go1.20.7
cloud-api-adaptor: starting Cloud API Adaptor daemon for "libvirt"
2023/08/07 17:45:57 [adaptor/cloud/libvirt] libvirt config: &libvirt.Config{URI:"qemu+ssh://wmoschet@<IP_ADDRESS>/system?no_verify=1", PoolName:"default", NetworkName:"default", DataDir:"/opt/data-dir", VolName:"podvm-base.qcow2"}
2023/08/07 17:45:58 [adaptor/cloud/libvirt] Created libvirt connection
2023/08/07 17:45:58 [adaptor] server config: &adaptor.ServerConfig{TLSConfig:(*tlsutil.TLSConfig)(0xc00032a280), SocketPath:"/run/peerpod/hypervisor.sock", CriSocketPath:"", PauseImage:"", PodsDir:"/run/peerpod/pods", ForwarderPort:"15150", ProxyTimeout:300000000000}
2023/08/07 17:45:58 [util/k8sops] initialized PeerPodService
2023/08/07 17:45:58 [adaptor] server started
2023/08/07 17:50:01 [adaptor/cloud] pod name io.kubernetes.cri.sandbox-name is missing in annotations
2023/08/07 17:50:15 [adaptor/cloud] pod name io.kubernetes.cri.sandbox-name is missing in annotations
2023/08/07 17:50:28 [adaptor/cloud] pod name io.kubernetes.cri.sandbox-name is missing in annotations
2023/08/07 17:50:43 [adaptor/cloud] pod name io.kubernetes.cri.sandbox-name is missing in annotations
2023/08/07 17:50:56 [adaptor/cloud] pod name io.kubernetes.cri.sandbox-name is missing in annotations

<OUTPUT OMITTED - too many messages equal to above>

I also noticed that the podvm VM was not created on Libvirt (supposedly a domain with name started with "podvm-"):
$ sudo virsh list
 Id   Name                   State
--------------------------------------
 2    ubuntu2204             running
 3    peer-pods-ctlplane-0   running
 4    peer-pods-worker-0     running

Finally this is how I tested this PR:

Built a new image:

$ make image registry=quay.io/wainersm

Changed the overlay file to use the built image:

$ git diff
diff --git a/install/overlays/libvirt/kustomization.yaml b/install/overlays/libvirt/kustomization.yaml
index 560697c..e062187 100644
--- a/install/overlays/libvirt/kustomization.yaml
+++ b/install/overlays/libvirt/kustomization.yaml
@@ -6,8 +6,8 @@ bases:

 images:
 - name: cloud-api-adaptor
-  newName: quay.io/confidential-containers/cloud-api-adaptor # change image if needed
-  newTag: latest
+  newName: quay.io/wainersm/cloud-api-adaptor # change image if needed
+  newTag: dev-096ca64e5a05a878fa74d95cef051762dc917724

 generatorOptions:
   disableNameSuffixHash: true

Downloaded the latest CentOS podvm qcow2:

$ cd podvm
$ ./hack/download-image.sh quay.io/confidential-containers/podvm-generic-centos-amd64:latest . -o podvm-generic-centos-amd64.qcow2

Ran the e2e test suite

$ cat test/e2e/libvirt.properties
libvirt_uri="qemu+ssh://wmoschet@<IP_ADDRESS>/system?no_verify=1"
libvirt_ssh_key_file="id_rsa"
#libvirt_vol_name="new-vol"
#cluster_name="peer-pods-e2e"
$ make test-e2e CLOUD_PROVIDER=libvirt TEST_PROVISION=yes TEST_TEARDOWN=no TEST_PODVM_IMAGE=$PWD/podvm/podvm-generic-centos-amd64.qcow2 TEST_E2E_TIMEOUT=40m TEST_PROVISION_FILE=$PWD/test/e2e/libvirt.properties

@wainersm looks like some issues with kata-containers. Flexible instance types is only for AWS/Azure/IBMcloud

pod name io.kubernetes.cri.sandbox-name is missing in annotations

Hi @wainersm The error message comes from here https://github.com/confidential-containers/cloud-api-adaptor/blob/main/pkg/adaptor/cloud/cloud.go#L161
So it is looking like the pod does not carry the required annotation, so the adaptor cannot determine the sandbox ID.
What component is responsible for attaching the io.kubernetes.cri.sandbox-name annotation to a pod?

pod name io.kubernetes.cri.sandbox-name is missing in annotations

Hi @wainersm The error message comes from here https://github.com/confidential-containers/cloud-api-adaptor/blob/main/pkg/adaptor/cloud/cloud.go#L161
So it is looking like the pod does not carry the required annotation, so the adaptor cannot determine the sandbox ID.
What component is responsible for attaching the io.kubernetes.cri.sandbox-name annotation to a pod?

@bpradipt can correct if I am wrong, but it should be the Kata runtime. Peer pods, in particular, leverages the remote hypervisor implementation at CCv0 branch (https://github.com/kata-containers/kata-containers/blob/CCv0/src/runtime/virtcontainers/remote.go). The sandbox name annotation seems attached at https://github.com/kata-containers/kata-containers/blob/CCv0/src/runtime/virtcontainers/remote.go#L77
I checked that my installation used the latest build kata-runtime CI:
Containers:
  cc-runtime-install-pod:
    Container ID:  containerd://8a248f64fefb6c279a136088f1f835e47f6f946ebc5d648ed2f5ccf3568ff076
    Image:         quay.io/confidential-containers/runtime-payload-ci:kata-containers-latest
    Image ID:      quay.io/confidential-containers/runtime-payload-ci@sha256:e8359e2024a2d2369dae4f7903597c0f10cb9f8ffbe7753c08bf8f517be5cbc0

@wainersm https://github.com/kata-containers/kata-containers/pull/7589

@wainersm kata-containers/kata-containers#7589 and #1313

Thanks @bpradipt ! The fix is approved but wait CI to pass.

The fix is merged and a new payload (https://quay.io/repository/confidential-containers/runtime-payload-ci?tab=tags&tag=latest) is built. Let me re-run the e2e libvirt tests

@CarstenLeue thanks for addressing my comments! I re-ran the tests, all passed!


pillar: Add support to CDI for native containers

The Container Device Interface (CDI) is already available on containerd and that are CDI files provided for NVIDIA platform that describes GPU devices for native container access. This commit introduces the support for CDI on pillar, so Video I/O adapters can pass a CDI device name to enable the direct access on native containers.
The corresponding documentation is also provided.

containerd's config file (https://github.com/lf-edge/eve/blob/master/pkg/dom0-ztools/rootfs/etc/containerd/config.toml)

Isn't that system containerd, and we want this for user containerd? Although I spent time with @christoph-zededa earlier today that showed that user apps are running on system containerd? I lost track. 🤷♂

By using /etc/cdi I can push any CDI file direct to this directory without the needs to change /etc/containerd/config.toml which is part of pkg/dom0-ztools

So what would be the process for a specific vendor? Root filesystem is immutable, so /etc/cdi (which is mounted into the pillar container) should be immutable. How do I get my CDI files in there? Or is the assumption that they are part of the rootfs build? How would that work?
We do have the pillar /opt/vendor/*/init.sh process, where we could just link /etc/cdi -> /opt/vendor/<foo>/cdi/? I am not sure that is better, though. I always have a concern with modifying things on the root filesystem and mounting it in.

In my tests, configuring another directory other than /etc/cdi in the config.toml didn't work

Different containerd? 🤷♂

containerd's config file (https://github.com/lf-edge/eve/blob/master/pkg/dom0-ztools/rootfs/etc/containerd/config.toml)

Isn't that system containerd, and we want this for user containerd? Although I spent time with @christoph-zededa earlier today that showed that user apps are running on system containerd? I lost track. 🤷♂

No, user containerd is used only for CAS, user apps run on system's containerd....

By using /etc/cdi I can push any CDI file direct to this directory without the needs to change /etc/containerd/config.toml which is part of pkg/dom0-ztools

So what would be the process for a specific vendor? Root filesystem is immutable, so /etc/cdi (which is mounted into the pillar container) should be immutable. How do I get my CDI files in there? Or is the assumption that they are part of the rootfs build? How would that work?
We do have the pillar /opt/vendor/*/init.sh process, where we could just link /etc/cdi -> /opt/vendor/<foo>/cdi/? I am not sure that is better, though. I always have a concern with modifying things on the root filesystem and mounting it in.

Me too, I have a security concern about allow runtime CDI files, so the assumption is that any CDI file must be part of rootfs build, which, IMO makes sense since they are usually very hardware specific and will be provided by specific packages, such as the pkg/nvidia....

In my tests, configuring another directory other than /etc/cdi in the config.toml didn't work

Different containerd? 🤷♂

Unfortunately not, the containerd config is correct, it's the system's containerd....

No, user containerd is used only for CAS, user apps run on system's containerd

Yeah, that came up yesterday. We probably should change that, but well beyond the scope of this PR.

Me too, I have a security concern about allow runtime CDI files, so the assumption is that any CDI file must be part of rootfs build, which, IMO makes sense since they are usually very hardware specific and will be provided by specific packages, such as the pkg/nvidia....

What happens if you have 100 different devices, all of the same family, with slightly different CDI? Are you going to have 100 different rootfs builds? Or just one, with multiple CDIs, and the ability to detect each? This gets us very much down the road of different builds because of a single few KB config file in /etc/.

Unfortunately not, the containerd config is correct, it's the system's containerd

So, we mount /etc/cdi into pillar, just so that we can retrieve the devices and modify the container spec, but in the end that gets passed to system containerd anyways, which runs (by definition) outside of pillar?
I didn't quite get what we are doing with that chunk of code inside pillar. We inject the devices into the container spec based on the name. Essentially, we are duplicating what containerd normally does?

What happens if you have 100 different devices, all of the same family, with slightly different CDI? Are you going to have 100 different rootfs builds? Or just one, with multiple CDIs, and the ability to detect each? This gets us very much down the road of different builds because of a single few KB config file in /etc/.

It's totally fine to have multiple CDI files under /etc/cdi, we don't need a single build per device. Actually, that's how it's working for NVIDIA, we have CDI files for both Xavier + Orin boards on the same build. Inside each file, we use different names for device description, so we have "nvidia.com/xavier-gpu" for Xavier and "nvidia.com/orin-gpu" for Orin...

Unfortunately not, the containerd config is correct, it's the system's containerd

So, we mount /etc/cdi into pillar, just so that we can retrieve the devices and modify the container spec, but in the end that gets passed to system containerd anyways, which runs (by definition) outside of pillar?

Yes, this can be improved when we move execution of Edge Apps to user containerd...

I didn't quite get what we are doing with that chunk of code inside pillar. We inject the devices into the container spec based on the name. Essentially, we are duplicating what containerd normally does?

No, this parses the I/O adapters list from the device model. The way we give direct access to GPU is exactly the same way as we use for passthrough PCI devices, the difference is that instead of giving a PCIe Bus Address in the device model, we pass the CDI string for the particular device. The CDI is only used for GPU access for now, for Serial devices and any other device (like a webcam under /dev/video0) we read them from the device model and add them to the OCI spec. For standard containers (with ShimVM) we just give full access to all file devices. In the documentation being added you can see some examples and a better description: https://github.com/lf-edge/eve/pull/4265/files#diff-8230cff5878b3df207474c79828836840673a5ac49fdc808ba034809902cac96

It's totally fine to have multiple CDI files under /etc/cdi, we don't need a single build per device. Actually, that's how it's working for NVIDIA, we have CDI files for both Xavier + Orin boards on the same build. Inside each file, we use different names for device description, so we have "nvidia.com/xavier-gpu" for Xavier and "nvidia.com/orin-gpu" for Orin...

OK, that works, thanks.

No, this parses the I/O adapters list from the device model. The way we give direct access to GPU is exactly the same way as we use for passthrough PCI devices, the difference is that instead of giving a PCIe Bus Address in the device model, we pass the CDI string for the particular device. The CDI is only used for GPU access for now, for Serial devices and any other device (like a webcam under /dev/video0) we read them from the device model and add them to the OCI spec. For standard containers (with ShimVM) we just give full access to all file devices. In the documentation being added you can see some examples and a better descriptio

So this is about translating between what came in the EVE API request for devices to pass to the app, and the CDI file format, so that it will know what to do with it? That would make sense to me, but the doc to which you linked implies that the spec comes with the CDI attribute? So why translate?

So this is about translating between what came in the EVE API request for devices to pass to the app, and the CDI file format, so that it will know what to do with it? That would make sense to me, but the doc to which you linked implies that the spec comes with the CDI attribute? So why translate?

I don't know if I understood your question, but the main idea is that the CDI string works as a "hardware ID", the same way we specify PCIe Bus Address, network interface names (eth0, wlan0), etc, in the hardware device model, for this particular case we specify the CDI string which points to the device described in the CDI file.... this makes the "native container GPU passthrough" work transparently with the controller, so the user can "pass-through" a GPU for a native container in the same way it pass-through a PCI Video card on x86, for example....

Actually, that's how it's working for NVIDIA, we have CDI files for both Xavier + Orin boards on the same build. Inside each file, we use different names for device description, so we have "nvidia.com/xavier-gpu" for Xavier and "nvidia.com/orin-gpu" for Orin..

I was just thinking about this. How do you distinguish between them? Aren't the device names similar? Won't you have conflicts?

I don't know if I understood your question, but the main idea is that the CDI string works as a "hardware ID", the same way we specify PCIe Bus Address, network interface names (eth0, wlan0), etc, in the hardware device model, for this particular case we specify the CDI string which points to the device described in the CDI file.... this makes the "native container GPU passthrough" work transparently with the controller, so the user can "pass-through" a GPU for a native container in the same way it pass-through a PCI Video card on x86, for example

What I meant was, if we already define the CDI string inside the app instance, e.g. nvidia.com/gpus=0, then that is how containerd will take it and build the right config.json OCI spec for it, so why does pillar need to have access to it? What is that chunk of code doing?

Actually, that's how it's working for NVIDIA, we have CDI files for both Xavier + Orin boards on the same build. Inside each file, we use different names for device description, so we have "nvidia.com/xavier-gpu" for Xavier and "nvidia.com/orin-gpu" for Orin..

I was just thinking about this. How do you distinguish between them? Aren't the device names similar? Won't you have conflicts?

We can name these devices whatever we want, originally nvidia-ctk will always use "nvidia.com/gpu" during the CDI generation, I just changed them to nvidia.com/xavier-gpu and nvidia.com/orin-gpu

I don't know if I understood your question, but the main idea is that the CDI string works as a "hardware ID", the same way we specify PCIe Bus Address, network interface names (eth0, wlan0), etc, in the hardware device model, for this particular case we specify the CDI string which points to the device described in the CDI file.... this makes the "native container GPU passthrough" work transparently with the controller, so the user can "pass-through" a GPU for a native container in the same way it pass-through a PCI Video card on x86, for example

What I meant was, if we already define the CDI string inside the app instance, e.g. nvidia.com/gpus=0, then that is how containerd will take it and build the right config.json OCI spec for it, so why does pillar need to have access to it? What is that chunk of code doing?

We don't define CDI string inside the Edge App, the Edge App should be as any regular Edge App, the only requirement is to have NO_HYPER as the virtualization mode. Then, we are going to passthrough a GPU I/O adapter to this Edge App, as any regular PCI passthrough... the trick happens when we parse the I/O adapters from the device model and found the "cdi" attribute under "cbattr", so for native containers (and only for native containers) we will use this string as a CDI device and processing accordingly....
This approach makes the CDI solution 100% compatible with the current passthrough mechanism and it requires no changes neither in the API nor in the controller side....

Ok, now that makes sense. So there still is a "translation" going on between "how GPU appears in EVE API" and "how GPU is listed in CDI files". The work in pillar is there to do that translation. Correct? Can we capture that in the docs?

Ok, now that makes sense. So there still is a "translation" going on between "how GPU appears in EVE API" and "how GPU is listed in CDI files". The work in pillar is there to do that translation. Correct? Can we capture that in the docs?

Correct. Ok, I will update the documentation...

Updates in this PR:

Documentation updated.


Proposal: failureStrategy for DAGs and expandable tempaltes

Summary
Support more advanced strategies for when failing from a DAG or Steps template.
Use Cases
Currently a DAG has failFast, and recently templates also support failFast in conjunction with parallelism and with{Items,Prams}, etc. However, this could be extended further.
Something like:
failureStrategy:
  when: "{{numberFailed}} > 2 || {{numberSkipped}} > 0"
  terminateRunningPods: true     # or `false` to allow them to complete

Message from the maintainers:
Impacted by this bug? Give it a 👍. We prioritise the issues with the most 👍.

My ideal failFast behavior is: the workflow should retry tasks that have retryStrategy set, but once all retries are exhausted, the workflow should stop scheduling other tasks and fail.
I'm on Argo 3.1, and I can't get this behavior. Is it possible, or is it expected that this doesn't work?
I tried the following permutations:

by default without any explicit configuration, my workflows don't fail fast: if a task fails, Argo tries to run the rest of the workflow instead of failing sooner.
when I add failFast: true to all my dag templates*, I do get failFast behavior, but then failed tasks don't retry, and the first task failure results in the workflow failing. This is failing too fast.
when I add failFast: true to only 1 of the dag templates, retries work but then I don't get failFast behavior. I tried adding failFast to each dag template separately, and all had the same behavior.

*all my dag templates are these 4:

the outermost dag. this is the entrypoint, and just calls exit-handler-1
exit-handler-1: just contains subgraph-2
subgraph-2: contains my actual workflow tasks
fol-loop-4: i have a for-loop for 5-fold cross validation


Does GoogleNews support persian or arabic language?

As README shows,
goooglenews = GoogleNews(lang='en')

or
googlenews = GoogleNews(lang='en', region='US')

But it may not always, even on Google website may not always work correctly.


Generate .rubocop_todo.yml without any exclude limit

(Apologies if this has been discussed previously, it's hard to search for with such a large issue volume.)
Is your feature request related to a problem? Please describe.
When setting up RuboCop on a new project with a lot of existing offences, running --auto-gen-config results in many cops being entirely disabled (because there are more than the default limit of 15 occurrences).
To avoid that, I typically pass --exclude-limit with an arbitrary high limit such as 999999.
Describe the solution you'd like
I'd like to have a cleaner way to specify that no limit should supply, e.g:

--exclude-limit=0 (treat 0 as a special indicator)
--exclude-limit=-1 (treat any negative number as a special indicator)
--no-exclude-limit

Describe alternatives you've considered
n/a
Additional context
n/a

I would rule out --exclude-limit=0 beacuse it breaks compatibility. It can currently be used with the opposite purpose; to generate a todo file with no Exclude parameters.
Of the remaining two I like --no-exclude-limit the best, as I think using -1 is not entirely logical.

Thanks for implementing this @r7kamura!


LICENSE?

Thanks for making this great software and blog post. Would you be willing to apply a license the code?
unlicense, apache 2 or MIT perhaps?
https://help.github.com/articles/licensing-a-repository/

Thank you!


Jest does not asserts throw undefined as expected

Do you want to request a feature or report a bug?
Bug
What is the current behavior?
Throwing undefined could not be asserted correctly. Although throwing undefined might not be a good idea overall, but in some cases the code is throwing it, and it needed be tested.
If the current behavior is a bug, please provide the steps to reproduce and
either a repl.it demo through https://repl.it/languages/jest or a minimal
repository on GitHub that we can yarn install and yarn test.
https://repl.it/repls/AdolescentTidyLead
function testThrow() {
  throw undefined;
}

// test only success when throwing something except undefined
expect(() => testThrow()).toThrowErrorMatchingSnapshot(); // failed

What is the expected behavior?
Should assert undefined as other throwing cases, I think snapshot has something matter with this also, actually the snapshot created in previous example shows unexpected snapshot content also, which might be
exports[`error handler throw except undefined works by toThrowErrorMatchingSnapshot 1`] = `error message`;

Please provide your exact Jest configuration
More or less the same as default.
Run npx envinfo --preset jest in your project directory and paste the
results here
System:
    OS: macOS High Sierra 10.13.4
    CPU: x64 Intel(R) Core(TM) i5-5257U CPU @ 2.70GHz
  Binaries:
    Node: 8.8.1
    Yarn: 1.3.2
    npm: 5.4.2
  npmPackages:
    jest:
      wanted: ~22.2.1
      installed: 22.2.1

Fixed in v23.


[WIP] Set up NetworkManager automatically

What does this PR do?
This removes the extra step of running the
openshift-ansible/playbooks/byo/openshift-node/network_manager.yml
before installing openshift. In addition, the playbook relies on a
host group that the provisioning doesn't provide (oo_all_hosts).
Instead, we set up NetworkManager on CentOS nodes automatically. And
we restart it on RHEL (which is necessary for the nodes to pick up the
new DNS we configured the subnet with).
This makes the provisioning easier and more resilient.
How should this be manually tested?
Run an end-to-end deployment on RHEL+Enterprise and Centos+Origin without running the network_manager playbooks.
Is there a relevant Issue open for this?
none
Who would you like to review this?
cc: @Tlacenka  @bogdando PTAL

Setting this to [WIP] because I didn't get to test this thoroughly yet.

Alright, the end-end for centos/origin worked for me. Testing rhel/enterprise now.

Got a successful end to end for rhel & enterprise, too. Removing the WIP tag, this is ready for reviews and merging now.

Could we reuse the openshift-ansible/playbooks/byo/openshift-node/network_manager.yml instead of adding more roles to maintain?

Not as it stands right now. It's a playbook not a role so we can't import it with ansible-galaxy like we do the DNS stuff. Plus we really need "state=restarted" not just "started" for RHEL.
We could move the node-network-manager role to openshift-ansible and update our code and their network_manager.yml to use it (if they're happy with that).
But even then, I'd prefer we merge this now and replace it with ansible-galaxy when that role is merged.
What do you think?


METEOR MN2-2

I have understood it uses OQPSK demodulation, so cannot be decoded by this software.

It looks like M2-2 not only uses a different modulation scheme, but also transmits data in a different format. And I haven't found a datasheet describing the new data format yet, so I'm afraid I won't be able to do much for now. If I find one, I'll try to support Meteor M2-2 as well.

I've pushed an update on the 'devel' branch that supports the differential decoding required for M2-2 (-d flag). It's still not completely bug-free, but it should work fairly well.

Thanks for that, I am testing "Meteor-M2 LRPT demodulator v0.3-beta1" right now with some files I have created with the very same command I use for M2
rtl_fm -M raw -f ${frequency}M -s ${sampling}k -g 48 -p 0.0 | sox -t raw -r ${sampling}k -c 2 -b 16 -e s - -t wav ${filename}.wav rate 96k
so I am not entirely sure if are correctly recorded.

M2 and M2-2 take up about the same bandwidth, so there is no significant difference between recording the newer satellite and the older one. So yes, the recordings you have should be decodable.

@dbdexter-dev , great work!
With minor changes, I compiled the demodulator and decoder using MinGW-w64 for Windows and tested them on a previously saved raw IQ file.
2019-07-19_10_32_M2_2_best.flac (458 Mb, OQPSK, symrate 72K) — https://yadi.sk/d/MDTNwV8AzayWiQ
This file taken from http://www.radioscanner.ru/forum/topic47659-127.html#msg1441079 and recoded to FLAC.
I added to the demodulator the ability to read standard input instead of regular files to load decoded FLAC files instead of huge WAVs, so the process looks something like this:
flac.exe -s -c -d rawIQ.flac | meteor_demod.exe -m oqpsk -B -R 1000 -
meteor_decode.exe -a 66,65,64 -d -q -s LRPT_YYYY_MM_DD-HH_MM.s

And here are the results obtained by the decoder and M2_LRPT_Decoder (v42, 2<IP_ADDRESS>2):

With default settings, meteor_decode gives a bit more errors and omissions on a weak and noisy signal. if you increase the options "fir-order" and "oversamp", then the errors become much less at the cost of increasing the time.

I've successfully decoded a MN2-2 signal (symrate: 80000) a few days ago, but with the MN2-2 pass today, meteor_decode (beta/devel branch) is unable to find any packets.
Demod with meteor_demod:

~/sdradio/src/meteor_demod_v3/src/meteor_demod -r 80000 -m oqpsk gqrx_20190824_133714_137900000_140000_fc.wav

Decode with meteor_decode:

~/sdradio/src/meteor_decode/src/meteor_decode -d  -s -a 66,65,64 LRPT_2019_08_24-17_05.s

LRPT decoder v0.2-beta2

Decoding started
0x03E1F31F rs=-1
Decoding complete
Successfully decoded packets: 0/4105 ( 0.0%)

I've replayed the wav file with SDR# connected to LRPTDecoder and was able extract the three channels, so I'm sure there is data available.
All files available at: https://chaospixel.com/pub/rtlsdr/mn22/rec20190824/

Do you know when exactly you succeeded in decoding that M2-N2 pass the last time?
Until a few days ago (2019-08-20 ~12:00 UTC) M2-N2 transmitted with a 72k rate. Since then I had no success and I believe the data structure is slightly different from what meteor_decode expects right now.

@benelsen not sure, I remember I've used meteor_demod with -s 80000 a few times and got good results with meteor_decode from the *.s file. IIRC it was on the same/next day as the old meteor switched to 137.1 MHz and the new used 137.9.

I know I'm eons late on this, but I finally had enough time to sit down and implement 80k mode decoding the right way. Pretty much useless for now since M2-2 was bonked by a meteorite, but will probably come in handy after M2-3 launches later this year.


Longwave Heat transfer is ignored on the inside of surfaces

The longwave radiation on the inside of the surfaces was causing stability issues... for now I have  simply set the internal radiant temperature to be that of the inside of the surface,
let mut back_env = ConvectionParams {
      air_temperature: t_back,
      air_speed: wind_speed * self.wind_speed_modifier,
      rad_temperature: self.parent.back_temperature(state), //(ir_back/crate::SIGMA).powf(0.25) - 273.15,<--- The physically correct value was commented
      surface_temperature: self.parent.back_temperature(state),
      roughness_index: 1,
      cos_surface_tilt: self.cos_tilt,
};

This has been updated: the rad_temperature is now the Air temperature in the adjacent Zone.


Read Exception

Exception:  The ReadValueAsChunk method is not supported on node type EndElement
            var options = new SylExcel.ExcelDataReaderOptions { Schema = SylExcel.ExcelSchema.Default, GetErrorAsNull = true };
            //collect data
            **using (SylExcel.ExcelDataReader excelDataReader = SylExcel.ExcelDataReader.Create(Setup.FilePath, options))**

Exception occurs on create
File sent via email.

Fixed in https://www.nuget.org/packages/Sylvan.Data.Excel/0.2.0-b0002

Hello Mark,
I had send you additional query regarding missing method InitializeSchema, how was it replaced?

I replaced that method with Initialize, which uses the schema that is passed to the constructor options object. The design of the InitializeSchema method felt a bit clumsy and duplicated what was already available via the constructor options.

Im getting exception after that change:
At step: var dataReader = excelDataReader.Select(Setup.NeededHeaders());
'Specified argument was out of the range of valid values. (Parameter 'names')'
                //collect data
                using (SylExcel.ExcelDataReader excelDataReader = SylExcel.ExcelDataReader.Create(Setup.FilePath, options))
                {
                    //loop to locate needed sheet from passed setup
                    if (!string.IsNullOrWhiteSpace(Setup.SheetName))
                    {
                        while (excelDataReader.WorksheetName != Setup.SheetName)
                        {
                            excelDataReader.NextResult();

                            if (excelDataReader.WorksheetName == null)
                            {
                                //throw exception, that sheet was not located
                                throw new Exception("didnt find the sheet");
                            }
                        }
                    }

                    //loop to find headers, this will allow to skip unwanted rows, such as comments, empty lines
                    for (int i = 0; i < Setup.StartRow; i++)
                    {
                        excelDataReader.Read();
                    }
                    //get all coulmns in file to column specified as max
                    var schema = Schema.Parse(Setup.JoinHeaders());

                    excelDataReader.Initialize();
                    //excelDataReader.InitializeSchema(schema.GetColumnSchema(), useHeaders: true);

                    var dataReader = excelDataReader.Select(Setup.NeededHeaders());

` var options = new SylExcel.ExcelDataReaderOptions { Schema = SylExcel.ExcelSchema.Default, GetErrorAsNull = true };
I declared headers later on

So i wouldn't be able to change schema later on? I can only pass schema during initialization?

Technically you can change the schema whenever you want, but it will require more work. The Schema option is of type IExcelSchemaProvider. ExcelSchema is a simple implementation of that interface. You can provide a custom implementation that allows you to do whatever you want.

I'll probably be adding a similar (initialize) API to the csv reader too at some point.


Unhandled state "chargingerror" (charging dock disconnected from power)

Hello everybody,
We just bought a our first Roomba and I am trying to integrate it into our OpenHab setup.
I noticed, that the app stopped responding after moving the charging base from one room to another.
After further testing and analyzing the communication from the Roomba, I seems like Roomba reports "chargingerror" state inside the cleanMissionStatus_phase when the base station is unplugged from power.
This state is unhandled and thus causing unhandled exception that kills the mqtt thread.
App does not recover from this state and requires a restart.
The hacky fix would be to add a early return before the array key access if the new state is unknown at https://github.com/NickWaterton/Roomba980-Python/blob/master/roomba/roomba.py#L829, but there must be a better solution.
I am running:

Roomba i7, fw: 3.2.9
App 1.2.9 on python 3.7.3
Raspberry Pi 4 2GB + latest stable Raspbian

Dec 25 20:14:04: [I 2020-12-25 20:14:04,287] *******************
Dec 25 20:14:04: [I 2020-12-25 20:14:04,287] * Program Started *
Dec 25 20:14:04: [I 2020-12-25 20:14:04,287] *******************
Dec 25 20:14:04: [I 2020-12-25 20:14:04,288] Roomba.py Version: 1.2.9
Dec 25 20:14:04: [I 2020-12-25 20:14:04,289] Python Version: 3.7.3 (default, Jul 25 2020, 13:03:44) [GCC 8.3.0]
Dec 25 20:14:04: [I 2020-12-25 20:14:04,289] Paho MQTT Version: 1.5.1
Dec 25 20:14:04: [I 2020-12-25 20:14:04,289] PIL Version: 8.0.1
Dec 25 20:14:04: [I 2020-12-25 20:14:04,289] <CNTRL C> to Exit
Dec 25 20:14:04: [I 2020-12-25 20:14:04,290] Roomba 980 MQTT data Interface
Dec 25 20:14:04: [I 2020-12-25 20:14:04,290] connecting to broker
Dec 25 20:14:04: [I 2020-12-25 20:14:04,296] Creating Roomba object <IP_ADDRESS>
Dec 25 20:14:04: [I 2020-12-25 20:14:04,296] CONTINUOUS connection
Dec 25 20:14:04: [I 2020-12-25 20:14:04,296] connecting Roomba <IP_ADDRESS>
Dec 25 20:14:04: [I 2020-12-25 20:14:04,297] Posting DECODED data
Dec 25 20:14:04: [I 2020-12-25 20:14:04,297] Connecting robi
Dec 25 20:14:04: [I 2020-12-25 20:14:04,298] Setting TLS
Dec 25 20:14:04: [I 2020-12-25 20:14:04,321] Setting TLS - OK
Dec 25 20:14:04: [I 2020-12-25 20:14:04,751] Roomba Connected robi
Dec 25 20:14:04: [I 2020-12-25 20:14:04,971] Received Roomba Data robi: $aws/things/E59A****************************/shadow/update, b'{"state":{"reported":{"batPct": 94, "batteryType": "F12432832R", "bbchg": {"nChatters": 0, "nKnockoffs": 3, "nLithF": 0, "nChgOk": 5, Dec 25 20:14:05: [W 2020-12-25 20:14:05,021] Error looking up Roomba error message 104
Dec 25 20:14:10: Exception in thread Thread-1:
Dec 25 20:14:10: Traceback (most recent call last):
Dec 25 20:14:10:   File "/usr/lib/python3.7/threading.py", line 917, in _bootstrap_inner
Dec 25 20:14:10:     self.run()
Dec 25 20:14:10:   File "/usr/lib/python3.7/threading.py", line 865, in run
Dec 25 20:14:10:     self._target(*self._args, **self._kwargs)
Dec 25 20:14:10:   File "/usr/local/lib/python3.7/dist-packages/paho/mqtt/client.py", line 3452, in _thread_main
Dec 25 20:14:10:     self.loop_forever(retry_first_connection=True)
Dec 25 20:14:10:   File "/usr/local/lib/python3.7/dist-packages/paho/mqtt/client.py", line 1779, in loop_forever
Dec 25 20:14:10:     rc = self.loop(timeout, max_packets)
Dec 25 20:14:10:   File "/usr/local/lib/python3.7/dist-packages/paho/mqtt/client.py", line 1181, in loop
Dec 25 20:14:10:     rc = self.loop_read(max_packets)
Dec 25 20:14:10:   File "/usr/local/lib/python3.7/dist-packages/paho/mqtt/client.py", line 1572, in loop_read
Dec 25 20:14:10:     rc = self._packet_read()
Dec 25 20:14:10:   File "/usr/local/lib/python3.7/dist-packages/paho/mqtt/client.py", line 2310, in _packet_read
Dec 25 20:14:10:     rc = self._packet_handle()
Dec 25 20:14:10:   File "/usr/local/lib/python3.7/dist-packages/paho/mqtt/client.py", line 2936, in _packet_handle
Dec 25 20:14:10:     return self._handle_publish()
Dec 25 20:14:10:   File "/usr/local/lib/python3.7/dist-packages/paho/mqtt/client.py", line 3216, in _handle_publish
Dec 25 20:14:10:     self._handle_on_message(message)
Dec 25 20:14:10:   File "/usr/local/lib/python3.7/dist-packages/paho/mqtt/client.py", line 3444, in _handle_on_message
Dec 25 20:14:10:     self.on_message(self, self._userdata, message)
Dec 25 20:14:10:   File "/usr/local/lib/python3.7/dist-packages/roomba/roomba.py", line 460, in on_message
Dec 25 20:14:10:     self.decode_topics(json_data)
Dec 25 20:14:10:   File "/usr/local/lib/python3.7/dist-packages/roomba/roomba.py", line 722, in decode_topics
Dec 25 20:14:10:     self.update_state_machine()
Dec 25 20:14:10:   File "/usr/local/lib/python3.7/dist-packages/roomba/roomba.py", line 829, in update_state_machine
Dec 25 20:14:10:     self.current_state = self.states[self.cleanMissionStatus_phase]
Dec 25 20:14:10: KeyError: 'chargingerror'

The robot reported this:
$aws/things/E59A****************************/shadow/update:
{
  "state": {
    "reported": {
      "cleanMissionStatus": {
        "cycle": "none",
        "phase": "chargingerror",
        "expireM": 0,
        "rechrgM": 0,
        "error": 104,
        "notReady": 0,
        "mssnM": 0,
        "sqft": 0,
        "initiator": "manual",
        "nMssn": 9
      }
    }
  }
}

Could please someone take a look at this?

Thanks for the report, I’m currently re-writing the library for my new s9 and Braava jet m6.
I have it working, and will post the new version after a few more days testing.

Update: the new version is a little delayed, as my new S9 has the “error 31” problem, and I’m waiting for a replacement.
Maps are still a little buggy, but I’ll push it as soon as I feel it’s at beta stage.

Update: the new version is a little delayed, as my new S9 has the “error 31” problem, and I’m waiting for a replacement.
Maps are still a little buggy, but I’ll push it as soon as I feel it’s at beta stage.

Thanks for the update and good luck with the replacement.

Thanks for the update and good luck with the replacement.


Use cortex-m-rtic instead of cortex-m-rtfm

Following the upstream rename.

Awesome thanks, I forgot we hadn't made that change yet


add django-allauth sign in

This is currently failing because django-allauth is outdated on conda-forge. I've requested to become the maintainer of the conda feedstock and fix this.

conda feedstock has been updated


Save fonts and images to specific folders

Hi,
I am using the latest Webpack and Laravel-mix version.
I am new to both :)
I am able to save the js and sass files to the folders that I require but have not been able to set the specific folders that I need the images and fonts to save too.
This is a non Laravel build and I am trying to use it on an existing project that does not use the file structure recommended.
Could someone please point me in the right direction.
Thank you

I am using .copydirectory() to copy the assets file that is created to the correct folder.
I this the correct way or is there an easier way?

Hi, @MikeDynamic! I resolved similar task here

Thank you very much @webmarkelov. This is exactly what I was looking for!


Why don't we provide a default compiled software package?

It can be easily compiled on mainstream systems.

It can be easily compiled on mainstream systems.

Compiling on Windows is not easy at all. It almost made me give up. I think it's still necessary to provide a release package for Windows.


12.2 does not work on 10.13.3

No configuration took effect to keys. Went back to 12.1.90 and it still works.

Something was borked, not sure what.

I've got 12.2 on 10.13.3, and KE has stopped working on my device keyboard.   Everything works fine on the bluetooth keyboard I've got though.   Ideas?


can not export audio and the all images error

Thanks for your greate work!
This version had some bug !
I am use 5.4.0
1、The audio can not export
2、All images are black and the size are 128*128
3、Shader error

Can you upload the files?

OK,Here you now.
Thanks


edits

Moved default appId popualtion into the endpoint handler.
Updated body pass-through in response to reflect generic body data.
Removed commented out references to getSessionUser.
Cleaned up console logs.
Moved interfaces from endpoints into types.
Removed response types on api endpoints that no longer match response body.
Simplify/refactor collection/info endpoint to take advantage of looser typing.
Fixed error when parsing serials from body, and improve endpoint to take advantage of body pass-through.
Remove getExpressions endpoint that no longer appears to be used.
Replace getNfts with slots, which doesn't appear to be used.
Updated some out of date types.


Internal Server error 500 (Failed to call access method) while trying to delete QuestionnaireAnswer

Hello,
I think that this issue somehow connected with the #201
I tired to delete QuestionnaireAnswer with no connection to Questionnaire , and got
HTTP/1.1 500 Internal Server Error  - Failed to call access method
try this:
DELETE http://fhirtest.uhn.ca/baseDstu2/QuestionnaireAnswers/10048
Thanks,
Andrew

Hello Guys,
I undestand that this is some test server - but could you take a look into this problem? Deletion of QuestionAnswers is not working...

HI @gansoper , this is a regression caused by the validator but we have a fix already. Should have it deployed to the test server later today or possibly early tomorrow depending on time.

This fix has now been deployed, so DELETE should now work on QuestionnaireAnswers once again.


Don't update VM if nothing changed

Don't run set_vm if vm size didn't change.

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

View a preview at https://prompt.ws/r/Azure/azure-cli/5909
This is an experimental preview for @microsoft users.

@yugangw-msft yes.. it sounds more appropriate. Updated as you suggested.

@cinek810 , could you please rebase to the top and address the lint error (1 character change)? Once CI check is green, i will merge

@yugangw-msft - done

@yugangw-msft  I see it's failing because of missing return statement, what would be your advice?


document how to skip/short-circuit reconciliation

If e.g. you are certain that the body / what Render returns will not have changed.

One of the major reasons I followed a non-node approach in my old Haiku experiment was in trying to solve this issue, from what I learnt, you guys need to have a form of identification of a current state of your dom possible in a Hash attribute for every node, which will allow you to identify which node has exactly changed, that is every time a node changes, this hash attribute is update and you can use it to track which elements within a DOM tree has infact changed.


import/no-extraneous-dependencies should check export from

The following is correctly picked up by import/no-extraneous-dependencies
import { myUtil } from '@my/utils';
export { myUtil };

The following code is equivalent but does not get picked up by import/no-extraneous-dependencies
export { myUtil } from '@my/utils';

Can support for this be added?

Open to contributions on this?

I think the ‘help wanted‘ tag from @ljharb means yes 🙂


fix: remove node-sass

Since LibSass and Node Sass are deprecated, we'd better migrate to Sass. Sass is already in package.json, just execute npm uninstall -D node-sass.
Have tested with Node v18.17.0, scss files work fine for me.
Some issues about this here

node-sass requires node-gyp which is really a troublesome thing for Windows users especially for thouse with network problems. The PR can completely solve https://github.com/apache/skywalking/issues/4463

@Fine0830 Is this a dev dependency or runtime?

It's a dev dependency.


[DNM] Add sleep in clear peer meta for testing

What problem does this PR solve?
Issue Number: close #xxx
Problem Summary:
What is changed and how it works?
Proposal: xxx
What's Changed:
Related changes

PR to update pingcap/docs/pingcap/docs-cn:
PR to update pingcap/tidb-ansible:
Need to cherry-pick to the release branch

Check List
Tests

Unit test
Integration test
Manual test (add detailed scripts or steps below)
No code

Side effects

Performance regression

Consumes more CPU
Consumes more MEM

Breaking backward compatibility

Release note

/release


Channel Form feat Ability

The feat/associated abilities are listed in the readme and present in the code however don't appear as a selectable feat in-game. I was unable to find the feat or channel ray/line etc in toy box.
This is an amazing idea for ability change btw :)

screenshots
combat log
game log here: "%appdata%..\LocalLow\Owlcat Games\Pathfinder Wrath Of The Righteous"

Doesn't work yet. Forgot to set hidden flag, that's why it's in the auto generated readme.

Ok that makes sense 👍

So technically it's not even in the mod yet? It seems you can't disable it via UnityModManager settings.

Set hidden. For some reason this feature doesn't want to work. Will come back to it, when I fixed other stuff.


After the service exits, the node on zk is not deleted in time, causing the rpc call to fail

When I forcibly close the springboot program, the node information currently registered in zk is not deleted in time, but is automatically deleted at the next heartbeat time. Is there a solution currently?

I'm unsure what you are asking for. Zookeeper discovery is implemented using https://curator.apache.org/curator-x-discovery/index.html.
We have no control over what happens if the instance if forcibly exits and the connection to zookeeper is severed.

I'm unsure what you are asking for. Zookeeper discovery is implemented using https://curator.apache.org/curator-x-discovery/index.html.
We have no control over what happens if the instance if forcibly exits and the connection to zookeeper is severed.

Sorry, I mean if my service is offline, but the data of the service in zk is not deleted in time, the service may be called again, which may cause the call to fail

Sorry, I mean if my service is offline, but the data of the service in zk is not deleted in time, the service may be called again, which may cause the call to fail

That's why there is retry and various other strategies when there are stale entries in discovery.

That's why there is retry and various other strategies when there are stale entries in discovery.

ok，i'll try later.

ok，i'll try later.

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.


Deal with multiple versions of CMS

Many CMS' have very different instructions based on which version you're dealing with.  One option would be to have separate entries for Drupal 7 & Drupal 8 for example.  Another would be to show a small '7 & 8' next to the entry for Drupal, and let the user choose which they want after clicking through.

I think I’d like to implement this as a chooser (e.g. <select>) at the tope of the doc page for a CMS type. Something like this:

That works for me.  The one case I would make for instead doing it as a 'step' is the user could easily miss that dropdown and be confused why the instructions don't make any sense.  Forcing them to choose which version they have would limit that.

If you feel strongly about that then my recommendation for implementation would be an interstitial page like the first one with a list view of the versions. (Obviously hideable/skippable/configurable though.)

What would I'm not sure show?
On Wed, Jul 27, 2016 at 2:50 PM, Adam Schwartz<EMAIL_ADDRESS>wrote:

If you feel strongly about that then my recommendation for implementation
would be an interstitial page like the first one with a list view of the
versions. (Obviously hideable/skippable/configurable though.)
[image: image]
https://cloud.githubusercontent.com/assets/154613/17187984/61a3a998-5409-11e6-9c7d-ca5d71620ffe.png
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/EagerIO/EmbedBox/issues/9#issuecomment-235682709, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AADYM8KykYmysNB3HCDa8rd2aWtvKjLfks5qZ6higaJpZM4JWdRf
.

I meant to imply that the list of versions and their label text is configurable through the API. So e.g. a developer could add such an item to the versions list to show a special doc which attempts to guide the person first through figuring out what version they have. Like: “Try doing _____. If that works then you are are running Joomla Version 5. Click here to view the docs for Joomla Version 5. If that doesn’t work, try ______. If that works you are running an early version of Joomla not supported....”

Sure, my question was what would we do as a part of v1? Just put Drupal 7 & Drupal 8 in there, or are we gonna try to popular an I'm not sure page as well?

Ahh gotcha. I think it would certainly be a nice example in the docs.
I do worry that making an interstitial page with just “Drupal 7” and “Drupal 8” in there might cause people to pause a bit. So perhaps we could have some text above the list (in place of where the search input is on the initial types page) which says something like: “Select your version of Drupal below. If you’re not sure which version you have, you can check it here.” (We can probably find a better link than that but hopefully you get the idea.

Alternatively maybe we could go with the <select> idea I had above, but make the choice really juicy, perhaps two tiles which have small depictions of a differentiating piece of admin UI.

I’m fine with either of the options I suggested above. I think this is something which we can expect to evolve as we build out support for many CMSs/versions.

@adamschwartz, @zackbloom
I like the dropdown approach more since many users will either use a recent version or not know what version they have.
A design like Adam's https://github.com/EagerIO/EmbedBox/issues/9#issuecomment-235672349 with slimmed down to "Version 1.2.3" with a "Help" link adjacent seems like a good fit to me :)
Thoughts?

many users will either use a recent version

Sadly not really true: https://www.drupal.org/project/usage/drupal

not know what version they have

Doesn't that mean they're just gonna get instructions they don't understand which don't work for them? Is that the solution?

@TeffenEllis what don’t u like about this option?

(From https://github.com/EagerIO/EmbedBox/issues/9#issuecomment-235682709)

@zackbloom, @adamschwartz,
I don't believe that CMS versions will differ so much that plugin installation and pasting embed codes require knowledge of version specific instructions.
It's possible a user may have an outdated or even more recent version of the CMS and our screenshots will not match. It's also possible that the user may give up when confronted with the question.

Select a Joomla version.

Likely response,

"I'm not sure how to do that... this is hard..." *bounce*

Possible response,

I'll pick one at random.
The user was lucky, or the instructions were similar enough that it didn't matter.

Possible response,

*clicks "I'm not sure"*
The user reads our instructions on how to find the version.

They give up, or get confused along the way and give up.

They find the version, come back and navigate back to the version select page, then to the version specific embed instructions. They still need to complete the original task at this point.

Every additional step the user takes is a potential for them to give up or get lost. Showing the user a recent version has fewer risks and is likely to fit their flow.

Excellent points. Then let’s just come up with a solid design that gives enough prominence to the version selection that it is unlikely to be missed. I’ll think on this and post a mock back. In the meantime, the mock above with the <select> is a good start.

Mock posted https://github.com/EagerIO/EmbedBox/pull/34

Introduced in v0.0.11


Make the style consistent by using explicit default values while stil…

Originally there was a mix of explicit default values and initialization being done in the necessary public init() constructor  but I thought it might make more sense to just use explicit default values for all the members.
Hows it look?

No longer will merge after my refactor.
The equivalent code is now in Build/build.swift, but I don't think this is necessary. Re-open if I'm wrong.


[Key Vault Admin] Convenience layer - KeyVaultBackupClient

The Backup Client source code.
IMPORTANT:

The BACKUP LRO has a return type of "string" since the result of the operation is the URI of the specific backup.
The RESTORE LRO has a return type of "undefined" because there's no expected return value for this operation.
Both of the new LROs use core-lro's getOperationState to show the other values of the pending operation. This gets extended by the properties of the generated code's operation.

You can see the tests here: https://github.com/Azure/azure-sdk-for-js/pull/11010
This PR will fail until these PRs are merged:

~[Key Vault Admin] Convenience layer - KeyVaultAccessControlClient #10815~ Merged.
~[Key Vault Admin] No LROs on the generated code for now #11008~ Merged.

For: https://github.com/Azure/azure-sdk-for-js/issues/10799

@bterlson thank you!


fix: do not check routes field on LNURL-pay

Some servers instead of returning routes as empty array returns nothing

@Jasonvdb can you please merge this and release new version?
fixing https://github.com/synonymdev/bitkit/issues/1960

Thanks published 0.0.9


When applying an operation to a variable in a loop, Polygolf tries to replace it with a pre-calculated expression

For example this code:
$s <- 5;
println $s;
$s <- ($s * $s);
println $s;

Compiles correctly into something like this:
s=5
print(s)
s=25
print(s)

But it still does this even if we do it in a loop:
$s <- 5;

for $i 0 5 {
  $s <- ($s * $s);
  println $s;
};

=>
s=5
for i=0,4 do s=25
print(s)end

The correct behaviour should be throwing a type error.
$s is missing a type annotation so it's type should be inferred to 5..5
Then, an expression, with the type of 25..25 is being assigned to the variable $s:5..5.

The assignment is never typecheckd now.
$s <- 5;
$s <- "x";

Doesn't throw.


feat(queryRules): add queryRuleContext widget

This is the 3rd PR in the series "Merchandized Query Rules".
Summary
This headless widget sets the rule contexts (called ruleContexts) of the search parameters based on the filters.
Query rules are by default generic when not provided any context. If you provide a context, they become contextual and are only triggered when the context is matched.
Usage
instantsearch.widgets.queryRuleContext({
  container,
  trackedFilters: {
    genre: () => ['Thriller', 'Drama'],
  },
});

This will set the following ruleContexts dynamically:

ais-genre-Thriller
ais-genre-Drama

API
trackedFilters

object – no default

The filters to track to add rule contexts.
transformRuleContexts

string[] ⇒ string[] – defaults to identity function

The function to apply to the rule contexts before sending them to Algolia.
Stories
See stories →
Related

connectQueryRules
queryRuleCustomData
Merchandized Query Rules RFC

This feature is on hold – see https://github.com/algolia/instantsearch.js/pull/3597#issuecomment-474809122.

⬆ I rebased against #3617 with the workaround for setting the context and other search parameters in a single request. You can check the story.


ENH: throw (overridable) error when attempting lossy NIFTI conversion.

Partially addresses #261.
Test project /Users/inorton/work/git/BRAINSTools-build
      Start  1: PrettyPrintTableTest
1/68 Test  #1: PrettyPrintTableTest .......................................   Passed    0.07 sec
...
68/68 Test #68: DWIConvertSiemensTrio_Syngo2004A_2Test .....................   Passed   13.71 sec

100% tests passed, 0 tests failed out of 68

@ihnorton Thank you for this contribution.


"Preferences: Open Remote Settings (JSON)" opens UI settings instead of JSON

Starting with ~v1.60 (not exactly sure), the command for opening the remote-specific JSON settings file opens the UI instead.

VSCode Version: 1.60.0 or v1.61.0-insiders
Local OS Version: Windows 10 or RHEL8
Remote OS Version: Debian, RHEL7 or RHEL8
Remote Extension/Connection Type: SSH, Docker and WSL (tested with all of them)
Remote Development Extension Pack Version: v0.21.0

Steps to Reproduce:

Open ar remote workspace (either WSL, Docker or SSH)
Run command: "Preferences: Open Remote Settings (JSON)"

Does this issue occur when you try this locally?: No
Does this issue occur when you try this locally and all extensions are disabled?: n/a

The JSON version of this command was only just added, and I see the problem


UIDevice countryCode extension added

Extension provides countryCode for current device as String

Checklist

[x] I checked the Contributing Guidelines before creating this request.
[x] New extensions are written in Swift 4.
[x] New extensions support iOS 8.0+ / tvOS 9.0+ / macOS 10.10+ / watchOS 2.0+.
[x] I have added tests for new extensions, and they passed.
[x] All extensions have a clear comments explaining their functionality, all parameters and return type in English.
[x] All extensions are declared as public.

          1 Message

:book:
Thank you for submitting a pull request to SwifterSwift. The team will review your submission as soon as possible.

  Generated by :no_entry_sign: Danger

Have been busy with repairing new flat and moving to flat. Will figure out where should I start to contribute soon :)


add etcd timeout to DEFAULT_CLUSTER_RETRY_EXCEPTIONS

Short description: We need to retry get calls on "etcdserver: request timed out"
More details: Without that piece upgrade testing failed, eventhough subsequent get/post/delete worked fine
What this PR does / why we need it:
Which issue(s) this PR fixes:
Special notes for reviewer:
Bug:

/approve

/verified


Allowlist darzu extensions

Forum posts about each:
https://forum.makecode.com/t/minimap-extension-beta/1709
https://forum.makecode.com/t/timers-extension-after-x-debounce-throttle-and-in-background/1925
https://forum.makecode.com/t/text-sprite-extension/2259
https://forum.makecode.com/t/gemcrush-and-sprite-grid-extension-beta/1842
Fixes: https://github.com/microsoft/pxt-arcade/issues/2309

There are lacking license files.
If these are to be used in any official documentation they need to be in Microsoft repo.

Like home screen tutorials or homescreen games which are not marked as community games.

Okay, that's some work. I know @riknoll has a bunch he wants to polish up and get on the microsoft/ org as well.
We'll need a work item and a bit of time to get these cleaned up.

If it is less than day or two of work. I would do it right away.

https://github.com/microsoft/pxt-arcade/issues/2309 to track

In arcade-minimap -> what is assets folder? And also main.blocks & main.ts are empty. Can we remove them and from pxt.json?

Also readme doesn't tell me anything about the blocks exposed by this extension. See https://github.com/microsoft/pxt-hacking-stem on how to write the API. This read me is exposed as https://makecode.microbit.org/pkg/microsoft/pxt-hacking-stem and needs to be descriptive.

Images and gifs for documentation:

![download](https://user-images.githubusercontent.com/6453828/90169327-4ea9db00-dd53-11ea-92cf-e90baf3b7c3c.gif)
![arcade-screenshot (3)](https://user-images.githubusercontent.com/6453828/90169355-56697f80-dd53-11ea-97f3-bcdfb5250a1c.png)
![arcade-screenshot (4)](https://user-images.githubusercontent.com/6453828/90169376-5d908d80-dd53-11ea-9a98-ea22a25a7adb.png)
![arcade-screenshot (5)](https://user-images.githubusercontent.com/6453828/90169381-5f5a5100-dd53-11ea-83e4-f005fdc3a1ef.png)

There are pending issues with https://github.com/microsoft/pxt-tilemaps/issues.

@darzu can you file separate PR for each extension? I can get the ones which looks good.  For example: microsoft/arcade-sprite-data looks good and ready to be merged.

Pending issue for arcade-minimap: https://github.com/microsoft/arcade-minimap/issues

All extensions other than sprite-data require updates. These are required for approval: https://makecode.com/extensions/approval

@abchatra
Split into:
https://github.com/microsoft/pxt-arcade/pull/2340
https://github.com/microsoft/pxt-arcade/pull/2337
https://github.com/microsoft/pxt-arcade/pull/2338
https://github.com/microsoft/pxt-arcade/pull/2339
https://github.com/microsoft/pxt-arcade/pull/2341
note arcade-sprite-data is not a part of this, it's already allowlisted. You might be reading the diff wrong because of the trailing comma change.


Horizon v0.18.0 Compatibility

Horizon 0.18.0 Release
Horizon 0.18.0 has been released, which continues additional work for a better integration with Stellar Protocol 11. This release contains breaking changes from 0.17.*, including a requirement to use Postgres 9.5+, along with various changes, including deprecations, that further support the protocol changes presented in CAP-0005 and CAP-0006.
You can find the official release on Github; below are the release notes.
This issue has been filed as a reminder for compatibility — if your SDK is already compatible, feel free to just respond on the thread and close it out. Thank you, and let me know if you have any questions!
Breaking changes

Horizon requires Postgres 9.5+.
Removed paging_token field from /accounts/{id} endpoint.
Removed /operation_fee_stats endpoint. Please use /fee_stats.

Deprecations

fee_paid field on Transaction resource has been deprecated and will be removed in 0.19.0. Two new fields have been added: max_fee that defines the maximum fee the source account is willing to pay and fee_charged that defines the fee that was actually paid for a transaction. See  CAP-0005  for more information.
The following operation type names have been deprecated: manage_offer and create_passive_offer. The names will be changed to: manage_sell_offer and create_passive_sell_offer in 0.19.0.

Changes

The following new config parameters were added. When old max-db-connections config parameter is set, it has a priority over the the new params. Run horizon help for more information.

horizon-db-max-open-connections
horizon-db-max-idle-connections
core-db-max-open-connections
core-db-max-idle-connections

Fixed fee_paid value in Transaction resource ( #1358 ).
Fix int64: value out of range errors in trade aggregations ( #1319 ).
Improved horizon db reingest range command.

Thanks. I will upgrade to use the latest java sdk and address any compatibility issues as soon as that is released. Part of this may already have been addressed with the previous release a few weeks ago.
See https://github.com/stellar/java-stellar-sdk/pull/217 for details.

Should be covered as part of v0.12