Add support for reading AC status

When asking Siri

What's the status of the AC?

it responds with

Sorry, I don't what mode it's in right now.

HomeKit should be able to read the AC state for automation.

Ask this way: status of thermostat in room_name

This is al about HomeKit framework and Siri itself. The acessory provides all data according to HAP spec.


Allow the user to choose the name of the metadata file to make the PR

In FAIR Evaluator.

Something like this "Clicking a branch":

After clicking "Clicking a branch", the field for the branch opens up with "master by default":

Discard selection of branch; the purpose of putting metadata in the repo is visibility, and anything in a different branch from main/master is mostly hidden.
Allow selection of name:

[ ] Modify front-end
[ ] Update API accordingly. Modify filename in endpoint POST /metadata/pull


Update build configuration

The build configuration of this project is outdated and may no longer work.
This pull request will be merged automatically if there are no conflicts.

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Added DeprecationWarnings for people still referencing EditorsPick

I think lots of projects will have this reference so I think it's good to go the extra step to show the deprecation warning (which turned out to be quite tricky).
This fixes #1588

Note that users that haven't yet installed the searchpromotions module will get this error: no such table: wagtailsearchpromotions_searchpromotion.


Project status

I just run code and working with demo phrases on solr 7.7.2. Everything is working okay, thank you for your code.
I have questions:

What is a current project status? Do you use it in production?

I am not very familiar with java, but it seems like this project is just a thin layer for other solr features? Can i reach same behaviour with solr without this plugin?

This project is not really maintained any more.

@otisg yes i see it by commit history. But i wonder why it not maintained? Do you use something else for autocomplete feature?


Colours dont stay true

This doesnt stay true to colour. Images can become washed out.
It seems to strip off ICC colour profiles from the pdf and/or from images within the pdf
Tested on lots of pdfs.
Is there anyway to keep these?

Updated the pdfjs in latest build so do have a check and if the issue still persist then raise a bug in pdfjs github, as pdf processing is done by pdfjs.

I appreciate you trying this, unfortunately, it still has the same issue.


calculateETA error

@emilyeros and I got everything configured and running but caculateETA crashes. Would love some help.

It looks like it cannot find an osrm file to work with
do you have a ./web/data/config.json with the proper path to the *.osrm file in baseline:
"baseline":{
  "name":"baseline"
  ,"dir":"./web/data/project_1463767649122/baseline",
  "files":{
    "osm":"baseline.osm",
    "profile":"profile.lua",
    "osrm":"baseline.osrm"
   }

It might be the same as #41 did you run osrm-contract on the .osrm file?

Closing here, as this seem to come from current master, v0.2.0 branch has many changes.


chore: release main

:robot: I have created a release beep boop
db-service: 1.10.3
1.10.3 (2024-07-04)
Fixed

rewrite assoc chains if intermediate assoc is not fk (#715) (3873f9a)
Support expand with group by clause (#721) (90c9e6a)

hana: 1.0.1
1.0.1 (2024-07-04)
Fixed

Allow numeric Booleans 0 and 1 (#714) (82c4dbe)
Support expand with group by clause (#721) (90c9e6a)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/cap-js/cds-dbs/releases/tag/hana-v1.0.1 :sunflower:


Relative paths broken for --snapfile option

When trying to use the --snapfile option with snapshot, snapshot is unable to find the Snapfile if it contains a relative path.
> ls Snapshot
Runthrough             Snapfile-runthrough    Snapshot-runthrough.js Snapshot.js            SnapshotHelper.js

> snapshot --snapfile ./Snapshot/Snapfile-runthrough
/Library/Ruby/Gems/2.0.0/gems/snapshot-0.9.0/lib/snapshot/snapshot_config.rb:73:in `initialize': Could not find Snapfile at path './Snapshot/Snapfile-runthrough'. Make sure you pass the full path, including 'Snapfile' (RuntimeError)
	from /Library/Ruby/Gems/2.0.0/gems/snapshot-0.9.0/lib/snapshot/snapshot_config.rb:57:in `new'
	from /Library/Ruby/Gems/2.0.0/gems/snapshot-0.9.0/lib/snapshot/snapshot_config.rb:57:in `shared_instance'
	from /Library/Ruby/Gems/2.0.0/gems/snapshot-0.9.0/bin/snapshot:39:in `block (3 levels) in run'
	from /Library/Ruby/Gems/2.0.0/gems/snapshot-0.9.0/bin/snapshot:37:in `chdir'
	from /Library/Ruby/Gems/2.0.0/gems/snapshot-0.9.0/bin/snapshot:37:in `block (2 levels) in run'
	from /Library/Ruby/Gems/2.0.0/gems/commander-4.3.4/lib/commander/command.rb:178:in `call'
	from /Library/Ruby/Gems/2.0.0/gems/commander-4.3.4/lib/commander/command.rb:178:in `call'
	from /Library/Ruby/Gems/2.0.0/gems/commander-4.3.4/lib/commander/command.rb:153:in `run'
	from /Library/Ruby/Gems/2.0.0/gems/commander-4.3.4/lib/commander/runner.rb:428:in `run_active_command'
	from /Library/Ruby/Gems/2.0.0/gems/commander-4.3.4/lib/commander/runner.rb:68:in `run!'
	from /Library/Ruby/Gems/2.0.0/gems/commander-4.3.4/lib/commander/delegates.rb:15:in `run!'
	from /Library/Ruby/Gems/2.0.0/gems/snapshot-0.9.0/bin/snapshot:84:in `run'
	from /Library/Ruby/Gems/2.0.0/gems/snapshot-0.9.0/bin/snapshot:90:in `<top (required)>'
	from /usr/bin/snapshot:23:in `load'
	from /usr/bin/snapshot:23:in `<main>'

> snapshot -v
snapshot 0.9.0

If I pass the entire path, to the --snapfile option, snapshot finds the Snapfile, but then is unable to resolve the relative path in js_file
> snapshot --snapfile $PWD/Snapshot/Snapfile-runthrough
/Library/Ruby/Gems/2.0.0/gems/snapshot-0.9.0/lib/snapshot/snapshot_file.rb:15:in `eval': js_file at path './Snapshot/Snapshot-runthrough.js' not found (RuntimeError)
	from (eval):21:in `initialize'
	from /Library/Ruby/Gems/2.0.0/gems/snapshot-0.9.0/lib/snapshot/snapshot_file.rb:15:in `eval'
	from /Library/Ruby/Gems/2.0.0/gems/snapshot-0.9.0/lib/snapshot/snapshot_file.rb:15:in `initialize'
	from /Library/Ruby/Gems/2.0.0/gems/snapshot-0.9.0/lib/snapshot/snapshot_config.rb:68:in `new'
	from /Library/Ruby/Gems/2.0.0/gems/snapshot-0.9.0/lib/snapshot/snapshot_config.rb:68:in `initialize'
	from /Library/Ruby/Gems/2.0.0/gems/snapshot-0.9.0/lib/snapshot/snapshot_config.rb:57:in `new'
	from /Library/Ruby/Gems/2.0.0/gems/snapshot-0.9.0/lib/snapshot/snapshot_config.rb:57:in `shared_instance'
	from /Library/Ruby/Gems/2.0.0/gems/snapshot-0.9.0/bin/snapshot:39:in `block (3 levels) in run'
	from /Library/Ruby/Gems/2.0.0/gems/snapshot-0.9.0/bin/snapshot:37:in `chdir'
	from /Library/Ruby/Gems/2.0.0/gems/snapshot-0.9.0/bin/snapshot:37:in `block (2 levels) in run'
	from /Library/Ruby/Gems/2.0.0/gems/commander-4.3.4/lib/commander/command.rb:178:in `call'
	from /Library/Ruby/Gems/2.0.0/gems/commander-4.3.4/lib/commander/command.rb:178:in `call'
	from /Library/Ruby/Gems/2.0.0/gems/commander-4.3.4/lib/commander/command.rb:153:in `run'
	from /Library/Ruby/Gems/2.0.0/gems/commander-4.3.4/lib/commander/runner.rb:428:in `run_active_command'
	from /Library/Ruby/Gems/2.0.0/gems/commander-4.3.4/lib/commander/runner.rb:68:in `run!'
	from /Library/Ruby/Gems/2.0.0/gems/commander-4.3.4/lib/commander/delegates.rb:15:in `run!'
	from /Library/Ruby/Gems/2.0.0/gems/snapshot-0.9.0/bin/snapshot:84:in `run'
	from /Library/Ruby/Gems/2.0.0/gems/snapshot-0.9.0/bin/snapshot:90:in `<top (required)>'
	from /usr/bin/snapshot:23:in `load'
	from /usr/bin/snapshot:23:in `<main>'

The workaround is to remove the js_file line in my Snapfile and manually pass it in:
> SNAPSHOT_JS_FILE=$PWD/Snapshot/Snapshot-runthrough.js snapshot --snapfile $PWD/Snapshot/Snapfile-runthrough

Ah looks like snapshot detects the 'Fastlane' directory and is using that as the current directory. If I rename the 'Fastlane' directory, everything works as expected

Great to hear :+1:

@KrauseFx so it's expected behavior that --snapfile uses paths relative to the Fastlane directory otherwise it's relative the the directory in which snapshot is executed? This is very surprising. At very least maybe we add a note in the help for snapshot?

It's not, I'll have to take a closer look at this.

I just released snapshot 1.0, please follow the migration guide.
Since the underlying snapshot was completely rewritten, I'm closing this issue now. Feel free to submit a new issue if you're experiencing an issue :+1:


Pointer Buttons example throws an error

pointer buttons.js:59 Uncaught TypeError: Cannot read property 'on' of undefined
at Scene.create (pointer buttons.js:59)
Link:  https://labs.phaser.io/view.html?src=src\input\pointer\pointer%20buttons.js&v=dev

Changing  this.input.events.on to this.inputs.on. Solves this

THanks

Yeah, sorry, we're going through and fixing these as fast as we can (there are quite a lot!)

This example is now fixed.


Remove redundant file API calls (unlink before open, seek before close)

Disk I/O is the bottleneck for fast harnesses (verified by profiling). Reducing the amount of those calls should give us an immediate performance gain.
I apologize but I won't have time to test this change, as I need to start a project at work, but if something seems amiss tell me and I'll try to make some time to fix it.

Thanks! I asked lcamtuf (original creator of AFL) about the unlinks and this is what he replied:
The original unlink approach is basically slightly safer in case the fuzzed program does something weird with the input file - say, removes read or write permissions, replaces it with a symlink, whatever. Not a hugely common scenario, but that unlink() is not costing much
I think something like that would be extremely unlikely on Windows. However, let me run some tests first and then I'll decide whether to merge as is or if we should have some flag or another mechanism to revert to earlier bahavior if needed.

Apologies for the delay, I too got tied up in another project. I did some experiments that suggest, on Windows at least, removing the unlinks is going to be noticeably faster. Given the benefits and relatively low risk of breakage (famous last words), I'm going to merge as is.


multinomial classification

How we can divide training data for training multinomial classification?

When using Label-Distribution Partitioning, we have the samples of subgroup that follow label distribution. For `Partitioning Evenly' method, each subgroup has same amount of samples.


slack: 4.35.126 -> 4.35.131

Description of changes
https://slack.com/intl/de-de/release-notes/linux
Release notes mention version 4.35.134, but it's not available to download (yet?).
❯ curl -L --silent https://slack.com/downloads/linux | sed -n 's/.*Version \([0-9\.]\+\).*/\1/p'
4.35.131

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Waiting for https://github.com/NixOS/nixpkgs/pull/274995 to get merged before triggering a backport to 23.05.


Fixed compiler warnings

fix: compiler warning -Werror=unused-function
fix: compiler warning -Werror=sign-compare
fix: compiler warning -Werror=pointer-sign
fix: compiler warning -Werror=pointer-arith
fix: compiler warning -Werror=implicit-function-declaration
build: added option to enable all warnings as errors
test: enabled all warnings as errors in smoke test

Awesome. Thank you


Fixed minor issues

Issue Reference
Fixed minor issues

@shivendra-webkul
Checked and found that the issues has been fixed and working fine.

In Channel -> now it will show default -> https://prnt.sc/xtUaG5oxGrvq
In CMS Page -> Channel Checkbox centre allignment done -> https://prnt.sc/jLw70glrUgX0

@shivendra-webkul
Checked and found that the issues has been fixed and working fine.

In Channel -> now it will show default -> https://scrsht.com/11c5d2a0
In CMS Page -> Channel Checkbox centre allignment done -> https://scrsht.com/3aa90f5c


New OldNew Mashup Theme

OldNew Mashup theme submission
This basically a complete rewrite of the old OldNew Mashup theme I asked you to remove.  It's much, much better, validates against W3C org's tools, and looks better.
I hope you like if you get a chance to check it out!
NB The License file I used is LICENSE not LICENSE.md, however I have an appropriate licenselink in theme.toml and testing using the theme site generateThemeSite and reveals that the link works as expected (goes to GitHub repo's copy of LICENSE).
Also, the theme works as expected with the hugoBasicTheme, but the content under exampleSite shows off more features of the theme.  I have a demo site (linked as the theme homepage) for the theme so it's not essential that exampleSite be used.
Link to my theme repository: https://github.com/cshoredaniel/new-oldnew-mashup/tree/stable-0.9
I made sure that...

[x] the repository contains a good README.md describing my theme
[x] an open source license has been added to LICENSE
[x] all metadata have been added to theme.toml
[x] screenshots have been added in the images/ folder with the required dimensions
[x] in case I'm using a customized demo via the exampleSite folder that

[x] https://example.com is set as base url in exampleSite/config.{toml, yaml, json} to avoid the abuse of unused domains
[x] I tested that my theme's demo works with the content directory of gohugoio/HugoBasicExample

[x] I tested my theme against the gohugoio/HugoBasicExample

[x] I've checked the developer tools' console in my browser for error messages

[x] in case my theme is using Hugo Pipes features like toCSS and PostCSS that I have committed the /resources directory with all generated assets, for my theme to work in the basic version of Hugo

I'll do my best to keep the theme maintained, or let you know if it no longer is alive.

Hello Daniel,
thank you for making another submission attempt with a revised version of your theme. Let's start straight with the review:

Is it possible to create a single branch that gets updated with each new release? Otherwise we would always have to switch the newest stable-{version} branch. Pulling releases from a single, pre-defined branch is much easier in the long run.
The search does not work if a website is hosted in subdirectory, such as https://themes.gohugo.io/theme/{some-theme}/. In search.min.js you hard-coded the url to the search index as /index.json. This way you refer to https://themes.gohugo.io/index.json instead of https://themes.gohugo.io/theme/{some-theme}/index.json. A possible work-around is to define the url to the search index as variable in combination with a template function such as absURL:

var url = {{ "index.json" | absURL }};
// include search.min.js afterwards and use the url instead of a hard-coded path

@digitalcraftsman Thanks again for all you hard work on hugo themes repository and especially for the help you have given me in the past (and now).
I've been thinking about the branch thing and decided the best way forward is to make master the release (stable) branch and make the development branch something like devel-<next_version>.  I don't remember why I flipped that around (I used to do it that way).  It was probably because I got in the habit of master being the current development branch when working on OpenWrt.
On at least some projects I may fork off and oldstable-x.x.x branch when stable changes, but I think user master for the current production version rather than development better suits most expectations and norms.
Anyway, on the search form: Thanks for catching that -- it wasn't even on my radar.  The workaround seems quite satisfactory for my needs.
That has, however, reminded me of another things that's not going to work on the theme site, and that is my contact form -- it is designed to contact the same server on a different port and doesn't go out some other site (and I don't want to change that).
Is there a way to not render certain pages only when for the hugo themes site?  (Assuming exampleSite is being used and not the hugoBasicExample.  If it's just a standard hugoBasicExample, it's non-issue).

I realized for the conditional render I can check baseURL...so I'll try that out this week.

Been busy.  Will open a new issue if necessary, once ready.

@digitalcraftsman I believe I've fixed the issues with the search (no longer hard coded, and works using the test instructions in this repo's README).  Also I've made master the stable branch (so the URL for the repo is https://github.com/cshoredaniel/new-oldnew-mashup.git . Development will be done on other branches and only merged into stable for releases.
I also fixed a few other nits I noticed, unrelated to the theme site.
If you could kind review again it'd be much appreciated!

Hello @cshoredaniel
When I try to test your theme I get the following ERROR
Error: module "github.com/cshoredaniel/necolas-normalize.css" not found; either add it as a Hugo Module or store it in "/home/alex/work/src/hugoThemes".: module does not exist

It seems that you need to configure that module again, currently it is 404.

Hmmm... I wonder if it's related the version of Hugo.  My CI tests start from scratch on Travis and succeed, but I've been using an older version because there was a version that was segfaulting in the Travis Bionic environment (I believe I filed a bug about that).  I guess it time to try the latest version and do necessary updates.

@cshoredaniel
The themes repo always uses the latest Basic version of Hugo, so it's advisable to check your theme with the latest.
I am not sure whether the ERROR due to the way that module is named i.e. necolas-normalize.css. The .css extension may be causing the issue, but I'm not sure, that's just a hunch, but if it's true, then probably a bug report may need to be filed at https://github.com/gohugoio/hugo/issues

Ok, I've updated the theme (it now only uses Hugo modules, no more git submodules).  I didn't need to quite do do that (the real issue was some difference in the generated hash ca. 0.58.0 or .59.0 compared to earlier versions; no bug to report; also the Travis CI tests now work, so the reason I was sticking with 0.57.2 has been resolved).
I did notice that the generateTheme.sh results in the use of my exampleSite instead of basicTheme -- either will work, but I wanted to make sure that was intentional and not because of some issue with generateTheme.sh script.
I hope you like the new theme (and it's another theme that is using Hugo modules that folks can look at, if you think it worthwhile.
Oh, and I caved and added back at least rudimentary IE11 support -- I was trying to drop it before, but my stats show too many people trying to access my main website with IE11 for that to work.  Pity.

I did notice that the generateTheme.sh results in the use of my exampleSite instead of basicTheme -- either will work, but I wanted to make sure that was intentional and not because of some issue with generateTheme.sh script.

That's because you have mounted the exampleSite's content using Hugo Modules.
Currently the Build Script does not enforce the hugoBasicExample through Hugo modules and as a result the override does not work in your case.
However your theme's previous version was whitelisted so that the demo could render fine and I am fine with having your provided exampleSite used in the demo.
If the Build Script gets adapted to take into account Hugo Modules we will add your theme in the whitelist again.
I have added the theme in the repo in

@digitalcraftsman
The new version of the throwback Old New Mashup theme has now been added to the Themes Showcase.

Thank you for all your help, and adding my theme.

@cshoredaniel I've promote your theme on Hugo's official Twitter account.
@onedrawingperday thanks for your support in this issue.


Fix buggy $current_focus_elem code in recent conversations

In some code paths in Recent Conversations, we seem to have code that's a bit confused about the type of $current_focus_elem, which can sometimes be the literal string "table".
    if ($current_focus_elem && input_key !== "escape") {
        $current_focus_elem.trigger("focus");
        if ($current_focus_elem.hasClass("btn-recent-filters")) {
            compose_closed_ui.set_standard_text_for_reply_button();
        }
        return true;
    }

@alya somehow managed to get this code to throw an exception earlier; I don't have a reproducer but the code seems on the face of it incorrect. Maybe $current_focus_elem should be unset rather than "table" in the state where it isn't set? Or the conditional should check for a value of table? I'm not sure, but obviously "table".trigger("focus") is invalid, since strings don't have a .trigger method :).
@amanagr can you pick a plan for fixing this one?

    } else if (is_table_focused()) {
        ....
        set_table_focus(row_focus, col_focus, true);
        return true;
    }
    if ($current_focus_elem && input_key !== "escape") {
        $current_focus_elem.trigger("focus");
        if ($current_focus_elem.hasClass("btn-recent-filters")) {
            compose_closed_ui.set_standard_text_for_reply_button();
        }
        return true;
    }

@timabbott we always return before $current_focus_elem.trigger("focus"); is executed if $current_focus_elem is table. The error might be linked to https://chat.zulip.org/#narrow/stream/6-frontend/topic/hotkey.20bug though.

I think some of the other cases in that big if/else block can fall through without returning, in which case the is_table_focused check would never be run, since it's in an else block. For example, if  if ($elt.attr("id") === "recent_topics_search"), and they key isn't any of the specific 12 keys listed there, it should fall through.

Idunno, I haven't found a reproducer through that idea so far, but it seems like a bug of that form should be possible -- we don't have page_up case in the btn-recent-filters block, for example.

I think some of the other cases in that big if/else block can fall through without returning, in which case the is_table_focused check would never be run, since it's in an else block. For example, if  if ($elt.attr("id") === "recent_topics_search"), and they key isn't any of the specific 12 keys listed there, it should fall through.

In the other cases, it is fine for it to fall through since they are jQuery objects. I will try to improve this code when migrating the recent topic's navigation code!

OK, sounds reasonable. Should we close this, or remove the release goal label?

Closed it!


"Problems loading reference '.../ms-vscode.vscode-typescript-tslint-plugin-0.0.4/schemas/tsconfig.schema.json': ...

I've just started seeing this in my problems list:

For some reason I can't right-click to copy, but the tooltip shows the full text:

When I click on it, it opens my tsconfig.json file which looks like this:
{
	"compilerOptions": {
		"module": "commonjs",
		"target": "es6",
		"outDir": "out",
		"lib": [
			"es6"
		],
		"sourceMap": true,
		"rootDir": ".",
		"noImplicitAny": true,
		"noImplicitThis": true,
		"alwaysStrict": true,
		"strictFunctionTypes": true,
		"strictPropertyInitialization": false,
		"strictNullChecks": false
	},
	"exclude": [
		"node_modules",
		".vscode-test"
	]
}

The file shows a green squiggle at offset 0 (note: the offset in the error message is way past the end of this file):

If I open the file mentioned in the message there are no obvious issues - here's what 679 characters selected from the start look like:

(oh, BTW the error seems to disappear from the errors list if I close by tsconfig.json file)

(no, that's wrong - they came back when I started closing other files - now I have 0 open files but that warning still shows)

Trailing comma. Doesn't break the functionality but causes this warning to be reported

Should be fixed in 0.0.5


Running the game before saving issue

Operating system or device - Godot version:
Windows 8.1
Issue description (what happened, and what was expected):
When I run a scene that is not saved, it prompts me first to save the game. That is perfectly good. But after saving it forgets to call run. I have to press run by myself again to make it run. So I think the run function is not being called in that particular routine.
Steps to reproduce:
As stated above.
Link to minimal example project (optional but very welcome):

Please refer me to the filename concerned with this issue. I really want to do it myself if the issue is justified.

@iammangod96 I think it is editor_node.cpp


Suggest merging latest work to master

Looks like a lot of good work has piled up in the first-metrics branch.
I'd suggest merging that work into master. That will enable better collaboration so that myself and others can open PRs without requiring special knowledge of which branch has the latest and greatest stuff in it.

Created a PR #5 to merge to master


Add Open Government, Croatia

[X] My submission is formatted according to the guidelines in the contributing guide
[X] My addition is ordered alphabetically
[X] My submission has a useful description
[X] The description does not have more than 100 characters
[X] The description does not end with punctuation
[X] Each table column is padded with one space on either side
[X] I have searched the repository for any relevant issues or pull requests
[X] Any category I am creating has the minimum requirement of 3 items
[X] All changes have been squashed into a single commit

This is an interesting case. I had this case with loading page once or twice and it loaded after refreshing the page (Poland, I almost certainly didn't have an active VPN connection at the time). So in my case it looks like a random timeout.
I sent them an email asking about this problem. If they answer me something, I will let you know in this thread.


Does BookshelfJS support Soft Deletes?

I notice BookshelfJS supports 'timestamps', meaning it will automatically populate/update the created/updated columns, but I was wondering if there was a way to enable 'soft deletes', meaning when you delete a row, it will populate the 'deleted' column with the timestamp, then exclude it from further searches.

Nope #261.


Issue #145 - Use the modern save file dialog

Support using the CommonOpenFileDialog as a folder picker when choosing directories.  This behavior relies on the Windows API Code Pack which is provided by NuGet.  Since this dialog is only available on Vista and later a test which will fall back to the older Windows Forms dialog is included.
I welcome your review and any feedback you might have.

Thx for the contribution. I dislike the Microsoft Nuget because it had some major bugs in the past, but the FolderBrowser dialog seems to work well, so we'll keep the reference.
I fixed 2 things:

The CommonOpenFileDialog implements IDisposable and therefor needs manual disposal. I added the using around it accordingly. I case of an exception (see 2.) there can be a memory leak.

If you cancel the dialog, you cannot read from cofd.FileName. That results in an unhandled exception. Always try every possibility when testing :)

Take a look at it. If you agree, I accept the pull request.

Oh and a 3rd thing:
Since TL depends on the 2 new dll's, we need to add those to the installer. But you cannot know this if you are not into WiX/MSI Installer stuff :)

Thanks for taking a look at it.  I'm certainly fine with these changes, sorry for missing the IDisposable thing.  I remember looking but must have missed it.  I didn't consider the installer at all either, oops!
I'm curious about the IsPlatformSupported test and why you used the CommonFileDialog class to access it instead of the CommonOpenFileDialog?
Should I do anything as far as squashing these commits together or what is your preference for that?

IsPlatformSupported is just something the code analyze tool of VS showed me. The reason is, IsPlatformSupported  is not implemented in CommonOpenFileDialog, it is just derived from CommonFileDialog. So this changes nothing, but I like to keep things clean regarding the VS code analysis tool.
You don't need to do anything, I can just merge the pull request now. I basically commited the changes to your pull request.


[ZEPPELIN-1587] (WIP) Add impersonation routine in SparkInterpreter for current user

What is this PR for?
This is to add impersonation routine for SparkInterpreter, meaning any communication with hadoop hdfs should be done with current user credentials
What type of PR is it?
Improvement
Todos

[x] - add privilege mode
[ ] - add tests

What is the Jira issue?
ZEPPELIN-1587
How should this be tested?
executing hdfs related file write should be done by your logged in username, e.g. in the example i used the following code:
val file = sc.textFile("hdfs:/inputFilePath")
file.cache()
val wordCount = file.flatMap(line => line.split(" ")).map(word => (word, 1)).reduceByKey(_ + _)
wordCount.saveAsTextFile("hdfs:/outputFolderPath")

Screenshots (if appropriate)

Questions:

Does the licenses files need update? no
Is there breaking changes for older versions? no
Does this needs documentation? possibly

I don't know how much this helps in impersonation. At least it doesn't affect executor. Do you see any impact on the driver side ?

@zjffdu i updated description and pushed some changes. as you can see from screenshot it makes usage of current username when writing to hdfs. So in the example above, although out_user1 folder is owned by user1, still it contains inside files (e.g. part0000) with different owner khalidhuseynov. So my guess is that it affects only driver and not the executors, and executors are the ones writing part0000. let me know what you think on it.
also feedback from @Leemoonsoo @prabhjyotsingh @felixcheung would be appreciated on this one as well

Using --proxy-user instead of doAs would work? https://issues.apache.org/jira/browse/ZEPPELIN-1730

@Leemoonsoo yes that's possible; moreover I originally implemented it using proxy-user. the only thing is that your hdfs for example in that case should be configured with
<property>
<name>hadoop.proxyuser.<username>.hosts</name>
<value>*</value>
</property>

<property>
<name>hadoop.proxyuser.<username>.groups</name>
<value>*</value>
</property>

in hdfs-site.xml so that you can't run without that configuration, which makes sense.

@khalidhuseynov  I think proxy-user is the correct way to implement impersonation for spark. Your approach in this PR only apply to driver side. If you look at the RM UI, the yarn app owner is the still the origin user. The reason that the owner of file is user1 in your screenshot is that the hdfs commit operation is invoked in driver side. And the change in hdfs-site.xml is necessary for impersonation.

@zjffdu makes sense. then i'll change it back to use proxy-user with additional flag, in order not to affect first time users not using impersonation.

@khalidhuseynov How about using System.setProperty("HADOOP_USER_NAME", getUserName()); instead of proxy-user setting?
Could you review https://github.com/astroshim/zeppelin/pull/15?
It might work as you expected.

@astroshim thanks for help, I'll test with proxy-user first since it's most recommended way, and possibly we can use your configuration there.

So I've done some research and --proxy-user argument is used with either spark-submit or spark-shell normally, and each of them creates new spark context. The problem is that Zeppelin calls spark-submit only once in shared and scoped modes when initializing interpreter, and afterwards single spark context is used. Thus it makes having impersonation through --proxy-user on spark interpreter in shared and scoped mode complicated. For isolated mode, it's easier since we can pass user with SparkConf for each spark context on initialization. any suggestions /opinions are welcome.

That's correct, impersonation for spark interpreter can only be applied to isolated mode. It is due to capability of spark.


scoped_token returns possibly incorrect "invalid value for scopes" error

Describe the bug
I'm trying to create an artifactory_scoped_token with the scope of a specific group. This is my (simplified) code:
resource "artifactory_scoped_token" "codefresh_token" {
  username          = "svc-codefresh-${var.project_key}"

  scopes = [
    "applied-permissions:groups/${artifactory_group.codefresh_group.name}"
  ]
}

# resources
resource "artifactory_group" "codefresh_group" {
  name        = "svc-codefresh-${var.project_key}"
  description = "Automatically created by BuilderTools automation scripts."
}

variable "project_key" {
  type = string
}

terraform validate passes, but when running  terraform plan I get this error:
│ Error: expected scopes to be one of [applied-permissions/user applied-permissions/admin applied-permissions/groups system:metrics:r system:livelogs:r], got applied-permissions/groups:svc-codefresh-iops

and

│ Error: invalid value for scopes (must be '<resource-type>:<target>[/<sub-resource>]:<actions>')

The API docs here suggest that applied-permissions/groups:<group_name> is a valid scope. https://www.jfrog.com/confluence/display/JFROG/Artifactory+REST+API#ArtifactoryRESTAPI-CreateToken.1
In fact, when I try to create a token using the API, it works fine:
$ curl -H "Authorization: Bearer $JFROG_TOKEN" -XPOST "https://omitted/access/api/v1/tokens" -d "scope=applied-permissions/groups:svc-codefresh-iops"
{
  "token_id" : "omitted",
  "access_token" : "omitted",
  "expires_in" : 31536000,
  "scope" : "applied-permissions/groups:svc-codefresh-iops",
  "token_type" : "Bearer"
}

Requirements for and issue

[x] A description of the bug - above
[x] A fully functioning terraform snippet that can be copy&pasted (no outside files or ENV vars unless that's part of the issue). If this is not supplied, this issue will likely be closed without any effort expended. - see above
[x] Your version of artifactory (you can curl it at $host/artifactory/api/system/version - 7.34.4
[x] Your version of terraform - 1.1.5
[x] Your version of terraform provider - 6.9.1

Expected behavior
I expect the scoped_token resource to accept the group scopes input described in the API docs.
Additional context

@tredman Thanks for catching this.

Hey @alexhung - in 6.9.2 I'm getting a new error as well as the original ones:
│ Error: expected scopes to be one of [applied-permissions/user applied-permissions/admin system:metrics:r system:livelogs:r], got applied-permissions:groups/svc-codefresh-iops
│
│   with module.epic-projects["iops"].artifactory_scoped_token.codefresh_token[0],
│   on modules/epic-projects/main.tf line 264, in resource "artifactory_scoped_token" "codefresh_token":
│  264:   scopes = [
│  265:     "applied-permissions:groups/${artifactory_group.codefresh_group.name}"
│  266:   ]
│
╵
╷
│ Error: invalid value for scopes (must be 'applied-permissions/groups:<group-name>[,<group-name>...]')
│
│   with module.epic-projects["iops"].artifactory_scoped_token.codefresh_token[0],
│   on modules/epic-projects/main.tf line 264, in resource "artifactory_scoped_token" "codefresh_token":
│  264:   scopes = [
│  265:     "applied-permissions:groups/${artifactory_group.codefresh_group.name}"
│  266:   ]
│
╵
╷
│ Error: invalid value for scopes (must be '<resource-type>:<target>[/<sub-resource>]:<actions>')
│
│   with module.epic-projects["iops"].artifactory_scoped_token.codefresh_token[0],
│   on modules/epic-projects/main.tf line 264, in resource "artifactory_scoped_token" "codefresh_token":
│  264:   scopes = [
│  265:     "applied-permissions:groups/${artifactory_group.codefresh_group.name}"
│  266:   ]
│


Reorganize the crate and rename to bindgen.

Fixes #398
Fixes #21
r? @fitzgen

cc @Yamakaky

You should change the version to 0.20, so that it's considered an upgrade on crates.io.

Good catch @Yamakaky :)

:umbrella: The latest upstream changes (presumably #413) made this pull request unmergeable. Please resolve the merge conflicts.

I'll need to update my tutorial now :)

:pushpin: Commit aad93a8 has been approved by fitzgen,Yamakaky

@bors-servo r=fitzgen,Yamakaky
Yay!

:hourglass: Testing commit aad93a8 with merge ab6117c...

:sunny: Test successful - status-travis

@emilio did you publish a new version to crates.io?


Update certs (2023.06 revision)

As it says.

Thanks!

Cherry-picked for 3.6.

Cherry-picked for 3.5.3.


Provide Meter(metrics) system

Hi dev
This pull request introduces the meter system into the SkyWalking core. Meter system is compatible with any metrics system in theory. It shares the same streaming calculation core and still pluggable to different protocols and different metrics read modes(pull/push, grpc/http/mq).
Here are the basic and simple usages of the MeterSystem APIs.
Meter Creation
New meter could be created based on metrics name, function, scope and data type.

Metrics name is still the storage entity name.
Functions are every similar with the OAL function, just accepting different input.

final MeterSystem meterSystem = MeterSystem.meterSystem(getManager());
meterSystem.create("test_long_metrics", "avg", ScopeType.SERVICE, Long.class);

NOTICE, this creation should only be called in the module#prepare stage, otherwise, Can't create new metrics anymore exception will be raised after the CORE module start stage finished. You may find out, there is a chance create could be executed successfully in your own module#start stage, but it it just because of the sequence of provider loaded by the class loader, no guarantee, so please don't do that.
Runtime Calculation
AcceptableValue is the object created at the runtime to accept new metrics value.
         final MeterSystem service = getManager().find(CoreModule.NAME).provider().getService(MeterSystem.class);
        Executors.newSingleThreadScheduledExecutor().scheduleAtFixedRate(new Runnable() {
            @Override
            public void run() {
                final AcceptableValue<Long> value = service.buildMetrics("test_long_metrics", Long.class);
                value.accept(MeterEntity.newService("abc"), 5L);
                value.setTimeBucket(TimeBucket.getMinuteTimeBucket(System.currentTimeMillis()));
                service.doStreamingCalculation(value);
            }
        }, 2, 2, TimeUnit.SECONDS);

Meter Functions
Right now, only avg function has been implemented. I submit this PR as soon as possible to get your feedback. I will add more functions.

Codecov Report

Merging #4694 into master will decrease coverage by 51.08%.
The diff coverage is 0.00%.

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

@mrproliu @JaredTan95 @arugal Does any of you what to add a meter/metrics toolkit package for metrics collection? Also take part in this PR about the backend feature.

need comment!

@geektcp What do you mean?

Make slow trace query available in the sampled record. Logically, they are the same thing. The UI doesn't need to concern about the trace as a special case.
Endpoint dependency will be removed from the dashboard. Because no query available for it. We will provide a new page for that in 8.1, according to @Fine0830
Comparison page will be removed due to dashboard is powerful enough to replace it.


Simplify ZipShortest implementation

The various Zip* methods currently share implementation in .ZipImpl(). However, the code is simpler for each one when they are written separately; that is, in this case, the variances are more than the commonality. As such, we should allow each method to be implemented separately.
This PR updates the implementation of ZipShortest to be done separately from .ZipImpl().

Possibly a duplicate of PR #715 by @Orace?

Duplicate in the sense that both separate the implementations of the three zip functions, yes. However, #715 uses T4 to generate separate implementations of each method for argument count 2-4. #715 and #904 have essentially the same implementation, with some variances on how the implementation is written.

Closing in favor of PR #715.


Add authenticated decorator to handlers in doc

I think it would be good to recommend using the authenticated decorator in the documentation examples for the extension handlers.

Ah, that's a great point—though, it adds some extra complexity to the example without explanation.
Do you mind adding a sentence somewhere (maybe a parenthetical) in these docs to help acknowledge why the decorator is there? Maybe a sentence like:
"(it's best practice to wrap each handler method with the "authenticated" decorator to ensure that each request is authenticated by the server)".

Thanks for the review and the sentence 😜 @Zsailer


I need to find a DVI-D switch that can manage 1440p @ 96Hz. If someone else stumbles upon this issue, and know of such a swtich, let me know and I'll buy you a beer.

This switch solved my woes. It might not be the exact same item, but it at least looks identical. Works with 1440p @ 96Hz.


feat(listr): accessing parent task

resolve: #141

Codecov Report

Merging #143 into develop will increase coverage by 0.10%.
The diff coverage is 100.00%.

@@             Coverage Diff             @@
##           develop     #143      +/-   ##
===========================================
+ Coverage    82.03%   82.14%   +0.10%
===========================================
  Files           16       16
  Lines          501      504       +3
  Branches       123      124       +1
===========================================
+ Hits           411      414       +3
  Misses          31       31
  Partials        59       59

Impacted Files
Coverage Δ

src/interfaces/listr.interface.ts
100.00% <ø> (ø)

src/renderer/default.renderer.ts
77.44% <ø> (ø)

src/renderer/verbose.renderer.ts
75.00% <ø> (ø)

src/lib/task-wrapper.ts
87.09% <100.00%> (+1.38%)
:arrow_up:

Continue to review full report at Codecov.

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

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Discontinued/replaced NCBI gene id

Description of the issue:

It is found that in the gene annotation file genes.tsv one associated Entrez gene id 107986084 was discontinued by NCBI and replaced with 7375.

Expected feature/value/output:

The discontinued/replaced NCBI ids can be updated to the latest ones
Ideally this update could be automated by the get_ensembl_ID_mapping.py script mentioned in #157

I hereby confirm that I have:

[X] Done this analysis in the master branch of the repository
[X] Checked that a similar issue does not exist already

I noticed that the updated genes.tsv file (on devel after merging #251) contains the following entry in the NCBI (geneEntrezID) column for this gene: 7375;107986084. I'm assuming that with later Ensembl updates that the deprecated ID (107986084) will be removed, but at the moment it's partially fixed.
Since the updated workflow with genes.tsv does not allow for manual modification of this file (thereby offloading the maintenance responsibilities to Ensembl), I will close this issue under the assumption that it will soon be fixed on Ensembl.

@JonathanRob no this issue is not fixed, let's keep it open.

@Hao-Chalmers my reason for closing this issue is because, with our current workflow, the responsibility of maintaining the proper gene ID associations is now placed on Ensembl. So in reality, the issue should be made with Ensembl, not Human-GEM, since we do not have the power to fix this. But you can keep the issue open if you want to make users aware of the temporary existence of an expired NCBI ID in our genes.tsv file.

But I agree to close this issue. Moreover I think the order of the IDs in genes.tsv is not random, Ensembl always puts the more meaningful ID at the left most position.

Ensembl always puts the more meaningful ID at the left most position.

@pecholley if you have any evidence supporting this?

@haowang-bioinfo I remember briefly looking in the documentation for the answer (evidence), but couldn't find it. Since both @JonathanRob and @pecholleyc were happy to close the issue, I will go ahead and close it.


When primary key is a composite key partition table is having only one key as primary key.

Steps to reproduce.:
Parent table defination :
request
(
message_id character varying(42) COLLATE pg_catalog."default" NOT NULL,
created_date timestamp without time zone,
state character varying(18) COLLATE pg_catalog."default",
err_msg character varying(1000) COLLATE pg_catalog."default",
err_code character varying(3) COLLATE pg_catalog."default",
campaign character varying(64) COLLATE pg_catalog."default" NOT NULL,
CONSTRAINT request_campaign_id PRIMARY KEY (message_id, campaign)
)
WITH (
OIDS = FALSE
)
TABLESPACE pg_default;

pgslice prep hotwire.request created_date month

pgslice add_partitions hotwire.request --intermediate --past 60 --future 60

4)pgslice fill public.request --batch-size 50000
Insert failed due to duplicate entry.

Child table defination
CREATE TABLE hotwire.request_201304
(
message_id ,
created_date ,
state ,
err_msg ,
err_code ,
campaign ,
CONSTRAINT request_201304_pkey PRIMARY KEY (message_id),  ->> this is the issue.
CONSTRAINT request_201304_created_date_check CHECK (created_date >= '2013-04-01'::date AND created_date < '2013-05-01'::date)
)
INHERITS (hotwire.request_intermediate)
WITH (
OIDS = FALSE
)
TABLESPACE pg_default;

Thanks
Kamal

Hey @kamaljha, thanks for the detailed report 💯 This is fixed on master.


♻ Migrate to non-nullable-by-default

Closes #43, continued from #45 .

The PriorityQueue has copied/pasted from the collection package.

cc @lrhn if you wanna continue your review.

Looks like util.dart needs to be formatted again, everything else looks good.

Should be all good. Could you run checks again?

Excellent. Thanks to @AlexV525 and @2ZeroSix for the migration. I'll take another pass at it, and see if I can improve the APIs before making a release.

@AlexV525 thanks for pushing it forward!
Unfortunately I had much less time to finish PR myself than I expected :disappointed:

@AlexV525 thanks for pushing it forward!
Unfortunately I had much less time to finish PR myself than I expected 😞

Remember to update the AUTHORS since you make the first part worked! 👍


Enable Event Processor Host live tests on Azure

Enables running Event Processor Host tests during our nightly build.
RealEventHubTestUtilities uses TestUtilities to fetch common environment variables.
TestBase uses slf4j for logging since we have a test dependency on slf4j-simple so we don't need check for console.

Question
@JonathanGiles I noticed is that some of the tests take a long time. (ie. SmokeTests took 33 minutes to run on my machine.) Should I disable them for now to investigate how to make them more performant?

In terms of slow tests - if there are many of them, then yes, I would ignore them and file a bug to follow-up. If there are only a few, I would just leave them and file a bug to follow-up.

Can one of the admins verify this patch?


Update README to include db folder

The current README does not specify what the db folder does.

fixed in: 2681e6cfbec09206c99cb4a68dd33744e631af49


✨ [REQUEST] Sonarr develop

Checked

[X] If a new addon, I have checked on  Google that such as addon doesn't already exists
[X] If a new feature, I have searched in the discussions & issues that it was not already covered

Which addon?
The development branch of sonarr. Tag :develop on linuxserver.io
Is your feature request related to a problem? Please describe
The already existing sonarr addon is the version from 19/03/2023. With version 4 several improvements were added. Those changes help a lot with non english and english content mixed in one database.
Describe the solution you'd like
Additional to the sonarr_nas addon there coud be an sonarr_nas_develop oder sonarr_nas_v4 addon.
Maybe others are interested in this too. Thanks!

Hi, I prefer not to duplicate add-ons but can switch the whole add-on. Is the switch a straightforward one, will it lead to data loss for users? Thanks!

this would be outstanding!

Hi, I prefer not to duplicate add-ons but can switch the whole add-on. Is the switch a straightforward one, will it lead to data loss for users? Thanks!

https://forums.sonarr.tv/t/sonarr-v4-beta/31078
we recommend creating a backup of Sonarr v3 and keeping it in a safe location to ensure everything is working as you will not be able to downgrade to v3 without using a backup from v3 or starting with a new DB. Sonarr v4 will automatically upgrade the database from v3 to v4 when it’s run for the first time.

I can make a test version and you tell me how it goes :)

I can make a test version and you tell me how it goes :)
no problem, and thank you

I've just pushed a test version it should finish building in a couple minutes

Please don't switch v3 to a beta v4.

Why? I've put a message in the changelog saying not to update so if it goes wrong we can still revert the add-on to v3

@derailius if you install the test version I'll revert to v3 if the rest of the community prefers. But then you'll be stuck on v4 unless restoring a backup. Just people let me know if we should keep v3 or move to v4 if it works

ok, thank you @alexbelgium

V4 is still beta and has unfixed issues. Also you cant ask one person to test it for every one

Well honestly I'm not using it so I don't really care if it's v3 or v4 so just let me know on which base I should put the add-on ;) I've reverted the add-on so there is no one updating without meaning to and getting stuck on a v4 database

the best option would be to just have a duplicate add-on, but i can see where this would be bothersome. anyway, thank you for your efforts @alexbelgium I truly appreciate you.


Add coverage to estimateDiversity

The  coverage index is a type of diversity index. Sometimes used in ecological literature and sketched in microbiome pkg. This could be incorporated as an additional option in estimateDiversity function?

Can you author a PR?

Me or @tvborm can do it as the time allows.

It is now added
https://github.com/FelixErnst/mia/pull/71

Have you added unit tests as well @tvborm ?


WebSocket connection closed: connection was closed uncleanly ("peer dropped the TCP connection without previous WebSocket closing handshake"), code: 1006, clean: False, reason: connection was closed uncleanly ("peer dropped the TCP connection without previous WebSocket closing handshake")

Before submitting a new issue, please check if a similar issue has already been filed.
Issue subject
Briefly describe the issue here.
Expected behaviour
Describe what should happen.
Actual behaviour
Describe what happens instead. Please include the complete failure message.
Steps to reproduce
Provide steps to let us know how we can reproduce this issue.
Environment
Provide any relevant information about your setup, such as:

Version of binance-connector-python
Python version
Operating system

Please provide more details, it can be better if you provide a script that can reproduce the issue.

Please open a new issue if the problem is still happening on the latest version.


Configuration envoy.overload_actions.shrink_heap is not working

Title: Configuration envoy.overload_actions.shrink_heap is not working
Description:
We use envoy v1.26.4. We deploy it on the Kubernetes. We tried to configure overload_manager but I can see that envoy.overload_actions.shrink_heap doesn't work. Envoy heap is growing but not released. We have max_heap_size_bytes = 40 Mb but it grows even up to 44 Mb and not shrinked back. Probably my configuration is not correct?
Repro steps:

envoy v1.26.4
send many requests through envoy so that the memory grows up

Admin and Stats Output:
Output of /memory after the load test:
{
 "allocated": "11643744",
 "heap_size": "46137344",
 "pageheap_unmapped": "6782976",
 "pageheap_free": "8192",
 "total_thread_cache": "18394288",
 "total_physical_bytes": "44147406"
}

Config:
Set set the following properties in /envoy/config/envoy.yaml
overload_manager:
  refresh_interval: 0.25s
  resource_monitors:
    - name: "envoy.resource_monitors.fixed_heap"
      typed_config:
        '@type': type.googleapis.com/envoy.extensions.resource_monitors.fixed_heap.v3.FixedHeapConfig
        max_heap_size_bytes: 41943040
  actions:
    - name: "envoy.overload_actions.disable_http_keepalive"
      triggers:
      - name: "envoy.resource_monitors.fixed_heap"
        threshold:
          value: 0.92
    - name: "envoy.overload_actions.stop_accepting_requests"
      triggers:
      - name: "envoy.resource_monitors.fixed_heap"
        threshold:
          value: 0.95
    - name: "envoy.overload_actions.stop_accepting_connections"
      triggers:
      - name: "envoy.resource_monitors.fixed_heap"
        threshold:
          value: 0.98
    - name: "envoy.overload_actions.shrink_heap"
      triggers:
      - name: "envoy.resource_monitors.fixed_heap"
        threshold:
          value: 0.85

Logs:
No errors in envoy logs

From:
 "total_physical_bytes": "44147406"

You're using at least 44MB for the deployment of physical memory. The shrink heap action will try to free memory if TCMalloc can release it; I suspect TCMalloc cannot as its not in a releasable form
For more context / background see:
https://github.com/google/tcmalloc
https://github.com/envoyproxy/envoy/issues/21923


Remove duplicate normalizeColor calls

In the non-JSON case, there is no need to call normalizeColor: toSvgColor already calls normalizeColor internally.

Messages

:book:
:sparkles: Thanks for your contribution to Shields, @PyvesB!

  Generated by :no_entry_sign: dangerJS against d77cb3818e24ece6e66d2525183285f88eabdeb7


Fix ddpg and td3

Close #117

This modification didn't improve the performances.
Delete unnecessary multiplications

I found that that multiplication was for scaling actions to action limit.
https://github.com/openai/spinningup/blob/master/spinup/algos/pytorch/ddpg/core.py#L32-L33

Interestingly, TD3 was able to solve the easy task, Pendulum-v1.

https://user-images.githubusercontent.com/34284486/184656225-f84391b3-6096-437c-99cc-cb2dbbe9aecc.mp4

I found that about gym env version, in SpiningUp they used v3, so I will try to run with v3. I used v4.

Oh, overestimation bias occurs here


[refactor](group commit) remove future block

Proposed changes
Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall

run buildall

run buildall

run buildall

run buildall

run buildall

run buildall


GoLang: 8.1 DOC Concurrency - Introduction

Description 📜
Introduction to Concurrency
with some description about:

Goroutines
Channels
Buffered Channels
Range and Close
Select
Default Selection
sync.Mutex

Note for contributor:
The points mentioned above, will be covered in separate PRs, & will be picked by other contributors.

References:

golangbot
Geeks for Geeks
FMI

Domain of Contribution 📊

[x] Golang

Instructions ✔

Kindly make a README.md for this issue.
Changes should be made under the Golang branch only and push your PR to the same.
This issue is for GWOC'21 contributors only.
You need to push in a single commit. If there exists more than one commit then you need to squash your commits into one commit.

/assign


Child class does not inherit parent scopes

If I have
class Product
  actable
  scope :no_users, -> { where(user_id: nil) }
end

and
class Pen
  acts_as :product
end

I can't seem to use Pen.no_users - it throws error: undefined method 'no_users' for Pen

+1
Not only does Pen.no_users not work but if you copy scope to child - the query generated assumes the field is on the child instead of parent.
I tried using the created_at attribute for my test where Product has the value but Pen inherits it.

Fixed in v2.2.0


Include SuperJSON tRPC transformer

Big fan of the SuperJSON tRPC transformer, lets you send/receive p much anything from tRPC
I can file a PR next week maybe but happy to take a look at it if someone else takes it 👀
https://trpc.io/docs/data-transformers#using-superjson

I'll try to do this. If I get stuck please help me lol.

Resolved. Please check this commit: 1c278b5c8e2a19980f516e87874ea63bc058c43a.
Is this correct?

Looks perfect to me!


Added find & replace in files

This PR adds a way to globally search text files in the project, and replace all occurences of a given text. It's very useful for navigating script name occurences or refactoring.
Should fix https://github.com/godotengine/godot/issues/16336.
Partially fixes https://github.com/godotengine/godot/issues/6217 (quite ambitious though)
Related to https://github.com/godotengine/godot/issues/2592 but doesn't fix its specific case.
When editing a text-based script, use Ctrl+Shift+F to open it (or use the menu), which is pretty standard for this action.
(I had to change the default shortcut for "goto function" to Ctrl+Alt+F).
A window will open:

If you had selected text, it will be copied in the search field.
In addition, the search field will be given focus. If you press enter just after that, it will trigger the search (so you can do it without touching the mouse).
If you press Replace..., the search will happen the same way, but you will be given the ability to enter which text to use for replacement.
Search results are shown in the bottom dock, which opens automatically when a search begins.
If the search takes long, a progress bar can be seen, but you can still interact with the editor during the search.

Clicking a result will jump to the file and select the occurence (this should not conflict with the local file search).
Using Replace all will work on the files directly, and cannot be undone at the moment. Files that are open already will be reloaded using the same logic as external modifications do.
Scripts embedded in scenes and resources are problematic for this tool because unless tscn and tres files get included in the filter, it would require to preemptively load every single scene and resource of the project in case it has builtin scripts (which would slow down and complexify the logic due to varying data formats).
This implementation is almost completely separate from the existing Search & Replace, because it works quite differently and on a larger scope.
Some features are not yet supported (such as looking only for opened files, using a thread, highlighting occurrences in the results...) but can be added later.
Known bug:
Sometimes, the top of the results panel cannot be resized, I have no idea why.

very tolerant and nice commnuity imo. run by great leadership skills, you should be proud juan and akien for leading this great floss project!

Added copyright header

Is this in 3.0.2? When I hit Ctrl+Shift+F this is the window that appears

It's not in 3.0.2 yet, this is a PR which adds it for an upcoming version.


⚠ Bofrost.at has degraded performance

In 7b3ee64, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 2274 ms

Resolved: Bofrost.at performance has improved in 750984a after 40 minutes.


*** Initial directory 'null' couldn't be found. *** on Linux

Appears to be the same as #310.
I am using 0.57.1
Occurs with both zsh and fish.
Initial directory is correctly set in extraterm.json
The window does open in the correct initial directory.

Can you attach or paste the contents of ~/.config/extraterm/extraterm.json here?

Attached.

Attached
extraterm.json.gz

Thanks. I can reproduce the problem here.

Dupe of #318

Fixed in v0.58.0.


Button state not automatically updated in Home

If the button state gets changed from another device or an automation, the button state doesn't get updated in Apple Home without reloading that page. Once I switch pages and come back the button state is correct, but it seems there is no "push" of the button's status to Homekit once it's changed.

Nice catch! Yes, there is no push yet. I would need to add a polling time to the input and run the status check command to see if it changes.

Sounds like a plan :-D

Quick question if you don't mind me asking, how did you configure the plugin? Did you use the sample from the ReadMe or use the GUI to configure it?

Sure, no problem at all! I used the GUI to configure it.

The reason I ask is because I was running into this issue trying to configure via GUI myself! https://github.com/oznu/homebridge-config-ui-x/issues/1448
Was it version v1.0.1 or v1.0.2?

It's version v1.0.22.

Oh, are you using the homebridge-plugin-command-dev? I would recommend switching over to homebridge-plugin-command now. That was for testing these changes before I published to the main package :)

Ah sure, no problem! Don't remember how I came to install homebridge-plugin-command-dev. Is that for internal tests?

It was for me to iteratively test it on my homebridge since I could not develop on the device haha.

Ah!! It came up while searching for plugins in Homebridge. Was wondering about the dev lol.

Was testing it now with 2 computers and a phone, pressing the switches on the phone. One one computer it switches along. On the other one it doesn't; there I need to refresh. Situation (P = iPhone, M=MBP, D=Desktop):

Press buttons on phone, desktop switches but MBP doesn't.
Press buttons on desktop: phone switches but MBP doesn't.
Press buttons on MBP: desktop and phone switches.

Any idea how this can be? I tried quitting and restarting Home on the MBP but to no avail.

Yeah, I can reproduce that myself. My iPad, which is configured as a home hub, switches perfectly every single time, but my phone and laptop need a refresh to see the change.
Since I can reproduce this issue with my TP-Link smart home switch, this is not isolated to just this plugin. Weird, maybe try asking in the home bridge GitHub/reddit?

Okay, yes. My Mac does not switch for this plugin when triggered by the phone, but TP-Link does. Let me look into this a bit further. But, the poll issue still stands.

Ok, I don't have TP Link but I don't recall seeing this behavior with my Philips Hue... Thanks for looking into it 🙏


Ngram tokenizer now returns an error with invalid arguments.

Fixes #2100

Codecov Report

Merging #2102 (d73706d) into main (3b0cbf8) will decrease coverage by 0.02%.
The diff coverage is 98.30%.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
@@            Coverage Diff             @@
##             main    #2102      +/-   ##
==========================================
- Coverage   94.39%   94.37%   -0.02%
==========================================
  Files         321      321
  Lines       60612    60646      +34
==========================================
+ Hits        57213    57236      +23
- Misses       3399     3410      +11

Impacted Files
Coverage Δ

src/core/segment_reader.rs
90.57% <0.00%> (ø)

src/lib.rs
99.05% <ø> (ø)

src/directory/ram_directory.rs
90.50% <100.00%> (ø)

src/indexer/segment_updater.rs
94.27% <100.00%> (-1.18%)
:arrow_down:

src/postings/serializer.rs
98.95% <100.00%> (ø)

src/snippet/mod.rs
95.44% <100.00%> (ø)

src/tokenizer/ngram_tokenizer.rs
99.06% <100.00%> (+0.11%)
:arrow_up:

... and 2 files with indirect coverage changes


[BUG] Used VPN and deactivated it, this happened

Acknowledgement of preliminary instructions

[X] I have read the preliminary instructions, and I am certain that my problem has not already been addressed.
[X] I have thoroughly looked through the available Wiki articles and could not find a solution to my problem.
[X] I am using the latest version of Bloxstrap.
[ ] I did not answer truthfully to all the above checkboxes.

What problem did you encounter?
I was testing a vpn to use for roblox (I live in Malaysia as of now) and i set it to America (Accidentally). After i saw the login screen when i opened roblox again, i turned it off and opened roblox again. I logged in, closed it, and tried to open it from the bloxstrap shortcut, but then this error showed up.

Bloxstrap Log
Bloxstrap_20240929T070246Z.log

Update.
If you want multi instance, use Roblox account manager, no it's not a virus it's safe, yes it's a false positive.
If you don't want to use anything else but bloxstrap we won't help you, nor the devs will.

No, that’s not what happened, and no, I am using bloxstrap. I just
activated and deactivated a vpn.
On Sun, 29 Sep 2024 at 3:09 PM, nabber @.***> wrote:

Update.
If you want multi instance, use Roblox account manager, no it's not a
virus it's safe, yes it's a false positive.
If you don't want to use anything else but bloxstrap we won't help you,
nor the devs will.
—
Reply to this email directly, view it on GitHub
https://github.com/pizzaboxer/bloxstrap/issues/2998#issuecomment-2381139841,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BKPBTSHUYMPHUQNCQLEEAT3ZY6RSLAVCNFSM6AAAAABPBK6FWKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOBRGEZTSOBUGE
.
You are receiving this because you authored the thread.Message ID:
@.***>

No, that’s not what happened, and no, I am using bloxstrap. I just
activated and deactivated a vpn.
You're using an outdated version of Bloxstrap.


Record motions / clips

hi @kopiro
First of all thanks for the wonderful work and making community life easy with your efforts.
I want to record clips or even continuous recording solution, do you have any idea or something I am missing, i even checked in ffmpeg plugin but no working example for recording.

Hello; currently this plugin nor the official https://www.npmjs.com/package/homebridge-camera-ffmpeg package which this plugin is based on support this, sorry


Support workflow versioning

Background
Proposed @opensearch-project/opensearch-ux mockups for the frontend plugin introduces a concept of launches within a single workflow. This allows for easy prototyping for a particular use-case, allowing users to construct and test different workflow configurations, persisting the history and associated resources with each deployment for reference.

The current backend design does not support this paradigm. One approach to support this is introducing versioning to workflows, opening up functionality to iterate on a workflow at the API level to persist and provision multiple versions of a single workflow. Originally discussed in #109, this issue expands on this idea.
Implementation
Currently there is a version field (see here) but it is not being used or validated yet. We can refactor this into being a required field with a String value that users can set to whatever they want. This way, there will always be a default version for a workflow. (If we need to persist compatibility, we can refactor that into a standalone template field)
Internally, workflows with the same ID but different versions can behave identically to the current workflow implementation; users can perform CRUD operations on them, they each persist their own provisioning state, created/associated resources, etc.
To handle defaults at the API level, backend logic can filter through the workflow ID, and if there are multiple instances of that workflow ID under different versions, choose the one with the latest last_update_time or equivalent such field.
API changes
Users need the capability to run CRUD operations on individual versions of a workflow if they want. Users who don't want/care about versioning shouldn't have to, with abstracted out logic and sufficient defaults. Most changes listed below are just adding an additional path to existing APIs that include a version ID.
Create workflow
Users specify a (now mandatory) version field in the template.
POST /_plugins/_flow_framework/workflow
{
   "version": "my-version-1",
   "name": "my-workflow-name",
   ...
}

[NEW] Create new version of a workflow
Same as create, but now include the already-created workflow-id in the path. The JSON body should include a non-name-clashing version with any existing versions for that workflow, else throw an error. See open questions below on what to include in this JSON body.
POST /_plugins/_flow_framework/workflow/<workflow-id>
{
   "version": "my-version-2",
   "name": "my-workflow-name",
   ...
}

Update workflow
Same as before, with a new optional version-id to specify which version of the workflow to update. If no version specified, default to the latest version
PUT /_plugins/_flow_framework/workflow/<workflow-id>
PUT /_plugins/_flow_framework/workflow/<workflow-id>/<version-id>

Get workflow
Same as before, with a new optional version-id to specify which version of the workflow to get. If no version specified, default to the latest version.
GET /_plugins/_flow_framework/workflow/<workflow-id>
GET /_plugins/_flow_framework/workflow/<workflow-id>/<version-id>

Provision workflow
Same as before, with a new optional version-id to specify which version of the workflow to provision. If no version specified, default to the latest version
POST /_plugins/_flow_framework/workflow/<workflow-id>/_provision
POST /_plugins/_flow_framework/workflow/<workflow-id>/<version-id>/_provision

Get workflow state
Same as before, with a new optional version-id to specify which version of the workflow to get state. If no version specified, default to the latest version
GET /_plugins/_flow_framework/workflow/<workflow-id>/_status
GET /_plugins/_flow_framework/workflow/<workflow-id>/<version-id>/_status

Deprovision workflow
Same as before, with a new optional version-id to specify which version of the workflow to deprovision. If no version specified, default to the latest version
POST /_plugins/_flow_framework/workflow/<workflow-id>/_deprovision
POST /_plugins/_flow_framework/workflow/<workflow-id>/<version-id>/_deprovision

Delete workflow
Same as before, with a new optional version-id to specify which version of the workflow to delete. If no version specified, default to all versions
DELETE /_plugins/_flow_framework/workflow/<workflow-id>
DELETE /_plugins/_flow_framework/workflow/<workflow-id>/<version-id>

No changes/updates needed for the Get Workflow Steps or Search Workflow APIs.
Open questions

For "Create new version of a workflow", should the JSON body be a subset of what's created on the initial workflow creation? For example, we probably don't want name / description / use_case overridden by some later version. Fundamentally these fields should be static. Internally maybe we propagate such static fields to the newly-versioned workflow when indexing.
Performance concerns. Most APIs will need added logic to fetch a specific (or all) version(s) of a workflow under a workflow ID.

(ASIDE) Frontend implications
This approach seamlessly fits into the frontend design for handling multiple launches/deployments/versions. Matching up UX action vs. API calls:

Creating new workflow = create workflow API with some default (or user-specified) version
Viewing all workflows = search workflow API and deduping by workflow ID (constructing aggregate query and filtering by latest last_update_time)
Clicking "launch" = provision with current version ID (if first launch), or create new version of a workflow with provision=true flag (if subsequent launch)
Viewing all launches = search workflow API and parsing out all versioned workflows that match the workflow ID
Viewing launch resources = get workflow state API with specified version ID + workflow ID
Prototyping launch = get workflow API with workflow + version ID to prototype with (how to prototype is an open question - new API vs. using search pipelines stored under its resources vs. other)

I appreciate the effort you put into outlining this proposal, and while in principle I support the idea of versioning, I do not think the workflow_id is the right way to do it.
Fundamentally, the workflow_id is the document _id field.  It is guaranteed to be unique for a given index, and maps directly to a single unique document.  You can't have the same document ID with different contents.  The only way to achieve this "sub-versioning" scheme is to maintain a list of templates in the document, or a base template and list of changes to it (basically a diff).
It looks like this "list" idea aligns with your open questions.  I'm not sure performance is going to be that big of a hit.  Building an object and applying a finite number of diffs from it is likely not that hard.... we may want to always keep the "latest" version but keep diffs to earlier versions to "roll back".

Internally, workflows with the same ID but different versions can behave identically to the current workflow implementation; users can perform CRUD operations on them, they each persist their own provisioning state, created/associated resources, etc.

Even if we maintain a list of templates (or a base template + list of diffs), as we've found with maintaining a state index with resources, it's not exactly trivial to edit/append/rollback a single document.  (Deprovisioning just wipes the whole thing and rewrites it.)
I do think there's one possibility here in the fact that we've designed for a "list of workflows".  Currently we only have one such workflow named "provision".  We could keep multiple different "launch" workflows in that section while preserving the metadata (except that also includes a version so we'd have to figure out what to do with that).  But changing that will make it more complex for backend-only users.
From a front-end / UX perspective, I don't see the need for a user to see the actual document ID.  Can't we just use the name + version to do all that you suggest, while keeping the document ID (workflow ID) hidden from the user (mapped to the "Launch ID")?  We have complete/full documents with different IDs, copied from each other, independently CRUD-friendly without overwriting or using painless script shenanigans.  Searching for all workflows matching a given name is easy.

So after thinking about this far too much for a weekend, I'm coming to see the benefit of keeping a list of versioned templates assigned to a single workflow ID.  The main advantage here is the 1-to-1 correlation with provisioned resources.
It'll be a complex issue trying to jump back and forth between versions and trying to figure out which resources to deprovision/provision, but that seems solvable and makes more sense with a single workflow id.

@dbwiddis thanks for the input.
Definitely valid concerns about fitting multiple workflow versions under the workflow ID which is uniquely derived from the doc ID. But the way I view this change is a workflow is now only unique by a combination of the base workflow ID (initially set when the workflow is created) + version ID (set by the user or given some default). Here's some detailed examples of my thinking:
User creates an initial workflow:
POST workflow/
{
   "name": "my-workflow",
   "version": "v1",
   ...
}

|
V
document ID abc123:
{
   "name": "my-workflow",
   "version": "v1",
   "id": "abc123"
}

User creates new version under same workflow ID:
POST workflow/abc123
{
   "version": "v2",
   ...
}

|
V
new document ID def456, but underlying workflow ID still persisted as abc123:
{
   "name": "my-workflow",
   "version": "v2",
   "id": "abc123"
}

My reasoning for proposing maintaining separate docs for each version is to try to keep the document-level granularity paradigm the same; each document contains a unique workflow (via workflow ID + version ID), a standalone template, and a standalone set of resources. This keeps alignment with the existing backend design, and fully aligns with the frontend.
Also agreed this adds some complexity to the provision/deprovision APIs (and all APIs frankly) to route requests to the correct version. I would hope we can have a single piece of shared logic for (1) determining if there are multiple workflow versions, (2) fetching the latest, default version, and (3) fetching a user-specified version. These can be run top-level for each API.

To handle defaults at the API level, backend logic can filter through the workflow ID, and if there are multiple instances of that workflow ID under different versions, choose the one with the latest last_update_time or equivalent such field.

This concept overall sounds good to me, have a few more questions however.
it seems like we are changing the create workflow API to now take a workflowID:
POST /_plugins/_flow_framework/workflow/<workflow-id>
{
   "version": "my-version-2",
   "name": "my-workflow-name",
   ...
}

I assume this isn't a must and only if we want to create a child workflow (a new version of the same one)?

Will we basically have two ways (potentially 3) then to refer to the same document?

For example:
If we create the original workflow and we also assign version as v1. Lets say the document ID assigned is abc1234 Then we have two ways to get this workflow right?
GET /_plugins/_flow_framework/workflow/abc1234
GET /_plugins/_flow_framework/workflow/abc1234/v1

*We still haven't defined if the default for the GET api without the version is the original or the last version (I assume we can decide that later)
Then lets say I create a new version of the workflow do I then do:
POST _plugins/_flow_framework/workflow/abc123
{
   "version": "v2",
   ...
}

then based on your above comment I get this:
{
   "workflowId": "def456"
}

What would these return me then?
GET /_plugins/_flow_framework/workflow/abc1234/v2
GET /_plugins/_flow_framework/workflow/abc1234
GET /_plugins/_flow_framework/workflow/def456

Essentially would "version 2" of abc1234 return me the def456?

Additionally two other minor comments are:
a.  We should have a mechanism where users don't have to care/understand versions if they don't want to, so it's only an extra enhanced feature at least in terms of backend users.
b. I slightly prefer /_plugins/_flow_framework/workflow/<workflow-id>?version=<x> instead of /_plugins/_flow_framework/workflow/<workflow-id>/<version-id>

@dbwiddis

Do the new created resources "live" under the new/current workflow/document ID or the old one, or both? Does the old id even have any record of created resources or do we just remove them all and transfer them to the new one?

A new document. Editing and re-launching wouldn't have any special logic for sharing resources across launches/versions, I feel that could add a lot of unnecessary complications. My proposal is a new launch/version is doing nothing different than how workflows currently work - see previous reply below:

My reasoning for proposing maintaining separate docs for each version is to try to keep the document-level granularity paradigm the same; each document contains a unique workflow (via workflow ID + version ID), a standalone template, and a standalone set of resources. This keeps alignment with the existing backend design, and fully aligns with the frontend.

If they are deleted, how do I do a side-by-side comparison of old and new models?

You couldn't. If a user deprovisions a launch they can't use it for prototyping. We could have some frontend logic for filtering out versions to only make available provisioned launches to test with.

If they are not deleted, then what happens if I "deprovision" one of the two workflows with "shared created resources"; how do I verify the created resource is not in any other workflow's resource?

You can't. Similar to how we aren't tracking created resources after we create them - it isn't feasible for our plugin to try to inject logic in say, delete model API, to route through our plugin to verify if all workflows are still valid. I guess we could add some enhancement logic to check whether some resource ID exists in another document, but that's nothing specific to this versioning proposal.
It's this second bullet that's central to my "list" comment above. I have to search over all workflows to find a matching group/id tag. Compare that to keeping all workflows in the same "group" in a list in a single document. All of the various iterations are right there and we can keep track for created resources with a single read-in of the document and no complex searching and comparing.
If you see a path forward where all workflow versions can be persisted in one document / one workflow ID, I would have no objections to that. This points back to my Open Question 2:

Performance concerns. Most APIs will need added logic to fetch a specific (or all) version(s) of a workflow under a workflow ID.

The frontend requirement is just to have multiple versions/launches fall under a parent ID, with CRUD functionality for each individual version/launch, and persisted resources/template/state for each version/launch.

Note creating a new version should not create a new workflow ID - in my example, the id is still persisted as the original workflow ID. I'm only calling a different doc ID in that this proposed design is saying that each new workflow + version combo is a new document. This all boils back to the idea of changing a unique workflow from just workflow_id to now workflow_id + version.
GET /_plugins/_flow_framework/workflow/abc1234/v2 would succeed, returning version v2 of workflow abc1234 GET /_plugins/_flow_framework/workflow/abc1234 would succeed, returning the default version of workflow abc1234 GET /_plugins/_flow_framework/workflow/def456 would fail, since that is not an existing workflow ID.

Essentially would "version 2" of abc1234 return me the def456?

It would return the unique workflow "version 2" under workflow abc1234. Yes the underlying doc ID is def456, but the idea is this isn't queryable. You would query by searching for a doc where workflow_id = abc1234 for example.

I think I understand better now.
We would have to make additional changes on the GET APIs potentially if we don't want it to be queryable or at least never let the user know of the def456 id.
If a user creates a workflow abc1234 and provisions it. We know have two documents indexed in template index and state index with the docId being abc1234. This makes it easy to get the state back to the user. We essentially do a GET state-index/<doc-id> operations directly on the index.
Now if a user creates a new version under abc1234, v2? would there response back be this?:
{
   "workflowId": "abc1234",
   "version": "v2"
}

now a user never knows of def456. However now when we provision the new workflow, we will need to do a search operation to get the def456 document to get the template to provision and then index it into the state with that def456 id?
when user does any GET operations on state or template index they would either provide abc1234 or abc1234?versionv2 and then the code change would be instead of doing GET state-index/<doc-id> we would need to do
POST state-index/_search
{
  "query": {
    "bool": {
      "must": [
        { "match": { "version": "v1" } },
        { "match": { "id": "abc123" } }
      ]
    }
  }
}

Adding a versionId to the APIs would require us to change all the APIs. Instead, I believe the grouping can be treated as an additional feature rather than changing our current setup. I understand that this feature is requested from the frontend to group workflows of the same type together for easy listing. To address this request on the backend, we can use a workflow_group field in the template, an alternative to the discussed versionId.
Since most of the discussion on this issue revolves around the versionId, I'll present an alternative solution using the workflow_group field to meet the frontend requirement.
For each workflow template, we can introduce a new field called workflow_group:
POST /_plugins/_flow_framework/workflow
{
   "workflow_group": "group-1",
   "name": "my-workflow-name-1",
   ...
}

When creating a new workflow, instead of linking both workflows together, we will assign the same group:
POST /_plugins/_flow_framework/workflow
{
   "workflow_group": "group-1",
   "name": "my-workflow-name-2",
   ...
}

This approach maintains a 1:1 mapping between the workflowID and existing resources, requiring no changes to the existing APIs.
To list the workflows together, we can introduce a new GET API:
GET /_plugins/_flow_framework/workflow_group/<workflow_group_id>

This API would list the workflows together, and we can also retrieve details about the resources created for each workflow through the status API.

@owaiskazi19 my concern with introducing a workflow group concept is it creates a large gap between backend APIs and the frontend. The frontend requirement is to have a single ID with multiple workflows / workflow versions / etc. under a single workflow ID. If we went with this approach, we would have to map frontend workflow -> backend workflow group, which would cause user confusion and messy frontend logic. Even with frontend tricks to "hide" the workflow group concept & have defaults, it is not a clean full-stack design.

The frontend requirement is to have a single ID with multiple workflows / workflow versions / etc. under a single workflow ID. If we went with this approach, we would have to map frontend workflow -> backend workflow group, which would cause user confusion and messy frontend logic.

Which is why we would group multiple workflows under the same umbrella. Why would it cause confusion to the user? This issue mostly address the communication between frontend and the backend of flow framework. A frontend workflowId would be mapped to backend workflowId. Only when frontend wants to talk to multiple workflows at the same time, workflow group would come into the picture.

Even with frontend tricks to "hide" the workflow group concept & have defaults, it is not a clean full-stack design.

From
_doc/def456
{
   "name": "my-workflow",
   "version": "v2",
   "id": "abc123"
}

Introducing a versionID with all the APIs and then appending the docId of the 1st workflow in the document of the new workflow looks more confusing if the user just uses the our backend plugin. We need to address both types of users:
One who will use our frontend and the other who will just use backend.

Only when frontend wants to talk to multiple workflows at the same time, workflow group would come into the picture.

This would be required by default. All of the workflow editing / set of launches / set of individual resources / prototyping falls under a single workflow with a single ID. The workflow list page, the workflow details pages (including the ID in the url) would all now be hidden under a workflow group ID instead. This introduces two differences between the frontend and backend:
Frontend "workflow" -> backend "workflow group"
Frontend "workflow launch" -> backend "workflow"
This is where the confusion happens when there is a large disconnect between what the frontend is portraying, and what all of our documentation / APIs / backend is doing.

Introducing a versionID with all the APIs and then appending the docId of the 1st workflow in the document of the new workflow looks more confusing if the user just uses the backend plugin.

How so? From an interface level, there is no difference to the user. This is just a low-level implementation detail/example on how we may persist multiple versions of a single workflow. Users would not be querying against raw doc IDs - they only care about workflow IDs and version IDs. Again, this is just one approach, perhaps appending documents within a single workflow ID as @dbwiddis has mentioned is more streamlined.

This is where the confusion happens when there is a large disconnect between what the frontend is portraying. For example, a user sees there is 3 "workflows" from the workflow list page. So a user may think they have 3 workflows, and then query using our search workflow API, and see there are 30.

Won't we list all the workflows present in all the workflow groups here? Still trying to understand the gap which is being called out.
For example: There will be 10 workflows in a workflow group. Similarly, we can have 2 more workflow groups with same number of workflows. On the workflow list page, we can list all the workflows together by combing the workflows of the groups.
We can have the below API
GET /_plugins/_flow_framework/workflow_group/_all

How so? From an interface level, there is no difference to the user.

Yes, from the interface level it would look the same. I am talking about in terms of design level. I feel like keeping same type of workflows in the group looks cleaner and this way every workflow would be different and can act as one single entity without any dependency.

Won't we list all the workflows present in all the workflow groups here? Still trying to understand the gap which is being called out.

No, because the frontend design is a single workflow which may contain x number individual launches/versions within it, and there is no concept of workflow groups. The workflow list, for example, would list out all workflows.
Again, even if we do frontend tricks to abstract / hide things (mapping frontend "workflow" to backend "workflow group"), this misalignment leads to the confusion and mismatch between frontend and rest of documentation/apis/backend.

I feel like keeping same type of workflows in the group looks cleaner and this way every workflow would be different and can act as one single entity without any dependency.

Somewhat agreed and this is a fair point, although imo it also adds complexity and more terminology users need to learn. By just supporting versioning, there is less user-facing changes and doesn't introduce any new APIs besides one to create a new version with an existing workflow. There's definitely pros and cons to each.
But, unfortunately the workflow grouping idea this has gotten a lot of pushback from product and UX side and isn't desirable from customer-side, hence we need to find a middleground to provide a clean experience full-stack for users.

No, because the frontend design is a single workflow which may contain x number individual launches/versions within it, and there is no concept of workflow groups. The workflow list, for example, would list out all workflows.

Which is fine. It's totally upto frontend to decide how it want to have different terminology for different APIs/fields. Other external frontend using our backend plugin could call workflow as flow or code or anything else.

But, unfortunately the workflow grouping idea this has gotten a lot of pushback from product and UX side and isn't desirable from customer-side, hence we need to find a middleground to provide a clean experience full-stack for users.

Need to understand more of the gaps and pushbacks here.
The reason I am pushing on grouping is to keep all the workflows separate and reduce dependency. With versioning we might have to track versions of the template later for fine-gained-provisioning and it will introduce some complications on the backend side.

Which is fine. It's totally upto frontend to decide how it want to have different terminology for different APIs/fields. Other external frontend using our backend plugin could call workflow as flow or code or anything else.

Very minor name changes may be acceptable, but UX will not allow this much of terminology changes. This particular name change adds a lot of user-facing confusion, in that a frontend "workflow" would correspond to a backend "workflow group". We need to have consistency on this piece. Pointing back to the example of the frontend workflow list page would mean something entirely different than what's returned from our search workflow APIs.

Need to understand more of the gaps and pushbacks here.

The pushback is this is the proposed UX that has gone through months of review with customers and product. We need to support this on the backend, which is a single workflow and x versions/launches related to it.

The reason I am pushing on grouping is to keep all the workflows separate and reduce dependency. With versioning we might have to track versions of the template later for fine-gained-provisioning and it will introduce some complications on the backend side.

Fine-grained provisioning and any other workflow-related features should not be impacted, could you help explain? This proposed change is keeping document-level granularity the same for each unique workflow. The only difference is a unique workflow is now determined by the workflow ID AND version, but all other functionality remains the same. If users want to provision/deprovision/fine-grained provisioning, the APIs would remain the same. They either only specify workflow ID (defaulting to some version), or specify workflow ID + version ID. Backend just needs initial routing logic at the API entry points, but other than that, there would be no complications I foresee.

From further discussion with @owaiskazi19 and @dbwiddis, we can take the following approach, a combination of proposals from above. We can introduce a new concept of workflow groups on the backend, used as an internal way for persisting associated workflows differing only by versions, without exposing/changing the proposed APIs/interfaces described above. User-facing (both frontend and APIs), everything will remain as workflow IDs. Internally, these will be stored as workflow group IDs.

unique workflows will be specified by a workflow ID & version ID, users may specify the IDs or defaults will be automatically generated (the workflow ID will be stored as a workflow group ID internally in the backend)
a new workflow group system index. Within it, will persist doc IDs of all unique workflows with the same workflow ID (a list of unique workflow-group-id/version-id combinations). This can be used for routing API requests to find available version(s) of a workflow

List out some user examples below:
Scenario 1: user creates a new workflow
POST /_plugins/_flow_framework/workflow/
{
   "name": "my-workflow",
   "version": "v1",
  ...
}

|
V
`.plugins-flow-framework-workflows` index

_doc/abc123
{
"name": "my-workflow",
...
}
`.flow-framework-workflow-groups/` system index

_doc/workflow-1-group-id
{
"versions": {
"version": "v1",
"docId": "abc123",
}
}

My original proposal was just using the first generated doc ID as the "workflow group ID" - here, the idea is to have a separately generated ID entirely.

I think this minor change actually helps us all align here.

the main difference is really naming

Naming things is hard!  I'm happy with whatever name we use and I think we've addressed the issue of shared resources so I'm GTG with this concept.

These both closely resemble the original proposal

I wouldn't say I am completely aligned here but looking at the discussion on this thread, this looks like a better approach for majority of us. Keeping the docId of the group index as workflowId rather the docId of the first workflow created looks cleaner.

My original proposal was just using the first generated doc ID as the "workflow group ID" - here, the idea is to have a separately generated ID entirely.

But the first generated doc ID is the original workflow, isn't a group. A group by idea wouldn't be provisioned

@owaiskazi19

Keeping the docId of the group index as workflowId rather the docId of the first workflow created looks cleaner.

We can do that, and/or allow the user to specify it. Definitely several different options for where/how to get this ID.
@amitgalitz

Also I don't know if I fully get the benefit of having another system index, instead of just keeping the same indices with separate documents for everything, the less we have to update a document that is already existing I think the better.

Yeah, pros/cons to each. Personally no strong opinion on this part. Listed out more alternatives as well, it can be boiled down to just query DSL at the REST layer to achieve the same thing.

@dbwiddis @owaiskazi19 do you both prefer having an additional system index plus having to do updates on a single document multiple times over changing internal search to something like:
POST <state-index or template-index>/_search
{
  "query": {
    "bool": {
      "must": [
        { "match": { "version": "v2" } },
        { "match": { "id": "abc123" } }
      ]
    }
  }
}

do you both prefer having an additional system index

Does having a system index give us a "source of truth" that makes things easier than searching?  Or does it introduce more complexity of updates?  Search should be just as fast, probably?  Adding an index smells of premature optimization.
I'd lean toward implementing right now with search.  We can always "make it more efficient later" if needed (which it may not be).


doc: Add some information about build dependencies

I'm a rookie

I took a look at the content of snapcraft.yaml, but I'm not sure if there's an infographic for building dependencies

graph-build-dependencies

digraph{
    "microk8s"->{containerd, dqlite, "k8s-binaries"}
    runc->iptables
    containerd->{iptables, runc}
    iptables->libnftnl->libmnl
    "k8s-binaries"->dqlite
    "dqlite-client"->{sqlite, dqlite}
    dqlite->{raft,sqlite}

}

This seems to be unnecessary


Metadata: parse new names

Implements parsing new tags

PackageName  || Title
PackagerName || PackagedBy
Icon         || PackageIcon
Url          || Links

See https://github.com/sailfishos-chum/main/issues/100
As the implementor I have taken the liberty of supporting PackagedBy as well, because I like it.

Thank you very much, LGTM

@nephros, unfortunately this change fails to compile:
chum-gui-0.6.0_compiling-fails.txt
Can you please take a look at it.

Damn, missing closing bracket.

… which I failed to see (despite being trivial) due to being overly tired when I detected that building fails.

Sorry about that.

Never mind.  It uncovered another issues: The CI runs at GitHub show success, even though compiling fails!  I have to improve the workflow definition(s).

Fixes coming up!

Thank you for PR #185.  Merged and compiling, as expected.


[utils] add logic for serializing Move value with both type and field…

… names
This is useful for viewing Move values as tree-structured data in formats that are likely to be consumed by clients (e.g., json).

@tzakian for re-stamp plz!

/land