Move search implementation from generic IndexView to BaseListingView

Quite nuanced, but I think the cleanups here are worth it. See each commit message for more details.

Just rebased.

Thanks @gasman!

If there are indeed no such views within Wagtail, and the only way for third-party views to not have breadcrumbs is if they set _show_breadcrumbs = False or use the wagtailadmin/generic/listing.html template directly without going though BaseListingView - both of which are unsupported - then we should be all clear to eliminate that, right?

Well, technically we have somewhat eliminated the support for BaseListingView without breadcrumbs in this PR. Breadcrumbs will always show in any views that use BaseListingView and/or wagtailadmin/generic/listing.html template – and while forcing _show_breadcrumbs = False on the view would disable the breadcrumbs and give the old header back, this is not something specific to BaseListingView. It's a result of having the default logic in wagtailadmin/generic/base.html:
https://github.com/wagtail/wagtail/blob/954519390753ab47b1f43c05d377496fe38f8c93/wagtail/admin/templates/wagtailadmin/generic/base.html#L8-L20
So there is actually no code left in BaseListingView/wagtailadmin/generic/listing.html that add explicit support for the non-breadcrumbs version 🙂
My vision is that the view templates should not need to be concerned about overriding the header block to add stuff in there (e.g. header buttons, search and filters) in favour of defining them on the view class. Putting the breadcrumbs logic in the base.html template allows us to inch closer to that goal as we refactor the views, since we won't need to touch that block for new code, while still providing basic heading support to any views (including non-listing ones) that extend that template and not use the breadcrumbs yet.
Anyway, to recap, what this PR does is:

Enforce breadcrumbs on all listing views by default.
Remove the ability to have filters in BaseListingView/wagtailadmin/generic/listing.html if breadcrumbs are disabled.

The reason why we had this before was because the report views were still using it before 6.2. Now, nothing in core relies on this.
This ability is now moved to the wagtailadmin/generic/index.html template, in case people still use it somehow. Very unlikely, so we in theory can also remove it from the wagtailadmin/generic/index.html template. This is the part that we can clean up – let me know if we want to! 😉

Add the ability to have search in BaseListingView/wagtailadmin/generic/listing.html.

This requires the use of breadcrumbs, because we don't want to support the old header for searching. Hence why we enable breadcrumbs by default, so users don't need to know about it.
AFAIK, this view/template never supported searching at all, since we never pass any required variables for searching with the old header. This block is removed in this PR: https://github.com/wagtail/wagtail/blob/954519390753ab47b1f43c05d377496fe38f8c93/wagtail/admin/templates/wagtailadmin/generic/listing.html#L4-L8
So any views that used this class/template with searching had to have their own search implementation and/or use a template that has the code for it. This was the case with the page SearchView, and we refactor it in this PR.

This ability is now moved to the wagtailadmin/generic/index.html template, in case people still use it somehow. Very unlikely, so we in theory can also remove it from the wagtailadmin/generic/index.html template. This is the part that we can clean up – let me know if we want to! 😉

Given the combination of A) it's very unlikely people have done this, B) doing it requires jumping through hoops (namely setting _show_breadcrumbs = False or using the template independently of the view classes) that should signal to any reasonable developer that what they're doing is unsupported, and C) the burden of fixing it by switching to the breadcrumb variant (or if that's really not possible, creating your own template based on whatever legacy version of wagtailadmin/generic/index.html you like) seems pretty small - I think it should be pretty uncontroversial to go ahead with this cleanup!


importing bad paths fails with incorrect error

If a go file that's being compiled has a bad import path, gb will claim:

FATAL: command "build" failed: no packages supplied

Even though there are valid files. This is true even if there are many files that are correct, with only one file containing an invalid import.
This is reproduced with a simple test file:
package main

import (
	"log"
	"this/is/a/bad/path"
)

func main() {
	log.Println("Hello World.")
}

The reason this is happening is for several reasons. In context.go, matchPackages has a call to filepath.Walk that isn't handling the error that's returned. The error that's being returned (but not handled) is correctly calling out

import "this/is/a/bad/path": not a directory

but that isn't being passed higher up the stack. It's alsonot specifying which file (or line) is causing the bad import, which makes it a bit harder for the user to track down the offending line of code.
I tried to figure out a good way to pass along the information to main so it call fatalf out, but nothing came to mind in the bit that I looked at it since there's no error structure set up in place for that section of code. I'd be happy to try to fix it if you're willing to give a bit of guidance, or if you want to fix this yourself I'm totally happy with that as well.

Thanks for reporting this bug, which revision of gb are you using ?

I'm working in this area right now.

I grabbed head as of this morning. https://github.com/constabulary/gb/commit/5217deb25e4ba2962b4212c1f701ebe61383a5f2 to be exact.

Thanks for logging this bug, I think i've cleaned up the worst of the mess.


Error while finetuning

Hi, I am trying to finetune FreeVC-s model with a small dataset formatted in vctk format. I have done necessary changes in config file. I am also not using SR-based augmentation. But when I run train.py it throws me this error.
Traceback (most recent call last):
  File "train.py", line 284, in <module>
    main()
  File "train.py", line 49, in main
    mp.spawn(run, nprocs=n_gpus, args=(n_gpus, hps,))
  File "/usr/local/lib/python3.8/dist-packages/torch/multiprocessing/spawn.py", line 240, in spawn
    return start_processes(fn, args, nprocs, join, daemon, start_method='spawn')
  File "/usr/local/lib/python3.8/dist-packages/torch/multiprocessing/spawn.py", line 198, in start_processes
    while not context.join():
  File "/usr/local/lib/python3.8/dist-packages/torch/multiprocessing/spawn.py", line 160, in join
    raise ProcessRaisedException(msg, error_index, failed_process.pid)
torch.multiprocessing.spawn.ProcessRaisedException:

-- Process 0 terminated with the following error:
Traceback (most recent call last):
  File "/usr/local/lib/python3.8/dist-packages/torch/multiprocessing/spawn.py", line 69, in _wrap
    fn(i, *args)
  File "/content/FreeVC/train.py", line 115, in run
    train_and_evaluate(rank, epoch, hps, [net_g, net_d], [optim_g, optim_d], [scheduler_g, scheduler_d], scaler, [train_loader, eval_loader], logger, [writer, writer_eval])
  File "/content/FreeVC/train.py", line 136, in train_and_evaluate
    for batch_idx, items in enumerate(train_loader):
  File "/usr/local/lib/python3.8/dist-packages/torch/utils/data/dataloader.py", line 628, in __next__
    data = self._next_data()
  File "/usr/local/lib/python3.8/dist-packages/torch/utils/data/dataloader.py", line 1333, in _next_data
    return self._process_data(data)
  File "/usr/local/lib/python3.8/dist-packages/torch/utils/data/dataloader.py", line 1359, in _process_data
    data.reraise()
  File "/usr/local/lib/python3.8/dist-packages/torch/_utils.py", line 543, in reraise
    raise exception
RuntimeError: Caught RuntimeError in DataLoader worker process 3.
Original Traceback (most recent call last):
  File "/usr/local/lib/python3.8/dist-packages/torch/utils/data/_utils/worker.py", line 302, in _worker_loop
    data = fetcher.fetch(index)
  File "/usr/local/lib/python3.8/dist-packages/torch/utils/data/_utils/fetch.py", line 61, in fetch
    return self.collate_fn(data)
  File "/content/FreeVC/data_utils.py", line 164, in __call__
    c_padded[i, :, :c.size(1)] = c
RuntimeError: The expanded size of the tensor (399) must match the existing size (487) at non-singleton dimension 1.  Target sizes: [1024, 399].  Tensor sizes: [1024, 487]

PS: In my dataset few speakers have wav files at 22050 sampling rate , while other speakers wav files are at 32000 sampling rate. But I have used downsample.py to ensure that all of them are sampled down to 16000.

seems that the wavlm feature length is not consistent with spectrogram length.
delete all '.spec.pt' files, make sure the wavs in the wav dir (named as 'DUMMY') are all 16kHz, and run again?

well ,I have .pt files in dataset/wavlm folders (not .spec.pt) which are generated using preprocess_ssl.py (I also confirmed if I am giving downsampled 16K wav folder in --in_dir argument). I'll try excluding folders with different sampling rate to see if that solves the issue

I also had same problem too. Use former version of data_util, train.py will solve those problem

I also had same problem too. Use former version of data_util.py, train.py didn't contain TextAudioSpeakerCollate() will temporarily solve those problem

Thank you , it worked. @OlaWod does using old version of these files effect performance?

I also had same problem too. Use former version of data_util.py, train.py didn't contain TextAudioSpeakerCollate() will temporarily solve those problem

Thank you , it worked. @OlaWod does using older version of these files effect performance?

yes, it has more distortions according to my small scale test.

yes, it has more distortions according to my small scale test.

The model I fine-tuned is messing up the content and pronunciation but voices are really accurate. Do you think using newer version of data_utils would help? or is it simply the case of overfitting?

yes, it has more distortions according to my small scale test.

The model I fine-tuned is messing up the content and pronunciation but voices are really accurate. Do you think using newer version of data_utils would help? or is it simply the case of overfitting?

i think it more likely because of overfitting

yes, it has more distortions according to my small scale test.

The model I fine-tuned is messing up the content and pronunciation but voices are really accurate. Do you think using newer version of data_utils would help? or is it simply the case of overfitting?

https://github.com/OlaWod/FreeVC/issues/57#issuecomment-1426857492
Try this in release version.

Hey , after finetuning , though the voices are more accurate , the content is kind of messed up. But when I run the same conversion without fine tuning (on provided pre-trained models) the content is preserved while the voices are inaccurate.
Do you think more training (finetuning for little longer) would help?
My dataset contains sound files from 10 differ speakers with 2hr duration , is it too less? If not , how many epochs of training is ideal for that?

Hello @MaN0bhiR , how did you end up improving the fine-tuned quality of converted voices? Are 2hrs duration of audios enough for fine-tuning?


Support GridView's numColumn

repositories {
   jcenter()
}

is required ?

Hi,
How can I run the Travis test again?
It says that  "No space left on device
Error: AVD not created."


Custom extension grant seems to work even if clientid / clientsecret are not included in POST data

Not sure if this is a IDS4 bug or just my misunderstanding of how custom extension grants work.  Wrote a custom grant extension and assigned the custom grant type to an identity server client instance.
Was able to call the custom grant validator via HTTP POST even though no clientid or client secret was included in the post data.  Is identity server supposed to enforce custom grant privileges by client or is that the custom grant validator's responsibility?

Please share your logs and also if possible implementation of your custom grant extension.

@osdude can't believe that. Will try to repro. Logs would be useful.

Here is the log file for running against my local workstation.  I will see if I can maybe reproduce the issue against the source code version of identity server (rather than nuget) to see why it works with no clientid.
log-20171116.txt

If you can write an integration test to illustrate the problem (and send it as a PR), that'd be best. That way we can have it as part of our automated test suite.

You seem to be sending the client credentials via basic authentication
2017-11-16 16:48:15.180 -06:00 [DBG] Start client validation
2017-11-16 16:48:15.184 -06:00 [DBG] Start parsing Basic Authentication secret
2017-11-16 16:48:15.184 -06:00 [DBG] Parser found secret: BasicAuthenticationSecretParser
2017-11-16 16:48:15.184 -06:00 [DBG] Secret id found: cid_uaa
2017-11-16 16:48:15.213 -06:00 [DBG] Secret validator success: HashedSharedSecretValidator
2017-11-16 16:48:15.213 -06:00 [DBG] Client validation success

I guess we can close this.

That is strange. Not sure why the fiddler trace shows is showing no clientid or client secret.
Serilog shows no client id as well:
public Task ValidateAsync(ExtensionGrantValidationContext context)
        {
            var accessToken = context.Request.Raw.Get("token");
            var clientid = context.Request.Raw.Get("client_id");

            _logger.LogDebug("UaaGrantValidator start. clientId = {clientId}, ipAddress = {ipAddress}", clientid, _ipResolver.GetAddress().ToString());

2017-11-16 16:48:16.469 -06:00 [DBG] UaaGrantValidator start. clientId = null, ipAddress = ::1

Because they are not in the post body.

Oic, Think i was confused by the documentation :
POST /connect/token

grant_type=delegation&
scope=api2&
token=...&
client_id=api1.client
client_secret=secret

http://docs.identityserver.io/en/release/topics/extension_grants.html

https://tools.ietf.org/html/rfc6749#section-2.3

Thanks for the rfc.  In reading does it show client_id in the body?
POST /token HTTP/1.1
     Host: server.example.com
     Content-Type: application/x-www-form-urlencoded

     grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA
     &client_id=s6BhdRkqt3&client_secret=7Fjfp0ZBr1KtDRbnfVdmIw

Looks like the correct way to get the clientId in the request validator is  to pull from ExtensionGrantValidationContext.    I will change my code.
context.Request.Client.ClientId

thanks


requests.get('https://tagme.d4science.org/tagme/tag‘）error

Hi, I run the code, and found that the program always got error in the follow line. Do you know what happens?

Hi, did you enter your tagme-token in the config?
Regards,
Philipp

On 19. Sep 2022, at 00:35, Lihui Liu @.***> wrote:
Hi, I run the code, and found that the program always got error in the follow line. Do you know what happens?
https://user-images.githubusercontent.com/53407011/190930702-7b0648b9-a1fb-42ae-8552-6c0fc1c06f6d.png
—
Reply to this email directly, view it on GitHub https://github.com/PhilippChr/CONVEX/issues/22, or unsubscribe https://github.com/notifications/unsubscribe-auth/AF3X7MNTUEACFKBWECWYOILV66KMRANCNFSM6AAAAAAQPUET6M.
You are receiving this because you are subscribed to this thread.

Thx. I think the service of TagMe is shut down. Do you know how to solve this problem?

Not really, maybe you could contact them directly.
In case you just need a NERD tool, you could also use:
https://clocq.mpi-inf.mpg.de


Menu Renovation - Part 4: Unification

Split out from #858. This is the big one, and probably the final one. It currently compiles and works, but there's still remaining work, bugs and code quality issues to iron out. See below.
Fixes #749
Fixes #815
Fixes #911
Remaining work:

[x] Fix/Simplify/Unify loading animations
[x] Generalize MenuJob as FilteringJob
[x] Add "hard-coded" keybindings instead of using NotifyKeyPressed
[x] Optional: Open file without closing menu if right arrow is pressed when cursor is at the end of input (mimics vscode)

Known issues:

[x] Jerky loading animations.

Code quality issues:

[ ]  Terminology: "Focus" vs "Select"
[ ] Terminology: "Menu" -> "Quickmenu" or something else? "Smartmenu"?
[x] Terminology: menuCommand -> menuItem
[x] Terminology: Unified name for "Commandline"/"Wildmenu" Edit: Settled on just "Wildmenu"
[x] Using up/down arrow "commits" Wildmenu selection, removing other possible completions from the menu. This is caused by using NotifyKeyPressed which also sends the key press to vim.
Consider abstracting away Ripgrep from RipgrepSubscription as there's no need to hard-code this to a specific technology. Also might be an idea to specialize it as directory search, hard-code the connection to FilterSubscription which then allows hiding the awkward itemStream connection. Edit: Let's wait and see how this will work with workspace search.

Observations:

Ctrl+P menu's listing of files is non-deterministic. Discussion on Discord has suggested that this might be expected behaviour because sorting would disable parallelism.  I think this makes sense for workspace search, but it seems like the wrong trade-off for the Ctrl+P menu. And it would be an easy fix I think, just add --sort path to ripgrep and use a proper LIFO queue instead of a list for the processing queue. See #818
There seems to be quite a bit more "Upshifting into active state" now. Might be because an animation hook is used instead of updating the model and re-rendering everything on Actions.Tick. Unsure if this indicates a problem. Would also be nice to have a more powerful logging framework with proper namespacing and filtering abilities.

I believe all that remains now is a couple of minor terminology issues:

"Focus" vs "select" - Both terms are currently overloaded. "Select" is used both for choosing an item, and partly for the currently highlighted item. "Focus" is used partly for the currently highlighted item and for input focus. Using a term like "choose" instead of "select" would be the easiest way to remove this overloading, but as this term is currently exposed to the user through the "menu.select" keybinding/command it would be a breaking change and should be considered carefully to avoid confusion.

"Menu" vs "Quickmenu" vs "Smartmenu" vs something else? - It's currently just called "Menu", which is incredibly vague. I called it "Quickmenu" in #858, after the QuickOpen menus, but don't think that's a great term. It should ideally be more descriptive, and since it's also exposed to the user through the "menu.*" keybindings/command, ought to be considered carefully as well. Also note that "Wildmenu" is a term used internally, as one kind of "Menu", and is of course also an established vim term. We should take care to avoid confusing these terms as well.

Thanks for all the work here, @glennsl ! I just tried the latest branch and it works great 🎉
Regarding the nomenclature - one constraint that might help us is that, at least for keybinding commands and theme colors - my goal is to have compatibility with VSCode. And they tend to have differentations for these:
list.activeSelectionBackground: List/Tree background color for the selected item when the list/tree is active.
list.activeSelectionForeground: List/Tree foreground color for the selected item when the list/tree is active.
list.dropBackground: List/Tree drag and drop background when moving items around using the mouse.
list.focusBackground: List/Tree background color for the focused item when the list/tree is active.
list.focusForeground: List/Tree foreground color for the focused item when the list/tree is active. An active list/tree has keyboard focus, an inactive does not.
list.highlightForeground: List/Tree foreground color of the match highlights when searching inside the list/tree.
list.hoverBackground: List/Tree background when hovering over items using the mouse.
list.hoverForeground: List/Tree foreground when hovering over items using the mouse

https://code.visualstudio.com/api/references/theme-color#lists-and-trees
(And parallels for their command set).
So in terms of these:

"Select" is used both for choosing an item, and partly for the currently highlighted item.

The VSCode themes seem to use selection to refer to a selected item. This is important in the case of multi-select lists / menus - where you can have multiple items in a 'selection'. Whereas 'select' is used to refer to either:

In a multi-selectable list, adding an item to the 'selection'
In a non-multi-selectable list, 'choosing' the item and running the associated command

"Focus" is used partly for the currently highlighted item and for input focus.

IMO, I think it'd reasonable to use this just for input focus. We'd have to consider . a

Using a term like "choose" instead of "select" would be the easiest way to remove this overloading, but as this term is currently exposed to the user through the "menu.select" keybinding/command it would be a breaking change and should be considered carefully to avoid confusion.

Given the constraint of sticking with VSCode's command conventions - we'll need to stick with "menu.select" - so we'll have to figure out another change to get consistent nomenclature.

"Menu" vs "Quickmenu" vs "Smartmenu" vs something else?

I believe the menu.* commands / theme colors apply to the equivalent VSCode concept, so I'd lean towards sticking with menu. VSCode calls the Control+P experience 'QuickOpen', which is a type of menu, as well as other features like theme picker. So switching seems to take us further away from parity with those concepts.
Hope that helps. Thanks for all your work on this, @glennsl ! The experience has really been leveled up thanks to all you've done!

Thanks for the input @bryphe!

The VSCode themes seem to use selection to refer to a selected item. This is important in the case of multi-select lists / menus - where you can have multiple items in a 'selection'.

That is a very good point. But in the case of multi-selection focus is often used to refer to a specific item in the selection that can be moved with keyboard or pointer input, and will expand or contract the selection relative to the previously focused item (See for example the HTML Selection interface, which also has the concept of an anchor, referring to the where the selection started). So in a single-selection list, is the "selected" item not effectively just indicating the current input focus?

Given the constraint of sticking with VSCode's command conventions - we'll need to stick with "menu.select" - so we'll have to figure out another change to get consistent nomenclature.

👍

I believe the menu.* commands / theme colors apply to the equivalent VSCode concept, so I'd lean towards sticking with menu. VSCode calls the Control+P experience 'QuickOpen', which is a type of menu, as well as other features like theme picker. So switching seems to take us further away from parity with those concepts.

Does vscode have any menu.* commands? I haven't been able to find any.
I think it makes sense for theme colors to apply consistently to all kinds of menus, as it does in vscode on Linux at least. The QuickOpen menu, context menus, menu bar menus and toolbar "overflow" menus are all styled the same on Linux. On macOS everything but QuickOpen uses native menus however.
I also think it makes sense to use menu.* for commands that should apply to all kinds of menus. But should that be the case here? VSCode behaves differently on Linux and macOS. On macOS you can use Ctrl+P/N on both native and QuickOpen menus, but not on Linux.Ctrl+P´ can be used in the QuickOpen menu to scroll down, but will "select" the "focus"ed item when Ctrl` is released, which is interesting behaviour.
But even if we just use menu.* in keybindings/commands and theme colors, we still need to be more specific internally I think, since we're probably going to have at least the same four kinds of menus vscode has.

So in a single-selection list, is the "selected" item not effectively just indicating the current input focus?

I think this is accurate - and consistent with the actions in VSCode bindings (although, I was wrong about menu.select - it doesn't look like there is a binding by default for VSCode, but the equivalent action is workbench.action.acceptSelectedQuickOpenItem).

For reference - there's a richer set of actions for lists (things like the file explorer in VSCode are actually controlled by these list actions:

Does vscode have any menu.* commands? I haven't been able to find any.

 I was mistaken. There are a set of commands for quickOpen (workbench.action.*quickOpen*) - we should be using those instead 👍

I think it makes sense for theme colors to apply consistently to all kinds of menus, as it does in vscode on Linux at least.

Makes sense - I think this is in parity with the theming convention of VSCode (which has menu.* theme colors that apply to all of these, as far as I can tell). Although, there are some separate / additional colors for menubar.*: https://code.visualstudio.com/api/references/theme-color#menu-bar-colors

But even if we just use menu.* in keybindings/commands and theme colors, we still need to be more specific internally I think, since we're probably going to have at least the same four kinds of menus vscode has.

Right, and seems like VSCode is too. Here's an attempt at it (inspired from your suggestion + VSCode's differentiation):

QuickOpen for the Control+P experience (and related ones like theme picker) - what we call Menu today 😬
ContextMenu for the mouse-right-click contextual menu
MenuBar for the top-level menu (we don't have this yet)
Suggest - the auto-complete 'menu'
OverflowMenu- we might be able to re-use context menu for this? But this would correspond to the toolbar overflow menu. I don't see any keybindings or styling specific to this type of menu.

workbench.action.acceptSelectedQuickOpenItem

Wow that's a mouthful!

There are a set of commands for quickOpen (workbench.action.*quickOpen*) - we should be using those instead.

Should we also aim to implement all the list actions? I think that'll be a part 5 if so.

QuickOpen for the Control+P experience (and related ones like theme picker) - what we call Menu today.

That would make WIldmenu a kind of QuickOpen menu. Does that seem intuitive? I'm not entirely sure. Otherwise I think the other suggestions are good.

Looking more closely at the vscode keybindings, it doesn't seem like most workbench.action.*quickOpen* commands are bound. Instead it probably uses the list.* commands, including list.select instead of the mouthful. Not sure why the workbench.action.* commands are needed then. Perhaps they're legacy commands and deprecated?
I also see some different terminology in the when clauses, where it uses inFIlesPicker, inRecentFilesPicker and inEditorsPicker where I've used Buffers and WorkspaceFiles. Not idea what RecentFiles is since it's not bound and quickOpen already order by most recent. Perhaps that's legacy/deprecated too.

Ok, I think this is done!

So stoked to have this in, @glennsl ! Thank you for all the work on this! Very excited to see it land 😎

Ctrl+P menu's listing of files is non-deterministic. Discussion on Discord has suggested that this might be expected behaviour because sorting would disable parallelism. I think this makes sense for workspace search, but it seems like the wrong trade-off for the Ctrl+P menu. And it would be an easy fix I think, just add --sort path to ripgrep and use a proper LIFO queue instead of a list for the processing queue. See #818

Thanks for thinking about this! My only concern is that the --sort flag makes ripgrep much slower - but I'm open to exploring it. There might be ways to improve the experience, for example, run it when a folder is opened so that we have a cached list ready to go (I was thinking about having a separate 'indexer' process - like what SublimeText does).

There seems to be quite a bit more "Upshifting into active state" now. Might be because an animation hook is used instead of updating the model and re-rendering everything on Actions.Tick. Unsure if this indicates a problem.

Appreciate you calling this out. It does seem like there is some state that happens to be changing when the menu is 'idle' - the downside is that this will consume CPU and cause a re-render every frame. We might want to turn off any animations once the search is complete.

Unsure if this indicates a problem.

It's a bug we'll want to fix - it could either be an animation going in the background, or the tick function causing the state to change (which would trigger a re-render). But we can track this separately.

Would also be nice to have a more powerful logging framework with proper namespacing and filtering abilities.

Definitely! Maybe it would make sense to have this in Revery (or even a stand-alone project)

I've just pulled the latest master and see some strange behaviour, not sure if this is related though.
So this is the problem. I'm opening a file with ctrl+p and no navigation/changing modes (basically I can't do anything in the opened file) works at this point for me. To make it work again, I need to open the ctrl+p menu again and then close it again. After this, navigation works again.

@tcoopman Sorry about that. Fixed in #937


Apply the ORDER BY NULL improvement in ac66ae9 to all preaggregation queries

playability.preaggregate_season_card_count() is up to 5 minutes and is another contender for ORDER BY NULL as it makes the Using filesort go away in the explain

playability.preaggregate_card_count() also shows the same difference in EXPLAIN

All of these numbers were hugely improved by the recent change to the innodb_file_buffer setting BUT we'll take all the speed we can get so if this is still gonna help we should still do it. Worth a test at least.


Include sources and symbols in C# nugets

New dotnet SDK doesn't generate symbols package by default.
Also, I've seen report that sources are missing in the nuget packages.
https://github.com/grpc/grpc/issues/9521

Actually, to push the 1.3.0 C# nugets, I used the packages built here.
https://grpc-testing.appspot.com/view/Artifacts/job/gRPC_build_packages/3281/platform=windows/
It's fine because the only change is invoking dotnet pack with --include_source and --include_symbols (and I didn't want to packages that have these missing).


Verify hybrid table contains the same table configs in its both subtype tables

Previously for a hybrid table, it's allowable to have different metadata in table configs, which makes the time column name and type could be different. This leads to an issue that if one single sub-table is queried, the result will be returned. If a query uses raw table name, the result is empty. We should validate the table config before we upload/update it.

Codecov Report

Merging #2986 into master will increase coverage by 10.09%.
The diff coverage is 88.46%.

@@             Coverage Diff             @@
##           master    #2986       +/-   ##
===========================================
+ Coverage   59.76%   69.85%   +10.09%
===========================================
  Files         912      912
  Lines       43341    43366       +25
  Branches     5923     5927        +4
===========================================
+ Hits        25902    30295     +4393
+ Misses      15522    11035     -4487
- Partials     1917     2036      +119

Impacted Files
Coverage Δ

...oller/api/resources/PinotTableRestletResource.java
50.98% <88.46%> (+8.52%)
:arrow_up:

...inot/transport/netty/NettyTCPClientConnection.java
82.31% <0%> (-3.41%)
:arrow_down:

.../com/linkedin/pinot/common/data/TimeFieldSpec.java
91.35% <0%> (ø)
:arrow_up:

.../pinot/core/segment/index/SegmentMetadataImpl.java
81.56% <0%> (+0.7%)
:arrow_up:

...ment/creator/impl/SegmentColumnarIndexCreator.java
88.72% <0%> (+0.75%)
:arrow_up:

...r/transform/function/ValueInTransformFunction.java
39.2% <0%> (+0.8%)
:arrow_up:

.../helix/core/realtime/SegmentCompletionManager.java
69.68% <0%> (+0.9%)
:arrow_up:

...din/pinot/core/realtime/stream/StreamMetadata.java
67.88% <0%> (+0.91%)
:arrow_up:

...e/io/writer/impl/MutableOffHeapByteArrayStore.java
86.45% <0%> (+1.04%)
:arrow_up:

...kedin/pinot/broker/broker/BrokerServerBuilder.java
87.5% <0%> (+1.04%)
:arrow_up:

... and 273 more

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 6be9309...403364d. Read the comment docs.


select_performance - up to n rows

Can we handle the situation where we use up to n rows in select with endselect?
i.e. I don't want to use select single because I can't do order by. So I use select... up to 1 rows order by...
And linter is telling me it's wrong.
Avoid use of ENDSELECT (select_performance) [E]

INTO TABLE

REPORT zfoobar.

DATA bkpf_stru TYPE bkpf.

SELECT * FROM bkpf INTO bkpf_stru
        UP TO 1 ROWS
        ORDER BY bukrs belnr gjahr DESCENDING.
ENDSELECT.

SELECT *
  FROM  bkpf
  UP TO 1 ROWS
  INTO TABLE @DATA(bkpf_tab)
  ORDER BY bukrs belnr gjahr DESCENDING

But one could argue that if you're interested in performance you'd avoid SELECT * 🙂

Why this is a good example, and into structure is bad?

I've added,
* Bad example
SELECT field1, field2 FROM table
    INTO @DATA(structure) UP TO 1 ROWS ORDER BY field3 DESCENDING.
ENDSELECT.

* Good example
SELECT field1, field2 FROM table UP TO 1 ROWS
  INTO TABLE @DATA(table) ORDER BY field3 DESCENDING

there is no need to use ENDSELECT, if you like to use endselect, just disable the rule

Can't we detect the situation when there is "1" in "up to 1 rows"? The whole point of doing "up to 1 rows" is to use structure as output, no a table.

Ok. I believe that you do not agree with me and this won't be changed, so I close the issue.


[bug] fix sharding multimodal

Context
What is the purpose of this PR? Is it to

[ ] add a new feature

[x ] fix a bug

[ ] update tests and/or documentation

[ ] other (please add here)

When sharding a model, we had a function that checked did: layer.split("."), and check if "layer" was at idx=0 and "id" was at idx[1].

Multimodal breaks this rule, by adding decoder.layer.i and encoder.layer.i.

Therefore, layers weren't being properly sharded, greatly increasing the amount of memory necessary

Changelog

updates the rule to look backwards: id has index [-1], layers has index [-2].
Raises value error if no layer is found, so we can minimize the chance of this happening in the future

Test plan
before

now

Codecov Report
Attention: Patch coverage is 0% with 22 lines in your changes missing coverage. Please review.

Project coverage is 70.04%. Comparing base (73aa126) to head (a398d54).
Report is 5 commits behind head on main.

Files with missing lines
Patch %
Lines

recipes/full_finetune_distributed.py
0.00%
6 Missing :warning:

recipes/qat_distributed.py
0.00%
6 Missing :warning:

torchtune/training/_distributed.py
0.00%
4 Missing :warning:

recipes/lora_dpo_distributed.py
0.00%
3 Missing :warning:

recipes/lora_finetune_distributed.py
0.00%
3 Missing :warning:

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1889      +/-   ##
==========================================
- Coverage   70.25%   70.04%   -0.22%
==========================================
  Files         309      309
  Lines       16285    16344      +59
==========================================
+ Hits        11441    11448       +7
- Misses       4844     4896      +52

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Make manage.py test work for the donate app

The goal of this PR is to make the tests run and pass. These can be run as follows:
python manage.py test readthedocs.donate --settings=readthedocs.settings.test

It doesn't look like these tests have been run in a while so perhaps a larger discussion is warranted around do we need these tests at all or should they live with the CI tests in rtd_tests.
Here are some specifics fixes:

fixed import error
removed the footer tests which seem invalid with the v2 api
fixed method names and numbers of params type issues
fixed a few tests logically

Hmm, are these not being run in our CI? Seems like a pretty big oversight -- I believe we have other in-app tests, and those might not be run currently, as well :(

I'd say updating travis to run these would be the only addition here I'd like to see -- that way we can avoid this in the future.

Actually it doesn't look like there are any other significant manage.py tests. There's readthedocs/comments/tests.py but there's nothing really in there. Based on what I can see in a given Travis run it doesn't look like the donate tests are running. It just runs readthedocs/gold/tests and readthedocs/rtd_tests/tests.

It does seem worthwhile to get these into continuous integration. I suspect it's just a config change but I don't know it off the top of my head.

I have added the configuration change necessary to make all the tests run with a simple tox. That's 15 additional tests that will run through CI.

Awesome!


Feature/fs2 backend stability rebase2

This PR is for the end-of-October mid-development release of the FS2 backend.  I caught a cold right before traveling to Ricon, so disease + jetlag made my first rebasing effort a mess of epic proportions.  A squash + rebase worked much better.
The commits to fix EUnit bugs also contain some real bugfixes wrt FS2 fold_objects.  Riak KV's handoff appears to be fully functioning again, yay.
See both of the edited README* files for installation instructions.  No Chef/Puppet thingies have been edited, sorry!

Repo cleanup sweeping.
It seems this PR is stale? I will close it but
please feel free to re-open if I'm too fast :smile:


README.md

Breaking changes

Target date

The motivation for the changes

Possible impact

Virtual environments affected

[x] Ubuntu 16.04
[x] Ubuntu 18.04
[ ] Ubuntu 20.04
[x] macOS 10.13
[ ] macOS 10.14
[x] macOS 10.15
[x] macOS 11.0
[x] Windows Server 2016 R2
[x] Windows Server 2019

Mitigation ways

https://github.com/actions/virtual-environments/issues/2212#issue-758751496


CORE-2494 Updating android and ios dependencies

Updating Android to https://github.com/BranchMetrics/android-branch-deep-linking-attribution/releases/tag/5.0.15
Updating iOS to https://github.com/BranchMetrics/ios-branch-deep-linking-attribution/releases/tag/1.40.2
Bumping Capacitor Core to 3.3.2

@gdeluna-branch very exciting movement! please make sure you also update the CHANGELOG file of this repo so that users can easily check and keep up to date of changes made rather than looking at pull requests etc.
appreciate your work.

@KirstenStake Thanks for pointing that out! I've updated the changelog in https://github.com/BranchMetrics/capacitor-branch-deep-links/pull/52


[Feature Request] Roll with tools

It seems like it should be possible to roll a check with the tools provided to the recipe, in addition to the skill checks already present. Am I missing it? Is it already in the module?
If not, that would be a lovely thing to have.

You are absolutly right i didn't thought about tools can roll !
However this is a bit complex as only one source can currently roll so i would need some time to think it through and then additional time to make it work :-)
I won't make any promisses only that it wont come anytime soon but i will think about how to solve it.

Well, no that will make more problems then it helps. The problem is the ui choices while still supporting legacy.
when you create a recipe you can currently select a skill what if you choose to also select a tool. Which check do you do ?
a) ui disable skill when enable tool or disable tool when enabling skill or both ?
b) is it what everyone is expecting legacy users used a tool as just something that needs to exists on actor they can't do it anymore
c) legacy data there might be recipes that has already both skill and tool those need to be converted.
d) is it at a all either tool or skill ? or should i redesign tool to be optional ! e.g. "When a recipe has a tool and a skill, the users that has the tool rollls on that tool the user not haveing it must roll on the skill.
d2) is tool then required when no skill is defined.
d3) does the user that uses the recipe understands that the skill shown is not for him but he rolls on the tool when he has it.
d4) do i need then also hide the skill from the user that has the tool ?
d5) what if a user that has the tool but is better on the simple skill they want to execute the skill not the tool why should they get punished for haveing a tool ?
d6) do i need to scan the users ability in skill and tool and use whatever is higher.
the actuall coding of rolling a tool item i am pretty sure i can solve somehow. but designing this correctly is not easy.

requested that tools in attendants should also be useable.

done with 3.0.x.
Old tools are gone deprecated since 0.7.x will now be migrated to attendants.
Old skills are deprecated and gets merged to tests.
Tests now can also add tools to test vs them which is not the same as haveing one as attendant. As Attendant you only need to have that item you do not get any rolls for it as it was before.
In Tests you now can set up any skill, ability or tools to test. You can set them up as options for one test you can then choose what option you want to use.


[ramda] .prop() return type should be a non-maybe type

Currently, the return value of of Ramda's .prop() (after currying) is ?T, where T is the type of the values of the object it's getting a property from. I propose that, while sound, this keeps Flow from catching mistakes it could otherwise catch, and that it would be better to type it as T.
There are two cases here: the case where the object (type O) is defined with an indexer property, and the case without.
Without an indexer property, the keys of O are known. Thus, Ramda.prop('foo', {bar: 1}) is an error, because 'foo' does not match the type $Keys<{bar: number}>. Without an indexer property, then, Ramda.prop() can never fail to return a T. Returning ?T, then, requires handling a null/undefined return value which can never occur at runtime.
With an indexer property, Flow doesn't know the keys of O. Thus, Ramda.prop('foo', (o: {[string]: number})) could return undefined if 'foo' is not in that o at runtime. But Flow has already decided that property access for objects with indexer properties is unsafe, and it's the programmer's responsibility to ensure a value exists at the key.
Therefore, I think it makes the most sense for Ramda's .prop() to follow the same pattern as normal property access and return T instead of ?T.
(This change should apply to more versions than the one given, but I'll add them later if I get a thumbs up for this change.)

@Peeja Could you rebase and apply the changes to all the files? IMO this looks good, but I'm no expert so someone else will have to take a look.
@mwalkerwells @mattgstevens Could either of you take a look at this change? I'm out of my element here. 😅  Thanks!

Unless Im missing something, this seems like a reasonable change.
flow will be able to pick up the non-"indexer property" case as expected (either inferred, or with a provided type), and based on the official docs linked the "indexer property" case (which would must have been typed as such) makes further checks needed as this is clearly a very permissive type.
It may have been intended to help in the "indexer property" case, but I don't see the reason to always return a Maybe T here.
@Peeja it would be worthwhile to add a test showing the "bad" behaviour when using prop fn with an O type that has the "indexer property" like you did here:
https://github.com/flowtype/flow-typed/pull/1186/commits/5baa1f0366da912a23a5d921c83a25d931086080#diff-b6649b612997ad895acca2c33510ee73R129

Closed in favour of #1450


aiohttp based asyncio client

I'd like to use this in a Sanic service in our platfrom, however I'm having to use run_in_executor() to use this library without stalling the eventloop.
It would make life faster and easier if this library would also support asyncio.

This is pretty unlikely to happen in this particular library- it's too encumbered by httplib2 and the burden of supporting 2.x it going to make it difficult.
It would be super interesting to see, though. :)

@jonparrott it would be possible to support python 2.x and python 3.x at the same time by using a custom deferred, future or IOAction implementation.

@graingert yeah but at that point we'd have a completely different library.

I don't think it would be that different, a lot of the api classes just transform data without performing further IO.

It's still a lot more than I think this library could take, and a major version bump would cause lots of issues. We went through this exercise with oauth2client and ended up just needing to write a new library altogether. This library is really old, has a lot of old idioms, and is very tied to the way its http library does things. It's just not something we can commit any time to here.
We're largely investing in the new google-cloud-python library. I'd suggest requesting this feature there. Alternatively, this is open source so you're free to make an async fork - but you'd be better off starting from scratch. :)

@jonparrott https://github.com/GoogleCloudPlatform/google-cloud-python/issues/3103

I came across this question when I was looking an asynchronous library for Google Analytics. My message is off topic a little bit, but maybe it helps to someone. We created an asynchronous client for Google Analytics (measurement protocol) and it can be found here: https://github.com/wikibusiness/aioga. It very simple for now, but in nearest future, we plan to expand it.

@jonparrott @froosty let me know if you ever find an async client.  We have a lambda that users google APIs so doing as many calls as possible in parallel would be nice.  Looks like there are some oauth clients so that can help.


Add an application stub for component containers

I could be misreading this issue (please correct me if I am wrong), but it is now straightforward to stub items in component integration tests:
moduleForComponent('adsfa', {
  integration: true,
  beforeEach() {
    this.register('application:main', {});
  }
});

I'm going to consider this closed.  Again, let me know if I have mis read.

@rwjblue that very well could be it. TBH I don't recall


Email Address - Markdown Link

In this PR, the following functionalities have been added

mailto link in CODE_OF_CONDUCT.md

ref: https://github.com/AccessibleForAll/Support/pull/19#pullrequestreview-1018794338
Thanks for the feedback!
The mailto clause is a special clause that opens up the default mail program, which is why there is no space in the link. (ref: https://css-tricks.com/snippets/html/mailto-links/) If we replace mailto with mail to, the link would be invalid and hence defeating the purpose of the PR.
~Vijay

Thanks @vijay-jaisankar 👍


fix(Configuration Governance): update service after API changes

PR summary
Updates Configuration Governance service after recent API changes.
PR Checklist
Please make sure that your PR fulfills the following requirements:

[ ] The commit message follows the Angular Commit Message Guidelines.
[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)

PR Type

[ ] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] New tests
[ ] Build/CI related changes
[ ] Documentation content changes
[ ] Other (please describe)

What is the current behavior?

What is the new behavior?

Does this PR introduce a breaking change?

[ ] Yes
[ ] No

Other information

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Handle PROCSIG_BARRIER

Set SIGUSR1 handler explicitly and call CHECK_FOR_INTERRUPTS() after resetting Latch.
Currently bg_mon doesn't handle SIGUSR1 at all, which wasn't a problem until https://github.com/postgres/postgres/commit/4eb2176 appeared. It means that unless we handle PROCSIG_BARRIER drop tablespace/database can not work correctly.
procsignal_sigusr1_handler is automatically set for a bgworker that defines BGWORKER_BACKEND_DATABASE_CONNECTION flag, however it is not done in bg_mon for a reason.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

2 of 2 (100.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.2%) to 88.738%

Totals

Change from base Build<PHONE_NUMBER>:
0.2%

Covered Lines:
1694

Relevant Lines:
1909

💛  - Coveralls

:+1:

👍


[FUZZ] Beaconfuzz_v2 crash-2cf82c9a6bf1e6e9e0609d767f4ea582defd9cf3 in proposer_slashing

I've done and provided the following:

[x] Checked to see if any other [FUZZ] issue already refers to that crasher
[x] Attached the crashing input (either attached to the issue as a .zip or .gz, or as a link to a file sharing service)
[x] Noted the beacon-fuzz version or commit used.
[x] Provided crash output
[x] Noted the command or fuzzer used to generate the crash
[x] Name of the original crash file
[x] (Optional but optimal) Checked if the crash can be consistently replicated by re-running the input.

Info to Reproduce

Command run: e.g. make fuzz_proposer_slashing-struct

Crasher file name: crash-2cf82c9a6bf1e6e9e0609d767f4ea582defd9cf3
2cf82c9a6bf1e6e9e0609d767f4ea582defd9cf3.zip

Client exercised: prysm(?)

Fuzzing engine used (if applicable): libfuzzer

Crash output and stacktrace
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Traceback (most recent call last, using override)
/root/nim-beacon-chain/vendor/nimbus-build-system/vendor/Nim/lib/system/excpt.nim(614) signalHandler
SIGABRT: Abnormal termination.
==198825== ERROR: libFuzzer: fuzz target exited
    #0 0x55d3b12ba901  (/root/beacon-fuzz/beaconfuzz_v2/fuzz/target/x86_64-unknown-linux-gnu/release/struct_proposer_slashing+0xc5e901)
    #1 0x55d3b371f690  (/root/beacon-fuzz/beaconfuzz_v2/fuzz/target/x86_64-unknown-linux-gnu/release/struct_proposer_slashing+0x30c3690)
    #2 0x55d3b372a4db  (/root/beacon-fuzz/beaconfuzz_v2/fuzz/target/x86_64-unknown-linux-gnu/release/struct_proposer_slashing+0x30ce4db)
    #3 0x7f686f797a26  (/lib/x86_64-linux-gnu/libc.so.6+0x49a26)
    #4 0x7f686f797bdf  (/lib/x86_64-linux-gnu/libc.so.6+0x49bdf)
    #5 0x55d3b152ae17  (/root/beacon-fuzz/beaconfuzz_v2/fuzz/target/x86_64-unknown-linux-gnu/release/struct_proposer_slashing+0xecee17)
    #6 0x7f686f79420f  (/lib/x86_64-linux-gnu/libc.so.6+0x4620f)
    #7 0x7f686f79418a  (/lib/x86_64-linux-gnu/libc.so.6+0x4618a)
    #8 0x7f686f773858  (/lib/x86_64-linux-gnu/libc.so.6+0x25858)
    #9 0x55d3b37cfe36  (/root/beacon-fuzz/beaconfuzz_v2/fuzz/target/x86_64-unknown-linux-gnu/release/struct_proposer_slashing+0x3173e36)
    #10 0x55d3b37b8ec5  (/root/beacon-fuzz/beaconfuzz_v2/fuzz/target/x86_64-unknown-linux-gnu/release/struct_proposer_slashing+0x315cec5)
    #11 0x55d3b36ee936  (/root/beacon-fuzz/beaconfuzz_v2/fuzz/target/x86_64-unknown-linux-gnu/release/struct_proposer_slashing+0x3092936)
    #12 0x55d3b37c01d7  (/root/beacon-fuzz/beaconfuzz_v2/fuzz/target/x86_64-unknown-linux-gnu/release/struct_proposer_slashing+0x31641d7)
    #13 0x55d3b15e6024  (/root/beacon-fuzz/beaconfuzz_v2/fuzz/target/x86_64-unknown-linux-gnu/release/struct_proposer_slashing+0xf8a024)
    #14 0x55d3b15e5bc9  (/root/beacon-fuzz/beaconfuzz_v2/fuzz/target/x86_64-unknown-linux-gnu/release/struct_proposer_slashing+0xf89bc9)
    #15 0x55d3b15e5ec4  (/root/beacon-fuzz/beaconfuzz_v2/fuzz/target/x86_64-unknown-linux-gnu/release/struct_proposer_slashing+0xf89ec4)
    #16 0x55d3b15eec4c  (/root/beacon-fuzz/beaconfuzz_v2/fuzz/target/x86_64-unknown-linux-gnu/release/struct_proposer_slashing+0xf92c4c)
    #17 0x55d3b15efc7c  (/root/beacon-fuzz/beaconfuzz_v2/fuzz/target/x86_64-unknown-linux-gnu/release/struct_proposer_slashing+0xf93c7c)
    #18 0x55d3b141719f  (/root/beacon-fuzz/beaconfuzz_v2/fuzz/target/x86_64-unknown-linux-gnu/release/struct_proposer_slashing+0xdbb19f)
    #19 0x55d3b135bd48  (/root/beacon-fuzz/beaconfuzz_v2/fuzz/target/x86_64-unknown-linux-gnu/release/struct_proposer_slashing+0xcffd48)
    #20 0x55d3b36ee960  (/root/beacon-fuzz/beaconfuzz_v2/fuzz/target/x86_64-unknown-linux-gnu/release/struct_proposer_slashing+0x3092960)
    #21 0x55d3b36ee5bf  (/root/beacon-fuzz/beaconfuzz_v2/fuzz/target/x86_64-unknown-linux-gnu/release/struct_proposer_slashing+0x30925bf)
    #22 0x55d3b372a93c  (/root/beacon-fuzz/beaconfuzz_v2/fuzz/target/x86_64-unknown-linux-gnu/release/struct_proposer_slashing+0x30ce93c)
    #23 0x55d3b3732920  (/root/beacon-fuzz/beaconfuzz_v2/fuzz/target/x86_64-unknown-linux-gnu/release/struct_proposer_slashing+0x30d6920)
    #24 0x55d3b37332dc  (/root/beacon-fuzz/beaconfuzz_v2/fuzz/target/x86_64-unknown-linux-gnu/release/struct_proposer_slashing+0x30d72dc)
    #25 0x55d3b37356df  (/root/beacon-fuzz/beaconfuzz_v2/fuzz/target/x86_64-unknown-linux-gnu/release/struct_proposer_slashing+0x30d96df)
    #26 0x55d3b36fc9b9  (/root/beacon-fuzz/beaconfuzz_v2/fuzz/target/x86_64-unknown-linux-gnu/release/struct_proposer_slashing+0x30a09b9)
    #27 0x55d3b12374b6  (/root/beacon-fuzz/beaconfuzz_v2/fuzz/target/x86_64-unknown-linux-gnu/release/struct_proposer_slashing+0xbdb4b6)
    #28 0x7f686f7750b2  (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
    #29 0x55d3b123765d  (/root/beacon-fuzz/beaconfuzz_v2/fuzz/target/x86_64-unknown-linux-gnu/release/struct_proposer_slashing+0xbdb65d)

SUMMARY: libFuzzer: fuzz target exited
MS: 1 CrossOver-; base unit: 2795b286363280c36284a983987d874d4fa7a0cb
artifact_prefix='/root/beacon-fuzz/beaconfuzz_v2/fuzz/artifacts/struct_proposer_slashing/'; Test unit written to /root/beacon-fuzz/beaconfuzz_v2/fuzz/artifac                                                                                ts/struct_proposer_slashing/crash-2cf82c9a6bf1e6e9e0609d767f4ea582defd9cf3

────────────────────────────────────────────────────────────────────────────────

Failing input:

        fuzz/artifacts/struct_proposer_slashing/crash-2cf82c9a6bf1e6e9e0609d767f4ea582defd9cf3

Output of `std::fmt::Debug`:

        ProposerSlashing {
            signed_header_1: SignedBeaconBlockHeader {
                message: BeaconBlockHeader {
                    slot: Slot(74),
                    proposer_index: 0,
                    parent_root: 0x000000000000002f2f2f2f2f2f2f2f2f2f2f2f2f2f2f2f2f2f2f2f2f2f2f2f2f,
                    state_root: 0x2f2f2f2f2f2f2f2f2f2f2f2f2f2f2f2f2f2f2f2f2f2f2f2f2f2f2f2f2f2f2f2f,
                    body_root: 0x2f2f2f2f2f0000000a000000000000000000000100000000000075757514bbbb,
                },
                signature: 0xa1baa9d1823b4965b4e4584a12b453c89b88b47b0c7aed40a2cf2d5f094f09dbe15400024eac0000460175757515111005b43e5428b6e7fead6e6a0428ee4672                                                                                40bd8f5d575c7cc42daa3d9941294503294c000930b40001ea0700000077ca53,
            },
            signed_header_2: SignedBeaconBlockHeader {
                message: BeaconBlockHeader {
                    slot: Slot(74),
                    proposer_index: 0,
                    parent_root: 0x000000000000002f2f2f2f2f2f2f2f2f2f2f2f2f2f2f2f2f2f2f2f2f2f2f2f2f,
                    state_root: 0x2f2f2f2f2f2f2f2f2f2f2f2f2f2f2f2f2f2f2f2f2f2f2f2f2f2f2f2f2f2f2f2f,
                    body_root: 0x2f2f2f2f2f0000000a000000000000000000000100000000000075757514bbbb,
                },
                signature: 0xa1baa9d1823b4965b4e4584a12b453c89b88b47b0c7aed4098cf2d5f094f09dbe15e00014eac00004601000000005655000000000075757500000014bbbbbbbb                                                                                bbbbbbbb300000000000560000a0000000000000000000000000000000000075,
            },
        }

Reproduce with:

        cargo fuzz run struct_proposer_slashing fuzz/artifacts/struct_proposer_slashing/crash-2cf82c9a6bf1e6e9e0609d767f4ea582defd9cf3

Minimize test case with:

        cargo fuzz tmin struct_proposer_slashing fuzz/artifacts/struct_proposer_slashing/crash-2cf82c9a6bf1e6e9e0609d767f4ea582defd9cf3

────────────────────────────────────────────────────────────────────────────────

ran ETH2FUZZ_BEACONSTATE=../eth2fuzz/workspace/corpora/beaconstate cargo +nightly fuzz run struct_proposer_slashing fuzz/artifacts/struct_proposer_slashing/crash-2cf82c9a6bf1e6e9e0609d767f4ea582defd9cf3
and got
    Finished release [optimized] target(s) in 0.20s
     Running `fuzz/target/x86_64-unknown-linux-gnu/release/struct_proposer_slashing -artifact_prefix=/root/beacon-fuzz/beaconfuzz_v2/fuzz/artifacts/struct_proposer_slashing/ fuzz/artifacts/struct_proposer_slashing/crash-2cf82c9a6bf1e6e9e0609d767f4ea582defd9cf3`
INFO: Seed:<PHONE_NUMBER>
INFO: Loaded 1 modules   (201115 inline 8-bit counters): 201115 [0x55cfca66ce21, 0x55cfca69dfbc),
INFO: Loaded 1 PC tables (201115 PCs): 201115 [0x55cfca69dfc0,0x55cfca9af970),
fuzz/target/x86_64-unknown-linux-gnu/release/struct_proposer_slashing: Running 1 inputs 1 time(s) each.
Running: fuzz/artifacts/struct_proposer_slashing/crash-2cf82c9a6bf1e6e9e0609d767f4ea582defd9cf3
ERRO[0018] Could not get rough time result: no reply     prefix=roughtime
ERRO[0018] Could not get rough time result: no reply     prefix=roughtime
ERRO[0018] Could not get rough time result: no reply     prefix=roughtime
ERRO[0018] Could not get rough time result: no reply     prefix=roughtime
ERRO[0018] Could not get rough time result: no reply     prefix=roughtime
ERRO[0018] Could not get rough time result: no reply     prefix=roughtime
ERRO[0018] Failed to calculate roughtime offset          error="no valid responses" prefix=roughtime
thread '<unnamed>' panicked at '[PRYSM] Mismatch post', /root/beacon-fuzz/beaconfuzz_v2/libs/prysm/src/proposer_slashing.rs:63:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Traceback (most recent call last, using override)
/root/nim-beacon-chain/vendor/nimbus-build-system/vendor/Nim/lib/system/excpt.nim(614) signalHandler
SIGABRT: Abnormal termination.
==200858== ERROR: libFuzzer: fuzz target exited
    #0 0x55cfc6dd3901  (/root/beacon-fuzz/beaconfuzz_v2/fuzz/target/x86_64-unknown-linux-gnu/release/struct_proposer_slashing+0xcdc901)
    #1 0x55cfc92898e0  (/root/beacon-fuzz/beaconfuzz_v2/fuzz/target/x86_64-unknown-linux-gnu/release/struct_proposer_slashing+0x31928e0)
    #2 0x55cfc929472b  (/root/beacon-fuzz/beaconfuzz_v2/fuzz/target/x86_64-unknown-linux-gnu/release/struct_proposer_slashing+0x319d72b)
    #3 0x7fc5c5b55a26  (/lib/x86_64-linux-gnu/libc.so.6+0x49a26)
    #4 0x7fc5c5b55bdf  (/lib/x86_64-linux-gnu/libc.so.6+0x49bdf)
    #5 0x55cfc704c837  (/root/beacon-fuzz/beaconfuzz_v2/fuzz/target/x86_64-unknown-linux-gnu/release/struct_proposer_slashing+0xf55837)
    #6 0x7fc5c5b5220f  (/lib/x86_64-linux-gnu/libc.so.6+0x4620f)
    #7 0x7fc5c5b5218a  (/lib/x86_64-linux-gnu/libc.so.6+0x4618a)
    #8 0x7fc5c5b31858  (/lib/x86_64-linux-gnu/libc.so.6+0x25858)
    #9 0x55cfc933a336  (/root/beacon-fuzz/beaconfuzz_v2/fuzz/target/x86_64-unknown-linux-gnu/release/struct_proposer_slashing+0x3243336)
    #10 0x55cfc93233c5  (/root/beacon-fuzz/beaconfuzz_v2/fuzz/target/x86_64-unknown-linux-gnu/release/struct_proposer_slashing+0x322c3c5)
    #11 0x55cfc9258b86  (/root/beacon-fuzz/beaconfuzz_v2/fuzz/target/x86_64-unknown-linux-gnu/release/struct_proposer_slashing+0x3161b86)
    #12 0x55cfc932a6d7  (/root/beacon-fuzz/beaconfuzz_v2/fuzz/target/x86_64-unknown-linux-gnu/release/struct_proposer_slashing+0x32336d7)
    #13 0x55cfc7107a64  (/root/beacon-fuzz/beaconfuzz_v2/fuzz/target/x86_64-unknown-linux-gnu/release/struct_proposer_slashing+0x1010a64)
    #14 0x55cfc7107609  (/root/beacon-fuzz/beaconfuzz_v2/fuzz/target/x86_64-unknown-linux-gnu/release/struct_proposer_slashing+0x1010609)
    #15 0x55cfc7107904  (/root/beacon-fuzz/beaconfuzz_v2/fuzz/target/x86_64-unknown-linux-gnu/release/struct_proposer_slashing+0x1010904)
    #16 0x55cfc711068c  (/root/beacon-fuzz/beaconfuzz_v2/fuzz/target/x86_64-unknown-linux-gnu/release/struct_proposer_slashing+0x101968c)
    #17 0x55cfc71116bc  (/root/beacon-fuzz/beaconfuzz_v2/fuzz/target/x86_64-unknown-linux-gnu/release/struct_proposer_slashing+0x101a6bc)
    #18 0x55cfc6f3496f  (/root/beacon-fuzz/beaconfuzz_v2/fuzz/target/x86_64-unknown-linux-gnu/release/struct_proposer_slashing+0xe3d96f)
    #19 0x55cfc6e78d79  (/root/beacon-fuzz/beaconfuzz_v2/fuzz/target/x86_64-unknown-linux-gnu/release/struct_proposer_slashing+0xd81d79)
    #20 0x55cfc9258bb0  (/root/beacon-fuzz/beaconfuzz_v2/fuzz/target/x86_64-unknown-linux-gnu/release/struct_proposer_slashing+0x3161bb0)
    #21 0x55cfc925880f  (/root/beacon-fuzz/beaconfuzz_v2/fuzz/target/x86_64-unknown-linux-gnu/release/struct_proposer_slashing+0x316180f)
    #22 0x55cfc9294b8c  (/root/beacon-fuzz/beaconfuzz_v2/fuzz/target/x86_64-unknown-linux-gnu/release/struct_proposer_slashing+0x319db8c)
    #23 0x55cfc925b7c9  (/root/beacon-fuzz/beaconfuzz_v2/fuzz/target/x86_64-unknown-linux-gnu/release/struct_proposer_slashing+0x31647c9)
    #24 0x55cfc92655c2  (/root/beacon-fuzz/beaconfuzz_v2/fuzz/target/x86_64-unknown-linux-gnu/release/struct_proposer_slashing+0x316e5c2)
    #25 0x55cfc6d504b6  (/root/beacon-fuzz/beaconfuzz_v2/fuzz/target/x86_64-unknown-linux-gnu/release/struct_proposer_slashing+0xc594b6)
    #26 0x7fc5c5b330b2  (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
    #27 0x55cfc6d5065d  (/root/beacon-fuzz/beaconfuzz_v2/fuzz/target/x86_64-unknown-linux-gnu/release/struct_proposer_slashing+0xc5965d)

SUMMARY: libFuzzer: fuzz target exited
────────────────────────────────────────────────────────────────────────────────

Error: Fuzz target exited with exit code: 77

Your Environment

Fuzzer ran: beaconfuzz_v2 libfuzzer struct
Version/Commit used:  04c354b
Operating System and version: Ubuntu 20.04

Thanks, I'm able to reproduce ;)
We are working on the root cause analysis !

This is a great catch from the structural differential fuzzer, thanks for reporting @Daft-Wullie !
After investigating, it turns out that Prysm implements the process_proposer_slashing slightly differently from Lighthouse and Nimbus:
From the eth2-specs repo:
def process_proposer_slashing(state: BeaconState, proposer_slashing: ProposerSlashing) -> None:
    header_1 = proposer_slashing.signed_header_1.message
    header_2 = proposer_slashing.signed_header_2.message

    # Verify header slots match
    assert header_1.slot == header_2.slot
    # Verify header proposer indices match
    assert header_1.proposer_index == header_2.proposer_index
    # Verify the headers are different
    assert header_1 != header_2
    # Verify the proposer is slashable
    proposer = state.validators[header_1.proposer_index]
    assert is_slashable_validator(proposer, get_current_epoch(state))
    # Verify signatures
    for signed_header in (proposer_slashing.signed_header_1, proposer_slashing.signed_header_2):
        domain = get_domain(state, DOMAIN_BEACON_PROPOSER, compute_epoch_at_slot(signed_header.message.slot))
        signing_root = compute_signing_root(signed_header.message, domain)
        assert bls.Verify(proposer.pubkey, signing_root, signed_header.signature)

    slash_validator(state, header_1.proposer_index)

As you can see, for a proposer slashing to be valid, the two block headers must be different (assert header_1 != header_2). A header is defined as the message field in a SignedBeaconBlock (i.e. a BeaconBlockHeader, see relevant SSZ container definition here).
The ProposerSlashing produced by the fuzzer has two same headers, with different BLS signatures. When processing a ProposerSlashing, Prysm compares the SignedBeaconBlockHeader instead of the BeaconBlockHeader:
https://github.com/prysmaticlabs/prysm/blob/b0917db4c79d9ec9c06884539697eb96138b5240/beacon-chain/core/blocks/proposer_slashing.go#L97-L101
As a result, this particular ProposerSlashing is deemed valid by Prysm because the BLS signature verification is disabled on beacon-fuzz (i.e. every BLS signature check always returns true), while Lighthouse and Nimbus rejects it since they perform the check above (assert header_1 != header_2) on the BeaconBlockHeaders.
This discrepancy is not directly exploitable per se, since it would require a malicious actor to be able to produce two different, valid BLS signatures for the same message (BeaconBlockHeader).
Great find nonetheless! The research team added additional test vectors to the specs repository as a result.
Thanks again for reporting this @Daft-Wullie !

Can you elaborate on this? Prysm does check the headers are not equal.
https://github.com/prysmaticlabs/prysm/blob/b0917db4c79d9ec9c06884539697eb96138b5240/beacon-chain/core/blocks/proposer_slashing.go#L82

Actually, I see what you are saying now. Sorry for the noise. Fix PR incoming!


Parity error

Hi, trying to evaluate:
10/-1 gives a parity error.
It solves, this way:
10/(-1)

Looks like it's failing to convert to RPN correctly, which is probably related to an unhandled unary - corner case. Compare the tokens for this example that works:
[ Token { type_: 0, index_: 0, prio_: 0, number_: 10 },
  Token { type_: 0, index_: 0, prio_: 0, number_: 1 },
  Token { type_: 1, index_: '-', prio_: 151, number_: 0 },
  Token { type_: 2, index_: '/', prio_: 52, number_: 0 } ]
      ✓ 10/(-1)

To the tokens for the example that fails:
[ Token { type_: 0, index_: 0, prio_: 0, number_: 10 },
  Token { type_: 2, index_: '/', prio_: 52, number_: 0 },
  Token { type_: 0, index_: 0, prio_: 0, number_: 1 },
  Token { type_: 1, index_: '-', prio_: 51, number_: 0 } ]
      1) 10/(-1)

I think the problem is on line 588, where it sets the priority to 2. It should probably be 5 like the other unary operators, unless there's a reason for it being 2 that I forgot about.
I did a quick test for this case, and that fixed it, but I'll need to do more tests make sure it doesn't break something else.

Thanks for the reply and the suggestion! That fixes the unary - issues (see additional test cases here) but causes Parser.evaluate("-3^x", {x: 4}) to equal 81 instead of -81.
I'm not really up to speed on parsers, so I'm struggling a bit, but here's my current understanding about how it works: This parser sets expected to try to disambiguate the correct interpretation of unary -. It builds up a token stack. Sometimes it sets noperators += 2;. Does that make it an LR(1) parser that looks as much as one token ahead to see what things mean?
If that's the case, does that mean everything here is fundamentally solid and it's just a matter of adding failing test cases and messing with the logic until it's all good? 😄

(I might not be right about that… your code + this fix appears cleaner and closer than the fork I was working with, so there's maybe some progress to be made here debugging… I'll work on this and see if I can come up with something)

That single fix (on the master branch) gives a single failing test — which appears otherwise valid in terms of RPN, so looking to priorities…
[ Token { type_: 0, index_: 0, prio_: 0, number_: 3 },
  Token { type_: 1, index_: '-', prio_: 5, number_: 0 },
  Token { type_: 3, index_: 'x', prio_: 0, number_: 0 }
  Token { type_: 2, index_: '^', prio_: 5, number_: 0 } ]
      1) -3^x

That single fix on the master branch gives this, which isn't quite right:
[ Token { type_: 0, index_: 0, prio_: 0, number_: 3 },
  Token { type_: 1, index_: '-', prio_: 5, number_: 0 },
  Token { type_: 3, index_: 'x', prio_: 0, number_: 0 }
  Token { type_: 2, index_: '^', prio_: 5, number_: 0 } ]
      1) -3^x

It should be 3 x ^ - instead of 3 - x ^, right?

Yes, that's correct, so apparently it is a little more complicated than that. Looking at it more, I think the reason it has a lower precedence than the the other unary operators is so that an expression like -x^2 parses as -(x^2), but sqrt(x)^2 is (sqrt(x))^2. So bumping the ^ operator up to 6, and having the isOp1 and isOp2 functions set tokenprio = 7 might be the way to go.

Also to (kind of) answer your question about it being an LR(1) parser, it's based on the shunting yard algorithm, which I think is equivalent to an LR(1) parser, but it's not really a direct translation. It's been awhile since I've taken a computer science class though, so don't take any of that as absolute truth :)

All good. This makes sense. Every ad hoc parser I've ever written has turned out very badly and looked like some of the forks + fixes were headed (maybe) into ad hoc land, so was just trying to pin down the formalities and convince myself maybe it's just the parameters (precedences, operators) that need modification and not a bunch of random flags and conditions. 😄


Update publish-hugo.md

Fixes yaml indentation
The yaml indentation for the custom hugo steps was wrong.

@BorisWilhelms : Thanks for your contribution! The author(s) have been notified to review your proposed change.

@BorisWilhelms looks good, thanks for your fix :)
#sign-off


Template light

Description:
Pull request in home-assistant.github.io with documentation (if applicable): home-assistant/home-assistant.github.io#2661
Example entry for configuration.yaml (if applicable):
light:
  - platform: template
    lights:
      temp_switch:
        value_template: {{1 == 1}}
        turn_on:
          service: light.turn_on
          entity_id: light.other_light
        turn_off:
          service: light.turn_off
          entity_id: light.other_light
        set_level:
           service: light.turn_on
           data_template: {{brightness}}
        level_template: {{42}}

Checklist:
If user exposed functionality or configuration variables are added/changed:

[x] Documentation added/updated in home-assistant.github.io

If the code does not interact with devices:

[x] Local tests with tox run successfully. Your PR cannot be merged unless tests pass
[x] Tests have been added to verify that the new code works.

I could not figure out how to undo the auto-add and subsequent commit to the polymer submodule, I tried to straighten it out and I may have actually made it worse. I would've just cut a new branch and cherry picked but it was part of a commit that contained useful information

I fixed it! This should be good to go now. @Landrash requested I write a blog post to accompany this but I haven't had a chance to do that yet.

Thanks for your contribution! 🎉


Including i --runInBand flag

Description
Include runInBand option for jest
For more information check:

https://stackoverflow.com/questions/43864793/why-does-jest-runinband-speed-up-tests
https://facebook.github.io/jest/docs/en/cli.html#runinband

Test times
Before
====================================
Test Suites: 110 passed, 110 total
Tests:       506 passed, 506 total
Snapshots:   0 total
Time:        16.569s, estimated 17s
Ran all test suites.
====================================

After
====================================
Test Suites: 110 passed, 110 total
Tests:       506 passed, 506 total
Snapshots:   0 total
Time:        31.331s
====================================

Relates #87

Coverage remained the same at 100.0% when pulling 987932d70fb61e8290b28e6d7163d15d936fe4c8 on MDOR:include-jest-flag-for-integration into fd17be09fc4ca5c61cdaef03c23d4aedefca6c07 on AlgusDark:master.

Nice :+1:


new update?

is it still working for new update guys? if it is then will i get higher chance of getting ban while using this ?

Duplicate of 772 and no

fix: https://github.com/danielkrupinski/Osiris/pull/698


Restoring a model from checkpoint fails with InvalidArgumentError

When using auto save (i.e. providing saver spec) with interval or time steps which are not aligned with the episode length and the agent is not explicitly closed or the process terminates unexpectedly, the model can't be restored from the checkpoints as updating the memory fails with error similar to:
InvalidArgumentError (see above for traceback): Must have updates.shape = indices.shape + params.shape[1:], got updates.shape [30,1], indices.shape [21], params.shape [100,1]
            [[Node: ppo/observe-timestep/store/ScatterUpdate = ScatterUpdate[T=DT_FLOAT, Tindices=DT_INT32, _class=["loc:@ppo/initialize/latest/initialize/state-state"], use_locking=true, _device="/job:localhost/replica:0/task:0/device:CPU:0"](ppo/initialize/latest/initialize/state-state, ppo/observe-timestep/store/mod, ppo/strided_slice, ^ppo/observe-timestep/store/AssignSub)]]

The reason is that the agent is reset upon init, expecting a new episode to start, while the buffer still holds values from the incomplete episode.
Test that demonstrates this: https://github.com/janislavjankov/tensorforce/commit/7879529fc117c0e266581d770c4dae6db1008d06, as well as fix that resets the buffer index.

Thank you for raising this, do you want to create a pr?


Feature Request: More info regarding screensaver

It would be nice if there was an FAQ or How This Works section in the screensaver settings. I know that it pulls random photos from account(s), but I believe there are limitations, does it randomly pull from ALL photos, or only a certain number? Is there any other info that can be provided as to how the screensaver works?

Any updates on adding the FAQ about the screensaver?

It would be nice if there was an option to remove there photoview icon.

FAQ has been created on the main website. This will continue to be updated with other questions people get: http://www.photoviewapp.com/faq


[feature]http manager for core-sdk

Associated modules
vm + context
core-sdk
Description
The user wasm code should have ability to make http requests. So the core-sdk should provide such a host function.
This request needs further discussion. Ideally, only one node instance makes a http request will be perfect.

the impl of the host function provides a handshake: FnOnce(TcpStream) -> impl Future<Output = std::io::Result<(S, C)>> + Send + Sync + 'static to permit complete DH key exchange with deterministic result.


Consolidate notebooks and address source control issues.

Remove old notebooks and consolidate related notebooks where possible. Work out a solution for the data-in-notebooks problem that's making code diffs useless.

Notebooks consolidated as a part of refactoring eddb and removing obsolete/deprecated code. Investigating notebook-to-code-to-notebooks transformations so only python code is checked into git. Notebooks will become a build artifact for deployment.  See: https://code.visualstudio.com/docs/python/jupyter-support-py


Regex lookbehind not working

Description of your problem
Regex lookbehinds seem to be broken. For instance this:
(?<!a)whatever
does not match
whereverwhatever
I have tested it in Sublime text first to ensure I am not missing something, and it works there.
If it is of any help, the lookbehinds seem to work when using (?<!\n)
Versions and main components

Spyder Version: 3.1.4
Python Version: 3.5.2
Qt Version: 4.8.7
PyQt Version: PyQt4  API v2  4.11.4 on Linux
Operating system: Ubuntu 16.04.2 LTS

Dependencies
Please go to the menu entry Help > Optional Dependencies (or
Help > Dependencies), press the button Copy to clipboard
and paste the contents below:
jedi >=0.9.0     :  0.10.2 (OK)
matplotlib >=1.0 :  2.0.2 (OK)
nbconvert >=4.0  :  5.2.1 (OK)
numpy >=1.7      :  1.13.0 (OK)
pandas >=0.13.1  :  0.20.2 (OK)
pep8 >=0.6       :  1.7.0 (OK)
psutil >=0.3     :  3.4.2 (OK)
pyflakes >=0.6.0 :  1.5.0 (OK)
pygments >=2.0   :  2.2.0 (OK)
pylint >=0.25    :  1.7.1 (OK)
qtconsole >=4.2.0:  4.3.0 (OK)
rope >=0.9.4     :  0.9.4-1 (OK)
sphinx >=0.6.6   :  1.6.2 (OK)
sympy >=0.7.3    :  1.0 (OK)

Thanks for reporting. We'll take a look at this after we release Spyder 3.2.

I tested this on https://pythex.org/
It does not work there either. I don't think this is a Spyder issue.


chore: updated nx and removed exposed cloud token -> nx login for remote caching

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Compile tensorflow 1.50 I met a question, could you tell me what version of the library is referenced in the graph below abseil

Sorry, I don't understand the question. What do you mean by "version"?

Sorry, I don't understand the question. What do you mean by "version"?

I found the master of abseil-cpp had remove internal .  it case some question at older tensorflow. I hava sovle it. thank your reply.


pull request for e2e test at 01/03/2017 08:15:12

:white_check_mark: Validation status: passed
For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


com.google.api.services.bigquery.model.TableFieldSchema->com.google.cloud.bigquery.Field conversion issue

Environment details
Library version(s): latest
Steps to reproduce

Do anything that calls com.google.cloud.bigquery.Field.fromPb(TableFieldSchema) with a TableFieldSchema that has a STRUCT type.

Code example
       System.out.println(LegacySQLTypeName.valueOf("STRUCT").equals(LegacySQLTypeName.RECORD)); // false
       System.out.println(LegacySQLTypeName.valueOf("RECORD").equals(LegacySQLTypeName.RECORD)); // true

Explanation

According to the docs com.google.api.services.bigquery.model.TableFieldSchema.type can have the value STRUCT.
Inside the mentioned fromPb this will be called fieldBuilder.setType(LegacySQLTypeName.valueOf(fieldSchemaPb.getType()), subFields);
LegacySQLTypeName.valueOf("STRUCT") will return a newly created LegacySQLTypeName object as the originally registered one is registered with RECORD.
So not this one:

/** A record type with a nested schema. */
  public static final LegacySQLTypeName RECORD =
      type.createAndRegister("RECORD").setStandardType(StandardSQLTypeName.STRUCT);

The com.google.cloud.bigquery.Field.Builder.setType(LegacySQLTypeName, FieldList) method that will be called with the returned LegacySQLTypeName contains a LegacySQLTypeName.RECORD.equals(type) check.
That check will always fail, as new LegacySQLTypeName("RECORD") won't be equal with new LegacySQLTypeName("STRUCT").

Stack trace
Caused by: java.lang.IllegalArgumentException: Only RECORD fields can have sub-fields
	at com.google.cloud.bigquery.Field$Builder.setType(Field.java:159)
	at com.google.cloud.bigquery.Field.fromPb(Field.java:361)

Any additional information below
Regarding a bigger picture, in my opinion every possible value in TableFieldSchema should act as equal objects, if they are just aliases.
For example:
assertEquals(LegacySQLTypeName.valueOf("INTEGER"), LegacySQLTypeName.valueOf("INT64"));
assertEquals(LegacySQLTypeName.valueOf("FLOAT"), LegacySQLTypeName.valueOf("FLOAT64"));
assertEquals(LegacySQLTypeName.valueOf("BOOL"), LegacySQLTypeName.valueOf("BOOLEAN"));
assertEquals(LegacySQLTypeName.valueOf("RECORD"), LegacySQLTypeName.valueOf("STRUCT"));

(vaguely related to https://github.com/googleapis/google-cloud-java/issues/3942)

Hi, com.google.cloud.bigquery.Field.fromPb(TableFieldSchema) cannot be called outside the class since it's not a public method. Could you share what you're trying to accomplish (e.g. code snippet)?
Fundamental equality betweennew LegacySQLTypeName("RECORD") and new LegacySQLTypeName("STRUCT") is not possible since the backend will still send back RECORD any way.
It would help if I know what problem you are trying to solve.

From com.google.api.services.bigquery.model.TableFieldSchema.java:
  /**
   * [Required] The field data type. Possible values include STRING, BYTES, INTEGER, INT64 (same as
   * INTEGER), FLOAT, FLOAT64 (same as FLOAT), NUMERIC, BIGNUMERIC, BOOLEAN, BOOL (same as BOOLEAN),
   * TIMESTAMP, DATE, TIME, DATETIME, INTERVAL, RECORD (where RECORD indicates that the field
   * contains a nested schema) or STRUCT (same as RECORD).
   * The value may be {@code null}.
   */
  @com.google.api.client.util.Key
  private java.lang.String type;

From documentation (https://cloud.google.com/bigquery/docs/reference/rest/v2/tables#tablefieldschema)
type string

Required. The field data type. Possible values include:

STRING
BYTES
INTEGER (or INT64)
FLOAT (or FLOAT64)
BOOLEAN (or BOOL)
TIMESTAMP
DATE
TIME
DATETIME
GEOGRAPHY,
NUMERIC
BIGNUMERIC
RECORD (or STRUCT)

Use of RECORD/STRUT indicates that the field contains a nested schema.

IMO it doesn't matter what the backend sends back at the moment and/or what is the use-case that led to this report. According to the docs/specifications it might contain both STRUCT and RECORD (and INTEGER/INT64, BOOLEAN/BOOL, etc) and the library is unable to properly handle those.

Please feel free to raise a PR with proposed fix. We won't be able to get to this in some time.


Potential use with Google Cardboard for PC games

If this project could be used to stream a video stream from PC towards a VR headset running on on Android or IOS then I'm hoping we could make an open source version of Trinus from it.

That would be awesome but would probably work best with a socket or RTC based stream that could handle higher resolutions and less lag.
I'm planning on implementing more transport layers soon, starting with RTC based streaming.

There's this project I found on the assetstore lately that might give you some ideas may be. Thought I'd share it just in case you have $5 to cash out on it.


new release

Hello,
When a new release to include the fix for "Prevent "a term is constructed, but never used" warning". With more apps supporting OTp 24 this lager issue is more and more visible.
Silviu

JUst tagged and pushed 3.9.2 to hex - thanks for the reminder


[Event Request] Table 5062 Attachment - procedure WizSaveAttachment

Describe the request
procedure WizSaveAttachment()
var
    Attachment2: Record Attachment;
    IsHandled: Boolean;
begin
    IsHandled := false;
    OnBeforeWizSaveAttachment(Rec, IsHandled); //CustPub
    if IsHandled then
        exit;

    with RMSetup do begin
        Get;
        if "Attachment Storage Type" = "Attachment Storage Type"::Embedded then begin
            "Storage Pointer" := '';
            exit;
        end;
    end;

    "Storage Pointer" := RMSetup."Attachment Storage Location";

    CopyAttachmentAsFile(Rec, Attachment2);

    Clear(Rec);
    Rec := Attachment2;
end;

[IntegrationEvent(false, false)]
local procedure OnBeforeWizSaveAttachment(var Attachment: Record Attachment; var IsHandled: Boolean) //CustPub
begin
end;

Additional context
Publisher request marked with //CustPub tag.Internal work item: AB#494004

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.
Build ID: 14693.


Paragraph breaks added in faq_de.json

Suggestion to split up the text in the first accordions with additional paragraph breaks (in the same way as it has already been done in the last accordion), to increase the readability, especially in mobile view.
Removed the only <br> in one paragraph.

Sorry for the late reply. As there was a conflict in the meantime and as the English version was missing, we included the fix in an own commit.
Thanks for reporting! We will close this issue now.
Mit freundlichen Grüßen/Best regards,
SW
Corona Warn-App Open Source Team


Fix schema to include CustomElementDeclaration and CustomElementMixinDeclaration

Fixes https://github.com/webcomponents/custom-elements-manifest/issues/100

Checks in schema.json so we can review changes to it directly
Adds GitHub action to ensure schema.json is built
Adds an example to /examples
Changes CustomElementDeclaration and CustomElementMixinDeclaration to interfaces so they generate named schemas
Adds a test of the example schema

I recommend reviewing each commit separately.

Thanks for the review @sonntag-philipp !

Is it possible to publish the changes to npm? @justinfagnani


Number of characters keeps reducing when scrolling on mobile

The number of characters starts reducing when repeatedly scrolling up and down on mobile. Maybe because of window resize due to chrome mobile address bar collapsing on scroll. How can it be fixed?

@shad-k could you post some screenshots of the case. Can you also confirm it is because of the resize event?
I suppose if this is the case then it is worth checking keyboard appearance as well.

Confirming it happens on chrome mobile - I can replicate it on desktop web by resizing the window height to simulate the mobile address bar collapsing on scroll:


Trigger Redraw Crash

Windows Terminal version
1.21.3231.0
Windows build number
10.0.26335.0
Other Software
No response
Steps to reproduce
Unsure 😅
Expected Behavior
To not crash
Actual Behavior
Access Violation exception, see Watson Bucket 20f45815-12a1-7b5a-eadf-5a6297346f30

internal dupe chain leads to MSFT:54447014,
`ACCESS_VIOLATION_c0000005_Microsoft.Terminal.Control.dll!
Microsoft::Console::VirtualTerminal::StateMachine::ProcessString

and no hits for that on 1.22. @shmuelie  if you use Terminal Preview, does this go away?

 And I typed out such a long message before that...
Here's where we destroy the renderer:
https://github.com/microsoft/terminal/blob/bfab5fde4d09ae138b9a26c8fd8fb071d5f5f193/src/cascadia/TerminalControl/ControlCore.cpp#L227-L233
But during the problematic call we only hold a strong reference to the Terminal, not the ControlCore:
https://github.com/microsoft/terminal/blob/bfab5fde4d09ae138b9a26c8fd8fb071d5f5f193/src/cascadia/TerminalControl/ControlCore.cpp#L197-L201
In other words, the ControlCore gets destroyed while we're holding onto the dysfunctional carcass of a terminal.

and no hits for that on 1.22. @shmuelie if you use Terminal Preview, does this go away?

I've not been able to reproduce it since the first crash so can't say

Just hit it again today on 1.23.3582.0


ci: add fedora33 to rpm builds

Signed-off-by: Rodrigo Rojo<EMAIL_ADDRESS>

Coverage remained the same at 66.08% when pulling 892375af4c72cd511b71fb41794537b280727176 on rrojo/fedora33 into dc66b2d5f3d2f92c54787750b421e43469d2de03 on master.


mock-get-request incompatible with returns: { models: ... } when the models have polymorphic: false

Hi,
We ran into some issues with the following code:
// Factory
import FactoryGuy from 'ember-data-factory-guy';
FactoryGuy.define('carrierBill', {
  polymorphic: false,
  default: {
    type: 'CarrierBill::Something',
  },
});

// Test code
const carrierBill = make('carrierBill');
const carrierBills = [carrierBill]
mockQuery('carrierBill', {
   limit: 50,
   offset: 0,
   'sort[id]': 'desc',
}).returns({ models: carrierBills });

// Later on
carrierBill.get('type')
// Expected output => 'CarrierBill::Something'
// Actual output => 'carrier-bill

After some debugging, I think this line https://github.com/danielspaniel/ember-data-factory-guy/blob/master/addon/mocks/mock-get-request.js#L103 is the reason for this
We changed our test so that it uses (maybe its not the best workaround)
query = mockQuery(...)
query.returns({
  json: query.fixtureBuilder.convertForBuild(
    'carrierBill',
    carrierBills.map((bill) => { return { id: bill.get('id') } })
})

Basically not passing the type in the fixture converter.
Thanks
Ember 2.11.3
Ember data 2.12.2
Ember data factory guy 2.13.7 which is bit behind. I haven't tried the latest version, but given that this code is still the same, I assume the problem is still there.

I guess what you are saying is this:
const carrierBill = make('carrierBill');
carrierBill.get('type'); //=> carrier-bill

Let me try and recreate that in a test, and if I can not, then I will ask you to do that ( in the FG repo ) and send the PR  so I can investigate.
One thing to note is I would do things this way:
FactoryGuy.define('carrier-bill', {
  ....
});
const carrierBill = make('carrier-bill');

since ember-data refers to models as 'carrier-bill' dasherized and not carrierBill . This is probably not the issue, but more of a way to have your setup be properly prepared ( in my opinion )

Ok, that worked for me ( I can not see this issue ) , so you will have to recreate it and make a PR for me to check out, or give me access to your repo?

Thanks @danielspaniel for looking into this.
No, that's not what I meant, it is really going through the mocked response that forces a new value for type after the call has been mocked. Just making is fine.
See https://github.com/danielspaniel/ember-data-factory-guy/blob/master/addon/mocks/mock-get-request.js#L103 =>  type: model.constructor.modelName` but I don't know the code enough to say why the type is forced here.
I'll try to add a failing test showing that.

Ohhhhhhhh .. I get it .. let me check that again

Sorry @gleseur , I can not make a failing test in the factory guy repo. if you can, let me know, or try latest factory guy? maybe that fixes it for some mysterious reason?

@danielspaniel See https://github.com/danielspaniel/ember-data-factory-guy/pull/321 with a failing test and a possible fix.
Though I'm a bit doubtful about the fact that this is the rignt fix

Thanks for the issue. That was a great bug and you found the solution.
This is fixed now in  => v2.13.19

Well, Thank you @danielspaniel  for your great work on this lib, we've been using it for a while now and it's been so useful in our test suite. I'm glad I was of some help.


[BUG] Typo in tsduck User's guide

Bug description:
There is a mistake in the manual tsduck.docx and tsduck.pdf for stats plugin on page 366.
How to reproduce:
Usage
tsp -P pids [options]
Expected behavior:
Usage
tsp -P stats [options]

Hi @bojanra,
Thanks for reporting this. Silly typo indeed. This is fixed.


Remove tedge_apama_plugin

Hi there, with Apama 10.15 we now ship an Apama plugin built into the Debian packages we ship to support thin-edge.io. For now the package will seamlessly replace the current plugin if it's installed, but you can remove it from your repository at your convenience for any new releases.

@mjj29 great, thanks for the information. Though do we still need to support the plugin for installations running older versions, e.g. < 10.15?

Yes you would need to - although prior to 10.15 that was an unsupported as-is offering, with 10.15 it's now officially supported, so I don't think we need to leave it for long - people can be pushed to upgrade to 10.15 if necessary.


vendor: Upgrade github.com/optiopay/kafka

Signed-off-by: Romain Lenglet<EMAIL_ADDRESS>

This PR pull in this Kafka parser fix: https://github.com/cilium/kafka/pull/1

It seems like Build 1's K8s tests failed due to kube-apiserver not responding to "get pods" request:
https://jenkins.cilium.io/job/cilium/job/cilium/view/change-requests/job/PR-2280/1/execution/node/35/log/?consoleFull
Started another build.

Got a passing build for this change: https://jenkins.cilium.io/job/cilium/job/cilium/job/PR-2280/2/


chore: bdd-spring-1576169402 to 0.0.1

chore: Promote bdd-spring-1576169402 to version 0.0.1

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approvers:
If they are not already assigned, you can assign the PR to them by writing /assign  in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


[Experimental][JSON-RPC] - RPC Gateway server using paritytech / jsonrpc

closing this in favour of https://github.com/MystenLabs/sui/pull/1256


libnoise

Hi, i realy want to test the voxel generator in unity, but missing the libnoise, can you mail me the .dll or is there another way to obtain it. Want to create a non-profit rts voxel game, and i'm new to programing.

LibNoise.Unity is from https://github.com/ricardojmendez/LibNoise.Unity
Silly me cloned LibNoise.Unity into this repository and staged that, which caused Git to create a submodule that referenced to nowhere.
However that should be fixed now!
LibNoise.Unity is now included as a UPM package in this project.
If you have any further questions, you can ask them here.


Error executing argument parser

Description:
The following code does not work if it is run in hydrogen however works fine when executed in python console.
import argparse
parser = argparse.ArgumentParser()
args = parser.parse_args()

Probably same problem as in this issue.
Steps to Reproduce:

Install WinPython
Install atom and hydrogen
Run the code snippet

Versions:

Windows 10 Pro
WinPython 3.7.0
Atom 1.27.0
Hydrogen 2.1.1

The solution from your link works for me. You can add this snippet or put in your startup code in the hydrogen settings if you always want it to run.
import sys
sys.argv=['']
del sys


useTransition throwing error after attempting to fix memory leak

Issue
Using react V8, I was having a memory leak in my useTransition animations - note - the animations were working, but would timeout after a while. This is an issue I've seen people talk about, and seems to be resolved by installing react-spring@next. I've made that installation, but am facing similar issues to https://github.com/react-spring/react-spring/issues/923. While it seems like it is resolved for them, I am still unable to use useTransition successfully. I attempted to switch to those specific canary versions mentioned in that issue with no luck.
I am wondering if useTransition has been altered so that I am now incorrectly using it. I noticed this issue https://github.com/react-spring/react-spring/pull/809 with updates, but wasn't able to successfully fix the issue.
Error

Currently I am getting this error, with the same code used previously before upgrading react-spring that worked, but with a memory leak.
Expected Behavior
This animation works smoothly without a memory leak.
Reproducible code
const images = [
  {
    key=1,
    url = "url1",
  },
  {
     key=2,
     url = "url2",
  },
  {
    key=3,
    url = "url3",
  },
  {
    key=4,
    url = "url4",
  },
];

 const [slide, setSlide] = useState(0);

  useEffect(() => {
      const interval = setInterval(() => {
        setSlide(state => (state + 1) % images.length);
      }, 4000);
      return () => clearInterval(interval);
  }, []);

  const transitions = useTransition(images[slide], item => item.key, {
    from: {
      x: 1,
    },
    enter: {
      x: 1,
    },
    leave: {
      x: 0,
    },
    unique: true,
    config: { duration: 800 },
  });

{transitions.map(({ item, props, key }, index) => {
          return (
            <animated.div
              style={{
                height: 715,
                transform: interpolate([props.x], v => `scaleY(${v})`),
                transformOrigin: 'top',
                overflow: 'hidden',
                position: marginal && item.order === slide ? 'absolute' : 'relative',
                zIndex: item.order === slide ? -1 : 1,
                top: 0,
                width: useDesk ? (item.order === slide ? '100%' : '100.1%') : '100%',
                right: useDesk ? (item.order === slide ? 0 : 1) : 0,
              }}
              className="slider"
              key={key}
            >
              <animated.div
                style={{
                  transformOrigin: 'top',
                  transform: interpolate([props.x], v => `scaleY(${1 / v})`),
                }}
              >
                <img src="item.url">
              </animated.div>
            </animated.div>
          );
        })
        }

The animation itself is complex, but was working previously.
Environment
<EMAIL_ADDRESS><EMAIL_ADDRESS>

The 2nd argument of useTransition was moved to the keys prop, alongside from, enter, leave, etc.
The return value is now a function. (see the first example in #809)


[Feature Request] Area synchronization with WorldEdit selection

It would be great if the mod could listen to WorldEdit's CUI events and update the area selection based on the current WE selection. This would make it easier to make precise adjustments, and allow the (optional) use of the WE selection tool, which many people are already familiar with.
Related: WorldEditCUI mod

I am genuinely somewhat confused where the real value with this originates. While I can appreciate that it's potentially redundant to manage two separate selection boxes, I don't see why you would want them to match up either. Both of these tools serve fundamentally different purposes and in my experience you update your WorldEdit selection much more frequently than the Isometric one as you make edits and then only select the final result for rendering once or twice.
I'd appreciate some concrete examples of when this is useful (and how often this would occur), because it's not impossible there are usage patterns where this genuinely makes sense that I'm not aware of
Cheers

Thank you for the reply, it made me realize that I didn't fully think this through, originally.
Since I have WorldEditCUI installed on my setup, I already have a selection box in my world for that, and if the two were synchronized, they would just overlap, reducing screen clutter and making it easier (for me, who is very familiar with worldedit selections) to adjust the bounding box.
What I did not consider is that people without WorldEditCUI would just see the isometric-renders selection bouncing around with their WE actions, which is obviously not intended, especially if they already framed the area that they want to render already and are making just a few last adjustments with WE.
My updated suggestion to consolidate these thoughts is that rather than synchronizing the two fundamentally different areas, there could be a subcommand similar to /isorender area worldedit which would be similar to /isorender area x1 y1 z1 x2 y2 z2, but ask WorldEdit (if available) for the current bounding box instead. This would give users the flexibility of the WorldEdit selection if they want it, while also leaving the two area selections separate for their specific purposes. I also imagine that it would be easier to implement ^^

I do agree that having the option to copy the selection from WorldEdit when appropriate could be useful, I'll look into implementing it once I get the time
Cheers

The real value of this proposal is the non cuboid selections in WorldEdit. When trying to render parts of a larger structure, the cuboid selection often lacks the fine grain control the poly selection offers for example.


Added maven profiles to build an uber jar.

Added Maven profiles for building an uber JAR using the Maven Assembly and Maven Shade plugins. Note that to support the uber JAR, GraalVM version 23.1.2 or later is required, as uber JARs do not work with classpath isolation.

We also need to bump https://github.com/graalvm/polyglot-embedding-demo/blob/main/.github/workflows/main.yml#L15 to 21.0.2


Quick fix error where calling host.fileExists caused vscode to stop services

Patches over #10366.
This is just for until I can debug the real problem.

Closed in favor of #10376