Fail installation of dependencies with File::Find

Problem or new feature
Using 2020.08.2, the dependency File::Find fails with:
[File::Find] ===SORRY!=== Error while compiling /home/jmerelo/.zef/store/File-Find.git/075720bde467460892fd3e326e139a9a926cbc8a/t/01-file-find.t
[File::Find] Could not find File::Find in:
[File::Find]     file#/home/jmerelo/.zef/store/File-Find.git/075720bde467460892fd3e326e139a9a926cbc8a
[File::Find]     inst#/home/jmerelo/.raku
[File::Find]     inst#/home/jmerelo/.rakudobrew/moar-2020.08.2/install/share/perl6/site
[File::Find]     inst#/home/jmerelo/.rakudobrew/moar-2020.08.2/install/share/perl6/vendor
[File::Find]     inst#/home/jmerelo/.rakudobrew/moar-2020.08.2/install/share/perl6/core
[File::Find]     ap#
[File::Find]     nqp#
[File::Find]     perl5#
[File::Find] at /home/jmerelo/.zef/store/File-Find.git/075720bde467460892fd3e326e139a9a926cbc8a/t/01-file-find.t:3
===> Testing [FAIL]: File::Find:ver<0.1>
Aborting due to test failure: File::Find:ver<0.1> (use --force-test to override)

Suggestions
It's relatively safe, probably, to remove this dependency, since it's only used in Build.pm6, affected by #3002. But it  might be safer to try and fix installation of that dependency.

Workaround installing it from source, opened issue there.

https://github.com/tadzik/File-Find/issues/32


'path_display' telescope opt doesn't work properly with the file-browser

Description

Neovim version
NVIM v0.8.0-dev-1000-gc0050b71e
Build type: Release
LuaJIT 2.1.0-beta3
Compiled by inferno@InfernoPC

Features: +acl +iconv +tui
See ":help feature-compile"

   system vimrc file: "$VIM/sysinit.vim"
  fall-back for $VIM: "/usr/local/share/nvim"

Operating system and version
Artix Linux
Steps to reproduce
nvim -u minimal_conf.lua
Expected behavior
To have only one slash at the end "/"
Actual behavior
Instead it has two slashes at the end "//"
Minimal config
vim.cmd [[set runtimepath=$VIMRUNTIME]]
vim.cmd [[set packpath=/tmp/nvim/site]]
local package_root = '/tmp/nvim/site/pack'
local install_path = package_root .. '/packer/start/packer.nvim'
local function load_plugins()
  require('packer').startup {
    {
      'wbthomason/packer.nvim',
      {
        'nvim-telescope/telescope.nvim',
        requires = {
          'nvim-lua/plenary.nvim',
          'nvim-telescope/telescope-file-browser.nvim',
        },
      },
      -- ADD PLUGINS THAT ARE _NECESSARY_ FOR REPRODUCING THE ISSUE
    },
    config = {
      package_root = package_root,
      compile_path = install_path .. '/plugin/packer_compiled.lua',
      display = { non_interactive = true },
    },
  }
end
local layout = require('telescope.actions.layout')
local previewers = require("telescope.previewers")
local sorters = require("telescope.sorters")
_G.load_config = function()
  require('telescope').setup({
	defaults = {
		vimgrep_arguments = {
			"rg",
			"--color=never",
			"--no-heading",
			"--with-filename",
			"--line-number",
			"--column",
			"--smart-case",
		},
		prompt_prefix = ":: ",
		selection_caret = "> ",
		entry_prefix = "  ",
		initial_mode = "insert",
		selection_strategy = "reset",
		sorting_strategy = "descending",
		layout_strategy = "horizontal",
		layout_config = {
			horizontal = {
				mirror = false,
				height = 20,
			},
			vertical = {
				mirror = false,
				width = 0.5
			},
		},
		file_sorter = sorters.get_fuzzy_file,
		file_ignore_patterns = {},
		generic_sorter = sorters.get_generic_fuzzy_sorter,
		winblend = 10,
		border = {},
		borderchars = { "─", "│", "─", "│", "╭", "╮", "╯", "╰" },
		color_devicons = true,
		use_less = true,
		path_display = { "smart" },
		-- set_env = { ['COLORTERM'] = 'truecolor' }, -- default = nil,
		file_previewer = previewers.vim_buffer_cat.new,
		grep_previewer = previewers.vim_buffer_vimgrep.new,
		qflist_previewer = previewers.vim_buffer_qflist.new,
		mappings = {
			i = {
				["<C-]>"] = layout.toggle_preview,
				-- ["<C-]>"] = layout.cycle_layout_next,
			},
		}

		-- Developer configurations: Not meant for general override
		-- buffer_previewer_maker = require'telescope.previewers'.buffer_previewer_maker
	},
	extensions = {
		file_browser = {
			hijack_netrw = true,
		},
		fzf = {
			fuzzy = true, -- false will only do exact matching
			override_generic_sorter = true, -- override the generic sorter
			override_file_sorter = true, -- override the file sorter
			case_mode = "smart_case", -- or "ignore_case" or "respect_case"
			-- the default case_mode is "smart_case"
		},
	},
	["ui-select"] = {
		require("telescope.themes").get_dropdown({
			-- even more opts
		}),
	},
	pickers = {
		find_files = {
			find_command = {
				"fd",
				"--type",
				"f",
				"--strip-cwd-prefix",
				"-E",
				"*cache*"
			},
		},
	},
})
  require('telescope').load_extension('file_browser')
  -- ADD INIT.LUA SETTINGS THAT ARE _NECESSARY_ FOR REPRODUCING THE ISSUE
end
if vim.fn.isdirectory(install_path) == 0 then
  print("Installing Telescope and dependencies.")
  vim.fn.system { 'git', 'clone', '--depth=1', 'https://github.com/wbthomason/packer.nvim', install_path }
end
load_plugins()
require('packer').sync()
vim.cmd [[autocmd User PackerComplete ++once echo "Ready!" | lua load_config()]]

Does it happen with a true minimal config?
My best guess is to try commenting out
		path_display = { "smart" },

and see whether it works then.

Yes , that was it ! Should i leave this issue open , since i don't think it's an intended behavior of the path_display = { "smart" } ?

Yes , that was it ! Should i leave this issue open , since i don't think it's an intended behavior of the path_display = { "smart" } ?

path_display = { "tail" }
is also broken , and the others I tried also have some strange behaviors.
I noticed that the buildin pickers of telescope follow the path_display as expected but file-browser seems to have a hard time with them.

I also just had this same thing happen.  It works on my other PC but when I pulled it to this one from git I started getting double slashes at the end of folders as well.

Am also facing the same issue with "smart" path_display option in telescope;


Add Missing Translations Files

This patch adds some translation files which were never initially added
to Opencast 9.x but which should have been.
This fixes #2945
Your pull request should…

[x] have a concise title
[x] close an accompanying issue if one exists
[x] be against the correct branch
[x] include migration scripts and documentation, if appropriate
[x] pass automated tests
[x] have a clean commit history
[x] have proper commit messages (title and body) for all commits

Just confirmed that these are the exact same files missing in 10.x
No additional pull request necessary.


reduce_sum support for int4, int2 and uint4, uint2

In this PR, I propose a solution regarding summation of low-bit arrays using integer promotion. Basically, we can already perform the sum of int8 and uint8 dtypes since these are already numpy native. However, we cannot do the same with lower precisions, simple because np.iinfo does not recognize them. Formally, in the reductions.py file, we use the _promote_integer_dtype function to figure the dtype conversion target, e.g. int8 goes to int32 while int64 remains int64. I propose to add special cases for very low bit-widths as follows
def _promote_integer_dtype(dtype: DTypeLike) -> DTypeLike:
  # Note: NumPy always promotes to 64-bit; jax instead promotes to the
  # default dtype as defined by dtypes.int_ or dtypes.uint.
  if dtypes.issubdtype(dtype, np.bool_):
    return dtypes.int_
  elif dtypes.issubdtype(dtype, np.unsignedinteger):
    if dtype in [np.dtype('uint4'), np.dtype('uint2')]: # <---- changes here
      return dtypes.uint
    if np.iinfo(dtype).bits < np.iinfo(dtypes.uint).bits:
      return dtypes.uint
  elif dtypes.issubdtype(dtype, np.integer):
    if dtype in [np.dtype('int4'), np.dtype('int2')]: # <---- and here
      return dtypes.int_
    if np.iinfo(dtype).bits < np.iinfo(dtypes.int_).bits:
      return dtypes.int_
  return dtype

To test the change, you can run the following before and after making the change:
import jax
import jax.numpy as jnp

print("sum int8")
sum_jit = jax.jit(jnp.sum)
sum_jit(
    jax.random.randint(
        key=jax.random.PRNGKey(0),
        shape=(10, 10),
        minval=0,
        maxval=16,
        dtype=jnp.int8,
    ),
)
print("sum int4")
sum_jit(
    jax.random.randint(
        key=jax.random.PRNGKey(0),
        shape=(10, 10),
        minval=0,
        maxval=16,
        dtype=jnp.int8,
    ).astype(jnp.int4),
)
print("done")

before the change, you should see an error after the int8 summation (which works) during the int4. After the change, both should run properly :)

Rather than a new test file for this test, we should add the test to the existing test suite here: https://github.com/jax-ml/jax/blob/6c8e56f43f1bd139869b600311c36bc0923e6b58/tests/lax_numpy_reducers_test.py#L820

I updated to PR by moving the tests to the target file and automatised it to check more dtypes. let me know if I can do better.

Thanks for all the support and patience :D
We should be good to go now

Thanks – could you squash the changes into a single commit again?

I squashed to a single commit, is this ready for you?


[1.10.2]Conduits are completely broken

Issue Description:
I've been having this peculiar rendering issue with conduits since probably 3.1.164 (persists through 3.1.173) , and it's somewhat gamebreaking. seems to only happen on 1.8_11 java, which opens a possibility of this issue being invalid
What happens:
https://imgur.com/a/KLDZ0
-The conduits render only on when you place another conduit that connects to them (resets back to transparency on chunk unload or relog)
-Invisible conduits "corrupt" chunks they're located in, making certain things (for example, storage drawers labels or c&b bit blocks) not render
What you expected to happen:
for things to just work
Steps to reproduce:

get jdk 1.8_11
launch the instance through it
place conduits
...

Affected Versions (Do not use "latest"):

EnderIO: 3.1.173
EnderCore: <IP_ADDRESS>b
Minecraft: 1.10.2
Forge: 2254

Your most recent log file where the issue was present:
http://pastebin.com/BKp8EcnL

Java 1.8_11 is terrible out dated - just from the security point of view you should update it.

don't bully

Wtf?

But yes, if you are using Java 8, use the latest one. I only fixed this because we still support Java 7 as there are some devices that cannot be easily upgraded to 8.


Hot Reloading Maximum call stack size exceeded error with circular reference

Carrying on from #7288 which has been opened for over a year.
Say, there are two files a.js and b.js.
a.js:
require('./b');

b.js:
require('./a')

After making a change to one of these files, with Hot Reloading enabled, it will run into an infinite situation and finally throw a Maximum call stack size exceeded error.
Even if I use a dynamic require in a function, such as what in b.js:
function f(){
  require('./a')
}

This is a pretty serious issue.

This is now fixed in master.


Use more well-known jwt package

@sijokun thanks for maintaining this repo. I'm aware that this is an async version of the original repository, and you might not be keen to modify some basic dependencies. But I hope you use more well-known packages like Autlib, which are JWT-verified, in favor of the jwt package used by the original repository. jwt does not seem to be maintained anymore, and this could pose security problems.

You can create a pull request and I will merge it. Unfortunately I don't have time now to rewrite this project.

Pyjwt is verified and is maintained, so there is no point in changing it


PROPOSAL - Use bot account instead of normal user

Is your feature request related to a problem? Please describe.
Currently admins have to create a user account for this plugin to work. They also have to enable two setting. See https://github.com/standup-raven/standup-raven/blob/master/docs/installation.md#mattermost-configuration. Both put additional work on the admin.
Describe the solution you'd like
This can be reduced by the plugin automatically creating a Raven bot account and using this one to post the messages.
Describe alternatives you've considered
Make the bot username configurable.

@hanzei thanks for the suggestion!
Agreed, it will minimize two steps from setup.


Where is UseInMemoryDatabase?

Can't find it in EF Core 2.2, was this functionality removed?
The picture demonstrates a project with EF Core added to it via NuGet, the InMemoryDatabaseExtensions does not exist in the Microsoft.EntityFrameworkCore namespace:

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

ID: c95e5c7e-882f-76f7-5301-2a5d1ede39d3
Version Independent ID: 8754aa99-67a7-98ac-a51e-0ba995f96414
Content: Testing with InMemory - EF Core
Content Source: entity-framework/core/miscellaneous/testing/in-memory.md
Product: entity-framework
GitHub Login: @rowanmiller
Microsoft Alias: divega

For it to work I had to install the Microsoft.EntityFrameworkCore.InMemory package, as explained in the doc.


Async HandlerFunc

On some of my routes I'd like to load some data from a server based on the ID in the URL, I was thinking of doing that via an async handler but that doesn't seem possible. Am I missing another way to do it?
Thanks!

(And as soon as I posted this I realized maybe the widget itself should be doing the async operations, not the route handler. If this is the case my apologies, I'm still getting a handle on everything).

@megamattron I'm not a contributor to the project as I just started using it myself, but architecturally speaking the async logic you're talking about should not be done in the route handler. It should be triggered by the mounted component.

Thanks @jpgilchrist, makes sense.


Doesn't start on iPhone physical device

I looked everywhere I could think of and can't figure out how to target my iPhone physical device.
When I have both an iPhone and Android phone connected, it will run on the Android phone. If I disconnect the Android phone and try again it says it can't find the Android phone.
In the debug target I have my iPhone selected. If I do a normal debug session with that target, it debugs fine on the iPhone.
When I try to do the trace it seems to be stuck trying to go to the Android phone.
How do I tell it to do the trace on the iPhone?

Hi, @tpitman !
Can you send something like screen recording?
.NET Meteor can't change your device If you select iOS Device here

I notice that just recentl. I am sure that will fix it. I have always been using the Debug Target because that was the only place I really saw a device name before. I wasn't sure what that one you called out was.
Thanks for the quick reponse.


Don't force further transpilation to use internal .babelrc

For any consumers that want to transpile this package with babel further,
they shouldn't be required to use the same presets defined in the local
.babelrc file. Those have already been applied for the npm package.

Coverage remained the same at 84.615% when pulling 90bb3450afa09cfcd268cdf0a8d79652f4ebd751 on wdoug:patch-1 into 5d24fb10fc29fafaea56ee500b2d76ffec3ec7bc on mattkrick:master.

Interesting, never thought of compiling something in node_modules...


Unable to Use FCM in Module Notification Class

Hey
I have implemented notification class in one of the module and in that I am using method from https://github.com/benwilkins/laravel-fcm-notification called toFcm but when I send notification through this class I get an error
Call to undefined method Modules\Blog\Notifications\NotifyBlogChannel::toFcm()
When I use same toFcm method in Laravel Default channel (in app/notification) then that works perfectly.
It seem it doesn't work in Module Notifications

Hi,
This is not related to this package.
Make sure your class is imported correctly as the error shows.


Devices without Serial Number

Hi,
First of all thanks for this great library. I was searching for quite a while for something exactly like this so thank you 😊.
However, i have 2 Litra Glow connected to my computer but i can't seem to identify them as no serial number shows up in the device list.
I am running the scripts on Windows 10, with node 18.16.0.
Any idea why that is the case ?

I guess that there won't be anything we can do to get the serial numbers, and we'll have to add an option that lets you pick the device by its "index". But I'd like tot ry hidapitester first, just to get a sense of what's going on.

Yeah, i've just started using index instead, works fine. I was just wondering if i you knew.
Here's the output :
`E:\Users\yonit\Documents\Stream\Touch Portal\scripts\litra>hidapitester --list-detail
0FD9/0078: Elgato - Elgato Facecam
vendorId:      0x0FD9
productId:     0x0078
usagePage:     0xFF00
usage:         0x0001
serial_number: FW42K1A02217
interface:     2
path: \?\HID#VID_0FD9&PID_0078&MI_02#8&252179c7&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}
046D/C548: Logitech - USB Receiver
vendorId:      0x046D
productId:     0xC548
usagePage:     0x0001
usage:         0x0006
serial_number:
interface:     0
path: \?\HID#VID_046D&PID_C548&MI_00#8&31e90214&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}\KBD
046D/C548: Logitech - USB Receiver
vendorId:      0x046D
productId:     0xC548
usagePage:     0x0001
usage:         0x0002
serial_number:
interface:     1
path: \?\HID#VID_046D&PID_C548&MI_01&Col01#8&e11c452&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}
046D/C900:  -
vendorId:      0x046D
productId:     0xC900
usagePage:     0x000C
usage:         0x0001
serial_number:
interface:     -1
path: \?\HID#VID_046D&PID_C900&Col01#8&15834a52&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}
046D/C900:  -
vendorId:      0x046D
productId:     0xC900
usagePage:     0x000C
usage:         0x0001
serial_number:
interface:     -1
path: \?\HID#VID_046D&PID_C900&Col01#9&1318cabc&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}
046D/C900:  -
vendorId:      0x046D
productId:     0xC900
usagePage:     0xFF43
usage:         0x0202
serial_number:
interface:     -1
path: \?\HID#VID_046D&PID_C900&Col02#8&15834a52&0&0001#{4d1e55b2-f16f-11cf-88cb-001111000030}
046D/C900:  -
vendorId:      0x046D
productId:     0xC900
usagePage:     0xFF43
usage:         0x0202
serial_number:
interface:     -1
path: \?\HID#VID_046D&PID_C900&Col02#9&1318cabc&0&0001#{4d1e55b2-f16f-11cf-88cb-001111000030}
046D/C548: Logitech - USB Receiver
vendorId:      0x046D
productId:     0xC548
usagePage:     0xFF00
usage:         0x0001
serial_number:
interface:     2
path: \?\HID#VID_046D&PID_C548&MI_02&Col01#8&15c57970&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}
046D/C548: Logitech - USB Receiver
vendorId:      0x046D
productId:     0xC548
usagePage:     0xFF00
usage:         0x0002
serial_number:
interface:     2
path: \?\HID#VID_046D&PID_C548&MI_02&Col02#8&15c57970&0&0001#{4d1e55b2-f16f-11cf-88cb-001111000030}
046D/C548: Logitech - USB Receiver
vendorId:      0x046D
productId:     0xC548
usagePage:     0x000C
usage:         0x0001
serial_number:
interface:     1
path: \?\HID#VID_046D&PID_C548&MI_01&Col02#8&e11c452&0&0001#{4d1e55b2-f16f-11cf-88cb-001111000030}
046D/C548: Logitech - USB Receiver
vendorId:      0x046D
productId:     0xC548
usagePage:     0x0001
usage:         0x0080
serial_number:
interface:     1
path: \?\HID#VID_046D&PID_C548&MI_01&Col03#8&e11c452&0&0002#{4d1e55b2-f16f-11cf-88cb-001111000030}
0B05/1939: AsusTek Computer Inc. - AURA LED Controller
vendorId:      0x0B05
productId:     0x1939
usagePage:     0xFF72
usage:         0x00A1
serial_number:<PHONE_NUMBER>
interface:     2
path: \?\HID#VID_0B05&PID_1939&MI_02#8&2765eff3&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}`

That's helpful - thanks! I think I'll probably make a change to make litra-devices return an index and then to allow you to specify a device by its index.


Detecting dropdown outside click

I'm a little bit stumped. I've got a widget inside of a dropdown with a "Cancel" and an "Apply" button. When the dropdown is closed through a click outside of the dropdown itself (like say I clicked on a button elsewhere on the page), I want to trigger the "Cancel" action in the widget. I'm not sure how to do that though.
I can listen to the input event on the dropdown for true/false but I can differentiate the boolean that comes through that outside click from a manual change to the v-model that I do when the user clicks "Apply"
If you've got ideas on how to do this I'd appreciate it.

For clarification both cancel and apply set the v-model value to false to hide the dropdown. So I can't just listen to @input for false and trigger the cancel method.

A work around is, make a flag that indicate if user has click apply, set it to true before hiding the dropdown. And watch the v-modal of dropdown as you said.
But it should be better with some event when outside click happened of cause.

@wxsms That makes perfect sense, I don't know why I didn't think about setting flags. Thanks


ValueError: operands could not be broadcast together

Hi Seth,
first of all thanks a lot for publishing this package!
A few weeks ago I wanted to try scranPY out on one of the scanpy datasets, specifically the 3kpbmc one.
Following mostly all the steps from the notebook, I got the error:
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
Cell In[10], line 2
      1 import scranPY
----> 2 scranPY.compute_sum_factors(adata, clusters='norm_groups', parallelize=True, algorithm='CVXPY', max_size=3000, plotting=True,
      3     lower_bound=0.4, normalize_counts=False)

File ~/mambaforge/envs/scranPY_test/lib/python3.11/site-packages/scranPY/main.py:250, in compute_sum_factors(adata, sizes, clusters, min_mean, max_size, parallelize, algorithm, stopwatch, plotting, lower_bound, normalize_counts, log1p, layer, save_plots_dir)
    248 lib_sizes = np.sum(adata.X, axis=1) ##3
    249 lib_sizes = lib_sizes / np.mean(lib_sizes)
--> 250 exprs = (adata.X.T / lib_sizes).T ##4
    251 min_mean = guess_min_mean(adata.X, min_mean=min_mean) ##5
    252 print('min_mean = ', min_mean)

File ~/mambaforge/envs/scranPY_test/lib/python3.11/site-packages/scipy/sparse/_base.py:686, in spmatrix.__truediv__(self, other)
    685 def __truediv__(self, other):
--> 686     return self._divide(other, true_divide=True)

File ~/mambaforge/envs/scranPY_test/lib/python3.11/site-packages/scipy/sparse/_base.py:665, in spmatrix._divide(self, other, true_divide, rdivide)
    663 if not rdivide:
    664     if true_divide:
--> 665         return np.true_divide(self.todense(), other)
    666     else:
    667         return np.divide(self.todense(), other)

ValueError: operands could not be broadcast together with shapes (32738,2700) (2700,1)

I also tried it with two other datasets I had on my computer and it had the same broadcast problem.
However, when trying it with the Paul15 dataset (also from scanpy), normalization actually completed.
I uploaded my notebook trying out Scranpy including package version numbers here. Do you think you maybe could also provide the environment and dataset you used to test ScranPY?
All the best,
Flo

Okay, I guess reading this tweet
https://twitter.com/sfortma2/status/1673448503543230464?s=20
would've made my life easier😅 Works perfect when prior converting all sparse matrices into dense ones using
adata.X = adata.X.A
or something similar!

Hi Flo. I'm sorry I missed your messages! You're correct, currently scranPY only supports dense arrays as input. I'll update the github page to reflect this until the functionality is implemented. Thanks!


ValueError: Expected value argument (Tensor of shape (128, 2000))

ValueError: Expected value argument (Tensor of shape (128, 2000)) to be within the support (IntegerGreaterThan(lower_bound=0)) of the distribution NegativeBinomial(total_count: torch.Size([128, 2000]), logits: torch.Size([128, 2000])), but found invalid values:

Have you encountered this problem?

I use the raw counts data，but it still gives an error

Thanks for the report! Could you verify that rna.layers["counts"] and atac.layers["counts"] contain all integers?

Sure I will look into this. Just to make sure, are these RNA and ATAC data that you are trying to integrate? What kind of preprocessing did you use? It would be most helpful if you could provide something like a jupyter notebook of your analysis.

Sure I will look into this. Just to make sure, are these RNA and ATAC data that you are trying to integrate? What kind of preprocessing did you use? It would be most helpful if you could provide something like a jupyter notebook of your analysis.

These two data are from different samples (the same patient), not Multiomics data. The initial data inside is the counts matrix, and the preprocessing is performed according to the tutorial. I didn't use jupyter to run, but I can show you the code.
rna = sc.read_loom("test/01.rawdata/P11_T_0_rna.loom", sparse=True, cleanup=False, X_name='spliced', obs_names='CellID', var_names='Gene', dtype='float32')
atac = sc.read_loom("test/01.rawdata/P11_T_0_atac.loom", sparse=True, cleanup=False, X_name='spliced', obs_names='CellID', var_names='Gene', dtype='float32')

rna.X, rna.X.data

rna.X = rna.layers["counts"]
rna.layers["counts"] = rna.X.copy()  # If don't assign it back, the next processing will change the data in counts

sc.pp.highly_variable_genes(rna, n_top_genes=2000, flavor="seurat_v3")
sc.pp.normalize_total(rna)
sc.pp.log1p(rna)
sc.pp.scale(rna)
sc.tl.pca(rna, n_comps=100, svd_solver="auto")

sc.pp.neighbors(rna, metric="cosine")
sc.tl.umap(rna)
sc.pl.umap(rna, color="celltype_singlesamp",save='_rna.pdf')

scglue.data.lsi(atac, n_components=100, n_iter=15)
sc.pp.neighbors(atac, use_rep="X_lsi", metric="cosine")
sc.tl.umap(atac)
sc.pl.umap(atac, color="Celltype",save='_atac.pdf')

scglue.data.get_gene_annotation(
    rna, gtf="./1.database/Reference/refdata-gex-GRCh38-2020-A/genes/genes.gtf.gz",
    gtf_by="gene_name"
)
rna.var.loc[:, ["chrom", "chromStart", "chromEnd"]].head()
ann_genes_list = rna.var[~rna.var.loc[:, ["chrom"]].isnull().iloc[:,0]].index.values.tolist() #Extract annotated genes
rna = rna[:,ann_genes_list]

atac.var_names[:5]
split = atac.var_names.str.split(r"[:-]")
atac.var["chrom"] = split.map(lambda x: x[0])
atac.var["chromStart"] = split.map(lambda x: x[1])
atac.var["chromEnd"] = split.map(lambda x: x[2])
atac.var.head()

graph = scglue.genomics.rna_anchored_prior_graph(rna, atac)
graph

graph.number_of_nodes(), graph.number_of_edges()
# Graph node covers all omic features
all(graph.has_node(gene) for gene in rna.var_names), \
all(graph.has_node(peak) for peak in atac.var_names)
# Edge attributes contain weights and signs
for _, e in zip(range(5), graph.edges):
    print(f"{e}: {graph.edges[e]}")

# Each node has a self-loop
all(graph.has_edge(gene, gene) for gene in rna.var_names), \
all(graph.has_edge(peak, peak) for peak in atac.var_names)

# Graph is symmetric
all(graph.has_edge(j, i) for i, j, _ in graph.edges)
atac.var.head()

scglue.models.configure_dataset(
    rna, "NB", use_highly_variable=True,
    use_layer="counts", use_rep="X_pca"
)

scglue.models.configure_dataset(
    atac, "NB", use_highly_variable=True,
    use_layer="counts",use_rep="X_lsi"
)

glue = scglue.models.fit_SCGLUE(
    {"rna": rna, "atac": atac}, graph,
    fit_kws={"directory": "glue"}
)

glue.save("glue.dill")
# glue = scglue.models.load_model("glue.dill")

dx = scglue.models.integration_consistency(
    glue, {"rna": rna, "atac": atac}, graph,
    count_layers={"rna": "counts"}
)
dx

Thanks a lot! There's nothing wrong about the code. Could you help check the loss values in tensorboard? You can do so with tensorboard --logdir=glue and then open the web page in a browser.

Thanks a lot! There's nothing wrong about the code. Could you help check the loss values in tensorboard? You can do so with tensorboard --logdir=glue and then open the web page in a browser.

Could you help me see it, I really don't understand，thank you very much

Thanks! The loss values are also mostly nominal, especially that the discriminator loss have indeed converged at around ln(2) = 0.693.
This is inconsistent with the UMAP plot you posted earlier. Could you also post your code after model training, corresponding to the "Apply model" section in the tutorial?
Is it possible that you accidentally skipped the following lines:
sc.pp.neighbors(combined, use_rep="X_glue", metric="cosine")
sc.tl.umap(combined)

That would cause it to visualize the UMAP of unimodal spaces (RNA PCA and ATAC LSI) superimposed over each other, rather than the UMAP of the GLUE-integrated space.

You are right, I repainted the umap and it shows up really well. I would like to ask you, what method do I use to identify the differences between clusters for downstream analysis. In addition, I found that the data in combined.X does not exist anymore.

Great! Yes the combined object does not have an X. It can only be used to visualize and cluster low-dimensional projections. You can obtain joint clusters using scanpy over combined.obsm["X_glue"]. For downstream differential analysis, I would recommend using scanpy over the RNA modality, and muon or episcanpy over the ATAC modality.

OK，thank you very much

@WhaleGe Hi, sorry to bother you. I met the same error:
Expected value argument (Tensor of shape (128, 3428)) to be within the support (IntegerGreaterThan(lower_bound=0)) of the distribution NegativeBinomial(total_count: torch.Size([128, 3428]), logits: torch.Size([128, 3428])), but found invalid values:
tensor([[0., 0., 0.,  ..., 0., 0., 0.],
        [0., 0., 0.,  ..., 0., 0., 0.],
        [0., 0., 0.,  ..., 0., 0., 0.],
        ...,
        [0., 0., 0.,  ..., 0., 0., 0.],
        [0., 0., 0.,  ..., 0., 0., 0.],
        [0., 0., 0.,  ..., 0., 0., 0.]])

Do you have any suggestions? Because I saw you had solved this problem.


JSON schemas should be strict validatable

Describe the bug
All EPAC JSON schemas should be strict validatable, to ensure definitions does not have unwanted properties that might break build and deploy.
I'd like to avoid writing our own linter for this, hopefully this is something that can be implemented in EPAC itself.
I'm no JSON schema expert, maybe adding "additionalProperties": false as a "root" value isn't enough? Seems like that's what Scoop does:

https://raw.githubusercontent.com/ScoopInstaller/Scoop/master/schema.json

Currently, none of the EPAC schemas have this:

policyAssignment: https://raw.githubusercontent.com/Azure/enterprise-azure-policy-as-code/main/Schemas/policy-assignment-schema.json
policyDefinition: https://raw.githubusercontent.com/Azure/enterprise-azure-policy-as-code/main/Schemas/policy-definition-schema.json
policySetDefinition: https://raw.githubusercontent.com/Azure/enterprise-azure-policy-as-code/main/Schemas/policy-set-definition-schema.json

To Reproduce
See issue comment: https://github.com/Azure/enterprise-azure-policy-as-code/issues/777#issuecomment-2415893832
Expected behavior
Non-valid JSON / JSONC should not go through EPAC.
Screenshots
None.
EPAC Version
Not relevant, JSON schema issue AFAIK.

Maybe it'd be smart to use a JSON schema version VSCode actually supports? 🤔

2022-07-16: https://github.com/microsoft/vscode/issues/155379
2023-09-27: https://github.com/microsoft/vscode-json-languageservice/issues/149

Looks like additionalProperties might work.

Updated schema to use this value - it seems to not like the additional property of id in your example but then doesn't have a problem with type so not sure what it going on there.

See comment in #777 re why the schema is provided - we can still look at adding additionalProperties but I don't believe that we'll be able to use the schema to test things like removed or invalid parameters - can do that with Pester and the module provided.

Thanks @anwather. We'll take a look at AzPolicyTest. We've linted wanted "root values" for EPAC policyDefinitions like this for now:
$AllDefinitions.Where{
    $(
        [string[]](
            Compare-Object -PassThru -CaseSensitive -ReferenceObject (
                (
                     ConvertFrom-Json -InputObject (Get-Content -Raw -Path $_.'Path')
                ).'PSObject'.'Properties'.Where{$_.'MemberType' -eq 'NoteProperty'}.'Name'
            ) -DifferenceObject '$schema','name','properties'
        )
    ).'Count' -gt 0
}

Closing as discussed with dev team - the purpose of the schema is to provide some level of Intellisense, not to support validation of policy files.


Plugin configurability: apps own scheduling logic

RENDERED
Many thanks to @Ratysz, @TheRawMeatball and @cart for helping shape my thoughts on this topic.
Summary
All scheduling information is attached directly to systems, and ultimately owned and configurable by the central app (or hand-written bevy_ecs equivalent).
To ensure that this can be done safely, plugins specify invariants about the ordering of their systems which must be respected.
Hard ordering constraints (where systems must be both ordered and separated by a hard sync point) are introduced as an assert-style protection to guard against a serious and common form of plugin misconfiguration.
Motivation
The current plugin model works well in simple cases, but completely breaks down when the central consumer (typically, an App) needs to configure when and if their systems run. The main difficulties are:

3rd party plugins can have "unfixable" ordering ambiguities or interop issues with other 3rd party plugins
plugins can not be added to states, and run criteria cannot be added
plugins can not be incorporated into apps and games that use a non-standard control flow architecture
end users who care about granular scheduling control for performance optimization have no way to change when systems run
worse, plugins can freely insert their own stages, causing sudden and uncontrollable bottlenecks
plugins cannot be used by standalone bevy_ecs users

See Bevy #2160 for more background on this problem.
By moving the ultimate responsibility for scheduling configuration to the central app, users can comfortably combine plugins that were not originally designed to work together correctly and fit the logic into their particular control flow.

could we get some code for how configuring a plugin would look?

I think going through some use cases with related dependency diagrams would definitely help make this RFC more clear.
I have a question: If a plugin is able to declare a system set, and that system set is able to declare the stage it belongs to, doesn't that defeat the purpose of these changes?
Ideally, the plugin should not be aware of what stages of the app are available, as I would consider that a user-side decision.

Here's my use case: It's useful to selectively disable plugins for power saving or when capabilities are disabled in a mobile app. For example, I have to do this in an iOS app:
    for label in [RenderStage::RenderGraphSystems,
                  RenderStage::Draw,
                  RenderStage::Render,
                  RenderStage::PostRender]
    {
        if let Some(mut stage) = app.schedule.get_stage_mut::<SystemStage>(&label) {
            stage.set_run_criteria(is_not_idle);
        }
    }

which works, but could be better. Without this, the OS will kill the app if it is put in the background.
Furthermore, it would be nice to have plugins for different OSes that handle this kind of thing, so that users aren't required to handle OS-specific schedule changes.

I have a question: If a plugin is able to declare a system set, and that system set is able to declare the stage it belongs to, doesn't that defeat the purpose of these changes?

Ideally, the plugin should not be aware of what stages of the app are available, as I would consider that a user-side decision.

@hymm So, I very much see your point: my perspective is that the stages (and high-level control flow in general) of an app are a user-side decision that plugins have no business knowing about.

However, in earlier discussions @cart made clear that we should be careful not to impact the beginner's experience, as having to grapple with scheduling immediately on starting to make their first Bevy game would be quite overwhelming and frustrating. Basically, adding your first plugins (especially default plugins!) should not need new users to specify which stage they're inserted into.
That said, now that I look back on the design, I think we could get away with removing the ability for plugins to dictate which stage systems run in. Basically, we could do some very minor smart scheduling, by letting apps specify a default stage for systems to be inserted into, then using hard ordering dependencies to insert the system sets to the schedule correctly.
I'll make a commit to change that in the morning, which IMO makes the design way cleaner.

I think you @'ed the wrong person.

In response to @cart's comments here I'm increasingly convinced that every system must have at least one label that is visible to the App for one simple reason: unresolveable system order ambiguities are a dealbreaker in production code, and cannot be fixed if the end user does not have labels (or ownership of) both systems.
 Fundamentally, because they prevent determinism, and can introduce unfixable non-deterministic bugs that will be very difficult to detect and completely destroy any attempt at . Neither the plugin author or the end user can predict which of their systems are likely to cause these issues: the only safe strategy is to ensure that you have (or can add) a label to each system.
As I see it, there are quite a few approaches we could try to take, most of which are pretty terrible:

Completely forbid system ordering ambiguities by panicking on schedule initialization. This is undesirable because:
Prevents system order ambiguities in quick-and-dirty prototype code.
Encourages a myopic approach to building the system ordering graph.
Unfixable system order ambiguities can still be introduced by adding a new system that's incompatible with a
Force users that care about determinism and test flakiness to audit and then either exclude or vendor every plugin in their dependency tree. This is terrible because:
It fragments the ecosystem with near-duplicate crates as users fork or remake crates to fix ambiguity issues.
It dramatically increases friction when considering trying out new crates as they must be audited.
Without a way to enforce this, determinism-capable plugins / crates can accidentally depart from the informal standard of publicly labelling each system.
Intermediate users will be repeatedly bitten by having to migrate away from a flaky crate after substantial effort building on it once they realize that they care about these things.
Force each plugin to operate in a separate private stage. This is pretty terrible because:
This seriously limits system parallelism, and adds overhead to each dependency you want to use.
Plugins that require operating systems across stage boundaries become a huge mess.
Other systems can never run between two systems within a plugin, even if it's required by the app's logic and desired by the plugin author.
Create a "deterministic" mode for the executor, which runs the schedule in a fixed order relative to any ambiguities. This is a poor choice because:
It massively reduces parallelization of systems by completely forbidding inconsequential ambiguities.
The seed or other ordering must be changed and regenerated every time a system is added or removed.
Tests become extremely brittle, relying on a global magic number that selects a particular valid ordering, recreating the problems with insertion-order system scheduling without the benefits.
Ensure that every system has at least one publicly visible label. This avoids the problem of unresolvable ambiguities without completely exposing everything in a granular fashion but:
We are forced to use a Plugin trait for our API design to enforce that labels are public by making the label type an associated type. See this proof of concept.
Having to create label names for every single exported system set is unergonomic and often redundant.
Reasoning about which systems should share a label is a non-trivial API design question for plugin authors.
Automatically provide a system label to each SystemDescriptor. This solves the problem and reduces boilerplate but forces plugin authors to expose serious internal details:
Users can pierce the API boundary provided by plugins by referring to individual systems.
This can increase maintenance costs for plugin authors when attempting to change internal structure if they are concerned with not breaking downstream users who have done so.
Similarly, this can increase upgrade costs for users who are relying on these internal details, preventing them from migrating large code bases to the newest version of Bevy and/or their plugins.
As we have no sensible way to require the functions that get turned into labels to be pub, actually grabbing these labels would be quite challenging, even with the use of type_id.
Closures can be turned into systems, and their types cannot be named.

Both 5 and 6 also share some drawbacks related to the "plugins define constraints" approach:

If our set of constraints is inadequate (or the plugin authors do not provide sufficient constraints), users can subtly break the guarantees that the plugin authors rely on for their functionality to work correctly.
Plugin authors may accidentally over-constrain their systems, reducing flexibility.

2 is the current solution. I feel pretty strongly that all solutions other than 5 and 6 are non-viable. Now that I've got "label types must be publicly exposed" working, I think that 5 is my clear preference as it avoids the "pub everything" approach in 6 that leads to makes plugin upgrading really hard.

(Alice and I are planning on discussing the points above more thoroughly in the near future, especially how they relate to ambiguity problems)
But heres a quick consolidation of my current thoughts and preferences.

I do agree that if we decide that every system needs a label, plugin-level labeling is the right call. However I think an "automatically created" label would be better UX.
I still have a strong preference for Plugin being a trait implemented on user types (over the "builder functions" proposed above). See my comment above for rationale.
I don't yet have a strong opinion on "Plugins have dependencies" vs "Plugins dont have dependencies" (see my comment above for the details of this problem).
I think SystemSets shouldn't be "special" as it creates too much cognitive load when users are reasoning about the structure of a program
I don't think we should have special "primary key" labels

This is a rough draft of where my head is at:
pub trait Plugin: Default + 'static {
    fn build(&self, plugin: &mut PluginState);
}

pub struct CustomPlugin;

impl Plugin for CustomPlugin {
    fn build(&self, plugin: &mut PluginState) {
        plugin
            .add_system(hello_world)
            .add_system_set(SystemSet::new().with_system(velocity).with_system(movement))
            .init_resource::<Thing>()
    }
}

// alternatively this could be called PluginBuilder
pub struct PluginState {
    systems: Vec<SystemDescriptor>,
    system_sets: Vec<SystemSet>,
    label: PluginLabel,
}

impl PluginState {
    pub fn new<P: Plugin>() -> Self {
        Self {
            system_sets: Vec::new(),
            systems: Vec::new(),
            label: PluginLabel::of::<P>(),
        }
    }
    pub fn apply(self, app: &mut App) {
        for system in self.systems {
            app.add_system(system.label(self.label.clone()))
        }

        for system_set in self.system_sets {
            app.add_system_set(system_set.label(self.label.clone()))
        }
    }

    /* other plugin builder functions here */
}

#[derive(SystemLabel, Debug, Clone, PartialEq, Eq, Hash)]
pub struct PluginLabel(TypeId);

impl PluginLabel {
    pub fn of<P: Plugin>() -> Self {
        Self(TypeId::of::<P>())
    }
}

Some things to note:

Plugin requires Default, which might seem odd at first glance. But note that we are using TypeIds to uniquely identify plugins. TypeIds cannot uniquely identify plugins if we allow duplicates. We will no longer accept direct plugin references on init. Instead we will store types and bevy will initialize the plugin at the appropriate time using the Default impl. This also opens the doors to a number of things:

Enables Plugins to declare dependencies easily.
Hard requirement of using Resources to configure plugins (which we have discussed a lot in the past and seems like a reasonable pattern to enforce). This also prepares the way for "editor-managed plugin initialization" (ex: you add a plugin to your app from the "asset store" using the Bevy Editor). Because all plugins must be initializable using their type, no user input is required (although theres still the issue of doing code gen, but i digress).
Allows users to disable any plugin they want via TypeId at app startup (ex: app.disable_plugin::<RenderPlugin>()).
Enables us to replace PluginGroups with Plugins that just register other plugins (if we decide that is better)
*I didn't include a Resource implementation in PluginState because that will depend on the "plugin dependency" decision. If plugins have dependencies, we can provide direct App access and do "normal resource registration". If plugins dont have dependencies, we would use "init systems with dependencies".

Plugin dependencies would look something like this:
impl Plugin for CustomPlugin {
    fn build(&self, plugin: &mut PluginState) {
        plugin
            // registers the plugin if it doesn't exist
            .add_plugin::<OtherPlugin>()
            // fails if SomeOtherPlugin isn't registered when the app starts
            // maybe this isn't needed when add_plugin could just init the plugin / avoid the failure in the first place
            .requires_plugin::<SomeOtherPlugin>()
            .add_system(hello_world)
    }
}

// We _could_ remove PluginGroups in favor of Plugins
impl Plugin For DefaultPlugins {
    fn build(&self, plugin: &mut PluginState) {
        plugin
            .add_plugin::<CorePlugin>()
            .add_plugin::<AssetPlugin>()
            .add_plugin::<RenderPlugin>()
            /* other deps here */
    }
}

I do agree that if we decide that every system needs a label, plugin-level labeling is the right call. However I think an "automatically created" label would be better UX.

Yep, fully agree and I'm working on that! I think these plugin labels can be automatically inferred from the type of the plugin.

I still have a strong preference for Plugin being a trait implemented on user types (over the "builder functions" proposed above). See my comment above for rationale.

Oh, that's a nice design. I was struggling to both minimize boilerplate and let it be configurable. Let me play with that some more...

I don't yet have a strong opinion on "Plugins have dependencies" vs "Plugins dont have dependencies" (see my comment above for the details of this problem).

Yeah, I don't have strong feelings here at all yet.

I don't think we should have special "primary key" labels

Agreed, this is no longer necessary.

Hmm, using the Plugin type to automatically make the label does seem like a reasonable reason to have the extra layer of indirection over exporting a function.

This is a rough draft of where my head is at

Hmm, I quite like this actually, though I have some questions:

If we're forcing config-through-resource, why not cut &self from Plugin::build entirely?
PluginLabel<P>(PhantomData<P>) might be better than PluginLabel(TypeId)
I wonder if directly using the plugin type itself as the label might be valid...

I wonder if directly using the plugin type itself as the label might be valid...

Yep, that's my hope!

If we're forcing config-through-resource, why not cut &self from Plugin::build entirely?

Very good point. That also removes the need for Default.

PluginLabel(PhantomData) might be better than PluginLabel(TypeId)

Hmm yeah it would be smaller / cheaper that way. And the DynEq class of stuff will already use TypeId of PluginLabel<P>, so the internal TypeId is redundant.

I wonder if directly using the plugin type itself as the label might be valid...

This would work, but it would requiring deriving SystemLabel for each Plugin, which I would like to avoid if possible.

This would work, but it would requiring deriving SystemLabel for each Plugin, which I would like to avoid if possible.

Nope, we can define a automatically implemented get_label method on the Plugin trait, which returns the label for that type and then do:
    app.configure_label(CombatPlugin.get_label().before("Foo"));

Thats not using the plugin type as a label. Thats using the plugin instance to get the label, which is just a rephrasing of PluginLabel::of::<CustomPlugin>().

True, but it avoids us having to store or specify label: PluginLabel in PluginState 🤔

Truth. And I guess if we made PluginLabel generic, we'd need to make PluginState generic too, which would be nasty.

if we made PluginLabel generic, we'd need to make PluginState generic too, which would be nasty

Why? Looking at it a bit more carefully, I have no idea why we'd even store the plugin label in PluginState.

Why? Looking at it a bit more carefully, I have no idea why we'd even store the plugin label in PluginState.

It can definitely be factored out into the higher level "Plugin orchestrator" that ultimately needs to be built. We need something to be able to apply a specific plugin's label to the systems in that plugin. We could do that in some type-erased Box<dyn PluginApplier> (note that if PluginLabel is a generic returned by an auto-impled trait, Plugin wont be directly boxable). For the simplicity of illustrating the concept I just encapsulated the logic in PluginState.

What about using SomePlugin::label() instead of SomePlugin::get_label()? It looks more readable, especially in the context of App configuration.

What about using SomePlugin::label() instead of SomePlugin::get_label()? It looks more readable, especially in the context of App configuration.

That's a perfectly reasonable bike-shed. I initially steered away from this, since system.label("foo") applies a label, rather than returns one.
I think the readability improvements are worth it though.

My two cents to the unresolved questions

Should we rename SystemDescriptor to something more user-friendly like ConfiguredSystem?

If they are not user facing, I think not. Either way, I thought about SystemConfiguration instead.

Do we still need plugin groups at all? Can we replace them with a simple standard collection? The ergonomics matter much less with App::default() initialization.

I think we don't strictly need them, but we can still keep them. They could just have the same power of the current plugins. Having whole App control, they can both add the necessary plugins and then anchor them to the right stages. See it as a prepackaged partial App configuration.

I think we don't strictly need them, but we can still keep them. They could just have the same power of the current plugins. Having whole App control, they can both add the necessary plugins and then anchor them to the right stages. See it as a prepackaged partial App configuration.

I'd really like to avoid blurring the line there. I think there's also room for some prepackaged App configuration, but it should either be an extra field on PluginState or preferably another form of exported data that users can add to the app. Adding this to PluginGroup is just messy.
I'm not sure we have enough context / experience to know exactly what form this extra app configuration might hold though, so I think we should wait to make that decision. Even something like "crates can choose to extend App with their own builder methods" would probably work well, and we can add that on top of this design once we have a clearer picture of things like nested schedules or how to make the winit runner more tweakable. The scope of this RFC is already huge enough though, so I'd like to defer that to another thread.

Hi!
I got to try out this RFC, by implementing parts of it myself. Here's what I've learned so far, hopefully that's helpful information:
So, my smol team is only using the bevy_ecs crate and nothing else. As such, it made sense for us to take a stab at implementing this and using it internally.  The first thing is that the RFC was written before Bevy 0.10, so it still assumes all of the stages stuff. Not a problem though, since the RFC already took the stageless future into account and mostly works nicely with it.
So far, the easiest plugins to write were those that are self-contained, and only have a single system set. Like a time plugin that just has a "update" system set.
Plugins with multiple system sets are also pretty elegant. E.g. A hypothetical physics plugin with a "read from game world and update physics world", a "physics step" and a "write back to game world" set . In the plugin, one simply specifies the order in which those sets run. And then the user can properly use the plugin, and even do advanced things like running independent game logic while parts of the physics plugin are running.
The annoying bit in terms of API design for me was "how do I expose the system sets of a plugin". It doesn't feel very ergonomic at the moment.

One could make a separate enum with a similar name?
Like #[derive(SystemSet)] pub enum PhysicsPluginSet { ...}
But that doesn't work for generic plugins.

One could add one function per set to the plugin and use TypeId in that function?
That seems a bit rough though.

An unrelated tricky bit is debugging the schedule ordering. There is a bevy plugin which visualizes a schedule, but it's not clear how well maintained it is ( https://github.com/jakobhellermann/bevy_mod_debugdump/issues/7 ). And that plugin assumes that one uses all of bevy.
Another issue that I assume is somewhat tough to figure out is "default plugin ordering". As in, a newcomer probably doesn't want to deal with masterfully ordering every single plugin for maximum performance. Lots of plugins could specific a sensible default, like "the time update plugin should run at the beginning of a frame".
But maybe that's easy to do when one uses more than just bevy_ecs.
IMO, this RFC is really nice. If well implemented, then the drawback of less powerful plugins would absolutely be compensated by "plugins are more likely to properly expose system sets and thus be easier to configure in terms of ordering".

And here's an example of what I'm doing at the moment. :)

"how do I expose the system sets of a plugin".

cart discussed a solution for this tentatively called ScheduleTemplate's on discord here. The basic idea is that a plugin can define a function that will add some preconfigured systems to any schedule.
// TransformPlugin
app.schedule_template(TransformTemplate, || (
  PropagateTransformsSet.in_set(TransformSystem::TransformPropagate),
  sync_simple_transforms.in_set(TransformPropagation),
  propagate_transforms.in_set(PropagateTransformsSet),
))

// User app
app.add_template_to_schedule(MyCustomSchedule, TransformTemplate)


Bug: Unable to resolve service for type 'Microsoft.Bot.Connector.Authentication.AuthenticationConfiguration'

Describe the bug
Bot not starting.

Downloaded the latest version from MAIN branch
Create a new bot from scratch
Started it.

Bot emulator kept returning Error 400, then Composer presented the following message:

Exported the code, and ran on VS:

Version
v1.1.1, built from commit c5e31b69d2d59dc5d99802776ec94d111509baa3
Browser

[ ] Electron distribution
[ ] Chrome
[ ] Safari
[ ] Firefox
[ X ] Edge

OS

[ ] macOS
[ X ] Windows
[ ] Ubuntu

Expected behavior
Bot starting.

Already fixed


Add QtWebKit

It would be great to have a port of the QtWebKit library ( https://github.com/annulen/webkit/wiki ) a community maintained version of the former official WebKit qt module.
Build instructions: https://github.com/annulen/webkit/wiki#build-requirements .
Debian package : https://packages.debian.org/source/sid/qtwebkit-opensource-src .
Non-core homebrew formula : https://github.com/KDE-mac/homebrew-kde/blob/master/Formula/qt-webkit.rb .

the port is not mine, stole from not remember ))
so bugs is not for me
did not test

qtwebkit.zip

We can’t reopen this issue until a PR is opened, unfortunately, consider making a pull request!

I guess this means that the new policy is not to have "New port request" open. Could it make  sense to remove the corresponding issue template https://github.com/microsoft/vcpkg/blob/master/.github/ISSUE_TEMPLATE/request-a-new-port.md ?

@traversaro No, we will still accept new port request, but we hope that new ports will be added by contributors.

@traversaro No, we will still accept new port request, but we hope that new ports will be added by contributors.

Just to clarify, so a new issue is opened, and then it will be closed after some time?

@traversaro Yes, if there is no body to add it into vcpkg.


Cannot save model when not giving a name in Layer.add_weight call

System information

Have I written custom code (as opposed to using a stock
example script provided in TensorFlow): Yes
OS Platform and Distribution: Manjaro 19.0.0 Kyria
TensorFlow installed from: binary
TensorFlow version: 2.1.0
Python version: 3.7.4

Describe the current behavior
I made a custom tf.keras.layers.Layer, where I make my weights in the build function using self.add_weight. However, I do not pass a name to this function. When I try to save the model that uses the layer, I get an error because the name of the weight is None (see traceback below).
Describe the expected behavior
I expected that the weight would either get a default name (possibly only upon saving), that I would get an error when calling add_weight or that I would get a more informative error when saving the model.
Standalone code to reproduce the issue
import tensorflow as tf
class CustomLayer(tf.keras.layers.Layer):
    def build(self, input_shape):
        self.w = self.add_weight(shape=(input_shape[-1], 1))
    def call(self, x):
        return tf.matmul(x, self.w)
inp = tf.keras.Input((5,))
m = tf.keras.Model(inputs=inp, outputs=CustomLayer()(inp))
m.save("/tmp/savedmodel")

Other info / logs
Traceback (most recent call last):
  File "tfbug.py", line 9, in <module>
    m.save("/tmp/savedmodel")
  File "/home/arno/conda/envs/tf2/lib/python3.7/site-packages/tensorflow_core/python/keras/engine/network.py", line 1008, in save
    signatures, options)
  File "/home/arno/conda/envs/tf2/lib/python3.7/site-packages/tensorflow_core/python/keras/saving/save.py", line 115, in save_model
    signatures, options)
  File "/home/arno/conda/envs/tf2/lib/python3.7/site-packages/tensorflow_core/python/keras/saving/saved_model/save.py", line 78, in save
    save_lib.save(model, filepath, signatures, options)
  File "/home/arno/conda/envs/tf2/lib/python3.7/site-packages/tensorflow_core/python/saved_model/save.py", line 899, in save
    _ = _SaveableView(checkpoint_graph_view)
  File "/home/arno/conda/envs/tf2/lib/python3.7/site-packages/tensorflow_core/python/saved_model/save.py", line 165, in __init__
    self.checkpoint_view.objects_ids_and_slot_variables())
  File "/home/arno/conda/envs/tf2/lib/python3.7/site-packages/tensorflow_core/python/training/tracking/graph_view.py", line 418, in objects_ids_and_slot_variables
    object_names[obj] = _object_prefix_from_path(path)
  File "/home/arno/conda/envs/tf2/lib/python3.7/site-packages/tensorflow_core/python/training/tracking/graph_view.py", line 64, in _object_prefix_from_path
    for trackable in path_to_root))
  File "/home/arno/conda/envs/tf2/lib/python3.7/site-packages/tensorflow_core/python/training/tracking/graph_view.py", line 64, in <genexpr>
    for trackable in path_to_root))
  File "/home/arno/conda/envs/tf2/lib/python3.7/site-packages/tensorflow_core/python/training/tracking/graph_view.py", line 57, in _escape_local_name
    return (name.replace(_ESCAPE_CHAR, _ESCAPE_CHAR + _ESCAPE_CHAR)
AttributeError: 'NoneType' object has no attribute 'replace'

I have tried on colab with TF version 2.1.0 , 2.2.0-dev20200218 and was able to reproduce the issue.Please, find the gist here. Thanks!

I still see this with TF 2.2.0 (GIT_VERSION: v2.2.0-rc4-8-g2b96f3662b). Even if this didn't work as is (via a default name in add_weight, or whatever), a slightly more specific error message would've cut the time it took me to work out the cause dramatically.

Issue is still reproducible with tf-nightly(2.4.0-dev20200813), please find the gist here

@arnomoonens Passing a name to weight works without any error . Please check the gist here. Thanks!
Please verify once and close the issue if this resolved your issue. Thanks!

@jvishnuvardhan that makes the code work, but the issue and comments are specific that that's not the whole story:

I expected that the weight would either get a default name (possibly only upon saving), that I would get an error when calling add_weight or that I would get a more informative error when saving the model.

Even if this didn't work as is (via a default name in add_weight, or whatever), a slightly more specific error message would've cut the time it took me to work out the cause dramatically.

@huonw Agree with you that this is an issue. Thanks!

Was able to reproduce your issue in Tf Nightly 2.6.0-dev20210524, please find the gist here. Thanks!

Hi There,
This is a stale issue. As you are using an older version of tensorflow, we are checking to see if you still need help on this issue. Please test the issue with the latest TensorFlow (TF2.7 and tf-nightly). If the issue still persists with the newer versions of TF, please feel free to open it in keras-team/keras repository by providing details about the issue and a standalone code to reproduce the issue. Thanks!
Please note that Keras development has moved to a separate Keras-team/keras repository to focus entirely on only Keras. Thanks!


<EMAIL_ADDRESS>list doesn't show running processes with<EMAIL_ADDRESS>

hi
when i start a process with "forever start process" and then it does not list this running process with "forever list".
I use<EMAIL_ADDRESS>and<EMAIL_ADDRESS>and GENTOO. it was worked before with<EMAIL_ADDRESS>.
...
  "trace": [
    {
      "column": 31,
      "file": "/usr/lib64/node_modules/forever/lib/forever.js",
      "function": "Array.0",
      "line": 194,
      "method": "0",
      "native": false
    },
    {
      "column": 41,
      "file": "node.js",
      "function": "EventEmitter._tickCallback",
      "line": 192,
      "method": "_tickCallback",
      "native": false
    }
...

  "stack": [
    "Error: Cannot find forever process: undefined",
    "    at Array.0 (/usr/lib64/node_modules/forever/lib/forever.js:194:31)",
    "    at EventEmitter._tickCallback (node.js:192:41)"
  ],
  "level": "error",
  "message": "uncaughtException"

/root/.forever/
|-- [-rw-r--r-- root    ]  NZTy.log
|-- [-rw-r--r-- root    ]  config.json
|-- [drwxr-xr-x root    ]  pids
|   `-- [-rw-r----- root    ]  NZTy.pid
`-- [drwxr-xr-x root    ]  sock

config.json

{
  "root": "/root/.forever",
  "pidPath": "/root/.forever/pids",
  "sockPath": "/root/.forever/sock",
  "loglength": 100,
  "columns": [
    "uid",
    "command",
    "script",
    "forever",
    "pid",
    "logfile",
    "uptime"
  ]
}

<EMAIL_ADDRESS>/usr/lib/node_modules/forever
├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS><EMAIL_ADDRESS>├──<EMAIL_ADDRESS><EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>├──<EMAIL_ADDRESS><EMAIL_ADDRESS>├──<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>├──<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>├──<EMAIL_ADDRESS><EMAIL_ADDRESS>├──<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>├──<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>├──<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>└──<EMAIL_ADDRESS>
Cheers
Remo

@remoe Cannot reproduce this. I spun up a Gentoo 10.1 server on Rackspace Cloud with this exact configuration:
#
# Update system
#
emerge --sync
emerge portage

#
# Install git, and other dependencies
#
emerge --verbose dev-vcs/git dev-util/pkgconfig

#
# Install python 2.7
#
wget curl http://python.org/ftp/python/2.7/Python-2.7.tgz -o Python2.7.tgz
tar -zxvf Python2.7.tgz
cd Python-2.7
./configure
make && make install
mv /usr/local/bin/python /usr/local/bin/python2.6.2
mv /usr/local/bin/python2.7 /usr/local/bin/python
cp -f /usr/local/bin/python /usr/bin/python

#
# Install node, npm, and forever
#
git clone git://github.com/joyent/node.git
cd node
git checkout v0.6.7
./configure
make && make install
cd ../
npm install forever -g

From there I grabbed some examples that are in the forever repo
cd /root
git clone git://github.com/nodejitsu/forever.git
cd forever

Then it worked.
forever-gentoo forever # forever list
info:   No forever processes running
forever-gentoo forever # forever start examples/server.js -p 8080
info:   Forever processing file: examples/server.js
forever-gentoo forever # forever list
info:   Forever processes running
data:       uid  command script                     forever pid  logfile                 uptime
data:   [0] lQNZ node    examples/server.js -p 8080 7424    7470 /root/.forever/lQNZ.log 0:0:0:0.7
forever-gentoo forever # forever stopall
info:   Forever stopped processes:
data:       uid  command script                     forever pid  logfile                 uptime
data:   [0] lQNZ node    examples/server.js -p 8080 7424    7552 /root/.forever/lQNZ.log 0:0:0:0.205

I'm going to close this because I can't reproduce it. Please provide exact instructions about every command run on your machine since it was created so I can reproduce the exact conditions of your machine. I can't help otherwise; sorry.

I have a very similar problem on an old ubuntu 10.10.
$ git clone git://github.com/nodejitsu/forever.git
$ cd forever
$ ../bin/forever server.js -p 8002
> hello world running on port 8002
$ ../bin/forever start server.js -p 8002
info:   Forever processing file: server.js
$ ../bin/forever stop server.js -p 8002
error:  Forever cannot find process with index: server.js
$ ../bin/forever list
info:   No forever processes running

I've also tried to run everything as root, but that's not the problem.
How can I help tracking this down? This is a long running machine so I don't have a creation recipe.

Try rm -rf ~/.forever

It didn't work.
I'm trying reinstalling node from git instead of the tarball.
Let's hope that helps.

Same problem on a openvz virtualized Ubuntu 10.04
Linux 2.6.32-6-pve #1 SMP Fri Nov 4 06:54:05 CET 2011 x86_64 GNU/Linux
deploy@test:/var/www/apps/test1$ ls
app.js  node_modules  package.json public  routes  views
deploy@test:/var/www/apps/test1$ forever start app.js
info:   Forever processing file: app.js
deploy@test:/var/www/apps/test1$ forever list
info:   No forever processes running

It didn't work reinstalling from git, same problem.

The ~/.forever/sock/ directory is empty after starting a process.
In another (old) setup in that directory there is a "forever.sock" file.

@mcollina , same on my installation. I don't have a socks file for my process. See my dump of the .forever directory.

@indexzero i can't reformat my system :) A VM is not the same as real hardware.
i use Linux 2.6.39-gentoo-r3 and it is important to write that i use v8 version v8-<IP_ADDRESS> .

@remoe I understand that. I am simply trying to isolate the problem. If you can confirm that using the above configuration actually works, we can attempt to figure out what's wrong with your installation. Without that confirmation it is difficult to begin to isolate the problem.

@indexzero , i've updated my prev. comment. and here are my node version information

 node
> process.versions
{ node: '0.6.7',
  v8: '<IP_ADDRESS>',
  ares: '1.7.5-DEV',
  uv: '0.6',
  openssl: '1.0.0e' }
>

@remoe Ok. Again, I can't move forward here until a third-party verifies that my installations instructions actually work on a fresh server. I understand that your current server cannot be reformatted, but I need this information.

@indexzero i've runned your testcode of forever and it fails:
 forever # npm test

><EMAIL_ADDRESS>test /root/forever
> vows test/**/*-test.js --spec -i

♢ forever/core/check-process

  When using forever checking if process exists if process process exists
    ✓ should return true
  When using forever checking if process exists if process doesn't exist
    ✓ should return false

♢ forever/core/tail

  When using forever the tail() method
    ✓ should respond with logs for the script
  When the tests are over stop all forever processes
    ✓ should stop the correct number of procs

♢ forever/monitor/spawn-options

  When using forever an instance of forever.Monitor with valid options passing environment variables to env-vars.js
    ✓ should pass the environment variables to the child
  When using forever an instance of forever.Monitor with valid options passing a custom cwd to custom-cwd.js
    ✓ should setup the child to run in the target directory
  When using forever an instance of forever.Monitor with valid options setting hideEnv when spawning all-env-vars.js
    ✓ should hide the environment variables passed to the child

♢ forever/monitor/fork

  When using forever and spawning a script that uses process.send() using the 'native' fork
    ✓ should reemit the message correctly
  When using forever and spawning a script that uses process.send() with forkShim true
    ✓ should reemit the message correctly

♢ forever/monitor/signal

  When using forever and spawning a script that ignores signals SIGINT and SIGTERM with killTTL defined
    ✓ should forcibly kill the processes

♢ forever/monitor/simple

  When using forever an instance of forever.Monitor with valid options
    ✓ should have correct properties set
  When using forever attempting to start a script that doesn't exist
    ✓ should throw an error about the invalid file
  When using forever non-node usage with a perl one-liner
    ✓ should get back moo
  When using forever an instance of forever.Monitor with valid options calling the restart() method in less than minUptime
    ✓ should restart the child process
  When using forever running error-on-timer sample once
    ✓ should emit 'exit' when completed
  When using forever running error-on-timer sample three times
    ✓ should emit 'exit' when completed

♢ forever/monitor/spin-restart

  When using forever and spawning a script that spin restarts with no spinSleepTime specified
    ✓ should spawn both processes appropriately
    ✓ should only run the bad process once
  When using forever and spawning a script that spin restarts with a spinSleepTime specified
    ✓ should restart spinning processes

♢ forever/monitor/watch

  When using forever with watch enabled forever should
    ✓ have correct options set
  When using forever with watch enabled forever should read .foreverignore file
    ✓ and store ignore patterns

/root/forever/lib/forever/plugins/watch.js:50
        forever.log.info('restaring script because ' + f + ' changed');
        ^
ReferenceError: forever is not defined
    at /root/forever/lib/forever/plugins/watch.js:50:9
    at StatWatcher.<anonymous> (/root/forever/node_modules/watch/main.js:60:38)
    at StatWatcher.emit (events.js:70:17)
    at StatWatcher.onchange (fs.js:705:10)

♢ forever/plugins/logger

  When using logger plugin with a custom stream
    ✓ should output correct number of lines
  When using logger plugin with a custom stream after exit event
    ✓ stream shouldn't be closed

♢ forever/service/simple

  When using forever the service module
    ✓ should have the correct exports

♢ forever/workers/multiple

  When using forever and spawning two processes using the same script
    ✓ should respond with no error
  When using forever and spawning two processes using the same script requests against the first child
    ✓ should respond with i know nodejitsu
    ✓ stop the child process
  When using forever and spawning two processes using the same script requests against the second child
    ✓ should respond with i know nodejitsu
    ✓ stop the child process
  Once the stop attempt has been made
    ✓ the processes should be dead

♢ forever/worker/simple

  When using forever worker and starting it and pinging it worker should connect and respond to pings
    ✓ with pong
  When using forever worker and starting it and pinging it worker should connect and when queried for data
    ✓ it should respond with data
  When using forever worker and starting it and pinging it worker should connect and when asked to kill the process
    ✓ it should kill the process

✗ Errored » 31 honored ∙ 1 errored (7.832s)

npm ERR<EMAIL_ADDRESS>test: `vows test/**/*-test.js --spec -i`
npm ERR! `sh "-c" "vows test/**/*-test.js --spec -i"` failed with 2
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>test script.
npm ERR! This is most likely a problem with the forever package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     vows test/**/*-test.js --spec -i
npm ERR! You can get their info via:
npm ERR!     npm owner ls forever
npm ERR! There is likely additional logging output above.
npm ERR!
npm ERR! System Linux 2.6.39-gentoo-r3
npm ERR! command "node" "/usr/bin/npm" "test"
npm ERR! cwd /root/forever
npm ERR! node -v v0.6.7
npm ERR! npm -v 1.1.0
npm ERR! code ELIFECYCLE
npm ERR! message<EMAIL_ADDRESS>test: `vows test/**/*-test.js --spec -i`
npm ERR! message `sh "-c" "vows test/**/*-test.js --spec -i"` failed with 2
npm ERR! errno {}
npm ERR!
npm ERR! Additional logging details can be found in:
npm ERR!     /root/forever/npm-debug.log
npm not ok

@remoe That's a good catch, thanks. Unfortunately, it's unrelated to the matter at hand since you're not using the watch plugin (i.e. -w or --watch options) in your sample usage.
Have you tried reproducing on a fresh VM? I can't stress this enough.

@indexzero , sorry i don't have a fresh VM available.

http://www.rackspace.com/cloud/ ... costs about $0.10 for the hour it would take to verify this. I really need your help here.

Got It!!
It seems https://github.com/nodejitsu/forever/blob/master/lib/forever/worker.js#L16 never call his callback (is it possible??).
I tryed to put the line "callback(null, sock)" instead of fs.stat and I got the list...
Now I have to find out the reason of this strange behavior of fs.stat... maybe tomorrow... ;)

@Nss Considering the platform discrepancy around the issue and the effect exact build instructions have it could be a core bug in fs.stat. We have to stat the file in-order to avoid two workers attempting to listen on the same socket.
... Although I could use the current ticks which is guarenteed to be unique for a while ... I'll experiment. Thanks for the tip!

@Nss @remoe Can you try installing the microtime branch from git?
  $ git clone git://github.com/nodejitsu/forever.git
  $ cd forever
  $ git checkout microtime
  $ [sudo] npm uninstall forever -g
  $ [sudo] npm link
  # Do stuff with forever

On my system it fixes the issue perfectly.

@indexzero , it fixes the issue also on my system, congrats !

@Nss You're a hero.

@remoe @mcollina I'll try to push this out as<EMAIL_ADDRESS>today

Thanks!!
Il giorno 15/gen/2012, alle ore 02:07, Charlie Robbins
<EMAIL_ADDRESS>ha scritto:

@remoe @mcollina I'll try to push this out as<EMAIL_ADDRESS>today

Reply to this email directly or view it on GitHub:
https://github.com/nodejitsu/forever/issues/225#issuecomment-3496326

Fixed in<EMAIL_ADDRESS>Thanks to everyone who provided bug reports :)

Ok, thanks. I've tested it and it works ;)

@indexzero thanks, I'm using 0.8.4 now ;)

Hi Guys.,,

Hi Guys.,
I am badly stucked to run forever as linux service. If i try to run forever as linux service by logged in as user(not as root).
First I tried to run forever as command by user
If i try to run command as lsof | grep 25696(process id of forever)
it is giving log as by this it is starting the worker sock
node      25696     stapp    9r      DIR              253,0     4096        2 /
node      25696     stapp   10u     unix 0xffff8801385c9680      0t0 45772086 socket
node      25696     stapp   11u     unix 0xffff88013998acc0      0t0 45772026 /home/stapp/.forever/sock/worker.14295342786175T4.sock
node      25696     stapp   13u     unix 0xffff8801385c9c80      0t0 45772088 socket
node      25696     stapp   15u     unix 0xffff88013ca99380      0t0 45772090 socket
Same thing If i tried to run as linux service (/etc/init.d/myservice_file) if i check the log by
lsof | grep 25786(process id of forever)
it is giving log as by this it is not starting worker sock
node      25770     stapp    7w     FIFO                0,8      0t0 45773381 pipe
node      25770     stapp    8u      REG                0,9        0     3672 anon_inode
node      25770     stapp    9r      DIR              253,0     4096        2 /
node      25770     stapp   10u     unix 0xffff88013b5c9c80      0t0 45773384 socket
node      25770     stapp   12u     unix 0xffff88013b5c9680      0t0 45773386 socket
node      25770     stapp   14u     unix 0xffff88013b5c9080      0t0 45773388 socket
Please help me out.
In one word i can forever as linux init.d service by linux user (not root) it is not starting /home/user/.forever/sock/worker.1429535560073IJV.sock
Regards
Samaka


complete refactor of entire package

easier to grasp (and use) types:

add SyncWorker type, which provides blocking streaming.
this is instead of Streamer type
asyncWorker, which wraps SyncWorker and provides asynchronous
streaming
AsyncWorkerGroup, which manages multiple asyncWorkers.
this is isntead of MultiStreamer type

add insert error type heirarchy. this provides a way to know when an
insert
operation has occurred, how many retries have been made,
and whether the insert has succeeded or not, fixes #8
enqueuing rows now support passing insert ids, fixes #7, fixes #11
add support for SkipInvalidRows and IgnoreUnknownValues:
https://cloud.google.com/bigquery/docs/reference/v2/tabledata/insertAll#request-body
switch to use functional options when passing arguments to New()
constructor functions
add option to automatically retry/not retry (with backoff)
when executing insert operations
update, add examples

Current coverage is 93.16% (diff: 93.16%)

Merging #16 into master will increase coverage by 9.42%

@@             master        #16   diff @@
==========================================
  Files             4         10     +6
  Lines           246        322    +76
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
+ Hits            206        300    +94
+ Misses           40         19    -21
- Partials          0          3     +3

Powered by Codecov. Last update 6c359e4...fefc1d1


Added content wrapped in decorator

 Issue by aray12
Friday Jul 15, 2016 at 16:41 GMT
Originally opened as https://github.com/storybooks/react-storybook-addon-info/issues/40

So if I want to provide some styling just to the component. The following example will center everything, including what addon-info adds
import React from 'react';
import { storiesOf, action } from '@kadira/storybook';

storiesOf('Button', module)
  .addDecorator(story => (
{story()}
))
  .addWithInfo(
    'Standard
    `
    This should continue to be normal and not constrained by the decorator

    `,
    () => (
      <button onClick={action('button clicked')}>Click Me</button>
    ),
    { inline: true, source: true, header: true }
  )

Thoughts?

 Comment by mnmtanish
Monday Jul 18, 2016 at 09:52 GMT

Yeah, that messes things up pretty bad. I think we should let addon developers decide that. How about exposing 2 new methods addRaw and decorate in addition to add?
cc: @arunoda

 Comment by arunoda
Wednesday Jul 20, 2016 at 04:24 GMT

@mnmtanish basically we need some options to do this:

apply decorators
do not apply decorators

Is that? If so, I'm okay with a such an API.
May be an option to the .add as byPassDecorators.

 Comment by mnmtanish
Thursday Jul 21, 2016 at 04:20 GMT

With the option users can only bypass decorators. With addRaw and decorate users can apply decorators exactly where they want. And adding an options object to the add method would make the API look terrible.

In general, you can apply styles to the container of your story markup by providing a styles key in the configuration such as:
{
  ...
  styles: stylesheet => {
    stylesheet.children = {
    // some styles
    }
    return stylesheet
  },
}

However, this did not work when rendering inline (with inline: true in the config), so I just submmited #1431 to address this.

#1147 We will move the info into a panel.

Feel free to continue discussing or re-open if there's still an issue afterwards 👍


Legend pagination

I wish I could paginate Chart.js legends, such as available in other libraries (e.g. https://jsfiddle.net/gh/get/library/pure/highcharts/highcharts/tree/master/samples/highcharts/legend/navigation-enabled-false/).
I'm trying to prevent the canvas from being overwhelmed by legends.
Pagination should be horizontal or vertical, according to configuration.

There's a bunch of other issues discussing this and similar requests, so I'm going to close this one.
E.g. see https://github.com/chartjs/Chart.js/issues/3761 https://github.com/chartjs/Chart.js/issues/5561 and https://github.com/chartjs/Chart.js/issues/6545
There's probably others as well


feat: add blurting method

Description
Please include a summary of the changes and the related issue. Please also include relevant motivation and context. List any dependencies that are required for this change.
Fixes #71
Type of change
Please delete options that are not relevant.

[x] New feature (non-breaking change which adds functionality)

How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

[x] Manual Testing

Checklist:

[x] I have performed a self-review of my code
[x] I have commented my code, particularly in hard-to-understand areas
[x] My changes generate no new warnings

:tada: This PR is included in version 1.6.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Sending isDarkMode to statements url

Details

This will not update the theme of the page just yet, this functionality will only be done when we merge this Web-E PR as well, but we don't need to HOLD on it.
Fixed Issues

https://github.com/Expensify/App/issues/33978
PROPOSAL:
Tests

Open the network tab in the browser developer tools
Send a DM with a link that looks like this: https://<staging>.new.expensify.com/statements/202312
With the app in dark mode open the link and look for this request in the network tab https://<staging>.expensify.com/statement.php it should have a isDarkMode=true parameter
Now with the app in light mode open the link and look for this request in the network tab https://<staging>.expensify.com/statement.php it should have no added parameter

[x] Verify that no errors appear in the JS console

Offline tests

The link only works online.
QA Steps

Open the network tab in the browser developer tools
Send a DM with a link that looks like this: https://<staging>.new.expensify.com/statements/202312
With the app in dark mode open the link and look for this request in the network tab https://<staging>.expensify.com/statement.php it should have a isDarkMode=true parameter
Now with the app in light mode open the link and look for this request in the network tab https://<staging>.expensify.com/statement.php it should have no added parameter

[ ] Verify that no errors appear in the JS console

PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[x] If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[x] If the PR modifies the form input styles:

[x] I verified that all the inputs inside a form are aligned with each other.
[x] I added Design label so the design team can review the changes.

[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

MacOS: Desktop

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

🚀 Deployed to production by https://github.com/marcaaron in version: 1.4.26-2 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
failure ❌

🕸 web 🕸
success ✅


No command besides "init" should create a repository

Output of restic version
restic 0.7.1
compiled with go1.8.3 on linux/amd64
Today, restic scared my good.
I ran restic  -r /mnt/bacup/restic snaphosts and got
unable to open config file: Stat: stat /mnt/bacup/restic/config: no such file or directory
Is there a repository at the following location?
/mnt/bacup/restic

I quickly checked /mnt/bacup/restic/ and indeed, the config file was missing. I was already worried that my repository was hosed. Then it dawned on me, that I simply had typoed the repository path (which should have been /mnt/backup/restic).
restic unhelpfully had created a /mnt/bacup/restic directory/repository.
Imho, restic should never auto-create a repository. The only time this should happen is on restic init.
It should simply return an error in such a case.
To reproduce the error, run
 restic -r /tmp/typo snapshots and see that restic has created something at /tmp/typo which looks like a (incomplete) repository.

Oh, interesting! That's indeed a bug and I agree with you that only restic init should create a repo. Thanks for the report!

Thanks for the super fast response!
Fwiw, snapshots is  not the only command which currently triggers this behaviour, others like backup or check do so as well.

Yeah, I've already triaged the problem ;)

Yeah, I've already triaged the problem ;)

You're awesome :-)


TypeScript Error: TS2769 in timezz.ts line 325

I'm encountering an error in my IDE:

Line 139 assigns NodeJS.Timer to the timeout variable:
 private timeout: NodeJS.Timer | null = null;
If I change the type to NodeJS.Timeout, the error goes away.
This is possibly due to the type of environment the code is excecuted in.
I'm not a Node or JS guy...  but this is what ChatGPT has to say:

So it might appear that my application is working in a Node.js environment, and not in a browser environment.

Hello, thank you for issue, I'll fix it soon.

I've release a new version, can you try it now?

The code that my build is importing is from an assets folder in a 3rd party theme.
The code in the timerzz.ts file is exactly what I shown in the original issue.
 private timeout: NodeJS.Timer | null = null;
Is it possible the author the theme has modified the code?  Because I have viewed the code here in the master branch at version 7 and it was ReturnType... as you stated in the previously edited comment.
The package however does require the npm dependency of version 7.0.0 which leaves me to wonder if the theme author has edited the original code..

I fixed it in 8 version, so you can update the timezz and try again.

The code doesn't appear to have changed in the zip file:

I've notified the theme author of the issue, and sent him a link to this thread.
Let's see what he has to say?

Yes, off course, he should just update the timezz version to 8. Also, can you share a link to the theme?

Cartzilla | Multipurpose E-Commerce Bootstrap HTML Template (createx.studio)https://cartzilla.createx.studio/index.html

From: Valerii Strilets @.>
Sent: Wednesday, June 12, 2024 3:57 PM
To: letstri/timezz @.>
Cc: richardaubin @.>; Author @.>
Subject: Re: [letstri/timezz] TypeScript Error: TS2769 in timezz.ts line 325 (Issue #35)
Yes, off course, he should just update the timezz version to 8. Also, can you share a link to the theme?
—
Reply to this email directly, view it on GitHubhttps://github.com/letstri/timezz/issues/35#issuecomment-2162353852, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AJBS3BNFKN7TKX3MEZAS7HTZG75NXAVCNFSM6AAAAABJFMSG7GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNRSGM2TGOBVGI.
You are receiving this because you authored the thread.Message ID: @.***>


Refactor for initial release

Will resolve #56

Going ahead with merge so we can move on to #41 and #53


chore: Included githubactions in the dependabot config

This should help with keeping the GitHub actions updated on new releases. This will also help with keeping it secure.
Dependabot helps in keeping the supply chain secure https://docs.github.com/en/code-security/dependabot
GitHub actions up to date https://docs.github.com/en/code-security/dependabot/working-with-dependabot/keeping-your-actions-up-to-date-with-dependabot
https://github.com/ossf/scorecard/blob/main/docs/checks.md#dependency-update-tool
Signed-off-by: naveen<EMAIL_ADDRESS>

Codecov Report

Merging #1706 (43045d2) into trunk (db8638d) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##            trunk    #1706   +/-   ##
=======================================
  Coverage   83.29%   83.29%
=======================================
  Files         400      400
  Lines       87759    87759
  Branches     9329     9329
=======================================
  Hits        73096    73096
  Misses      11485    11485
  Partials     3178     3178

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 db8638d...43045d2. Read the comment docs.

Merged - thanks!