Cannot read property 'scrollToBottom' of undefined

Ionic version:  (check one with "x")
(For Ionic 1.x issues, please use https://github.com/ionic-team/ionic-v1)
[ ] 2.x
[x ] 3.x
[ ] 4.x
I'm submitting a ...  (check one with "x")
[x ] bug report
[ ] feature request
Hello Folks,
I am getting this error "Cannot read property 'scrollToBottom' of undefined" and haven't got a solution to this anywhere, hence this post:
Here is my use case:
I have a custom accordion list, and on click of one of the list (since it will have some content) I want the user not to scroll to the bottom , hence using that property. I have only pasted the relevant code
This is my .ts
import { Component, ViewChild } from '@angular/core';
import { NavController,Platform, Navbar} from 'ionic-angular';
import { ToastController } from 'ionic-angular';
import { NativeStorage } from '@ionic-native/native-storage';
@ViewChild('content') content: any;
constructor(public navCtrl: NavController, private nativeStorage : NativeStorage, private toastCtrl : ToastController, platform : Platform  ) {
// other methods
}
 ionViewDidLoad()
  {
    this.IonAccordion()
  }

IonAccordion(){
    this.accElement = document.getElementsByClassName('ion-accordion-header');
    var i;
     for (i = 0; i < this.accElement.length; i++) {
      console.log(i)
      this.accElement[i].addEventListener("click", function()
      {
        this.classList.toggle("active");
        console.log("click");
        var panel = this.nextElementSibling;
        if (panel.style.maxHeight){
          console.log(panel.style.maxHeight);
          panel.style.maxHeight = null;
        } else {
          panel.style.maxHeight = panel.scrollHeight + "px";
          this.content.scrollToBottom(300);
        }
      });
    }
  }

This is my .html file,

<ion-content #content>
<ion-row>
    <ion-col>

Accordion 1

Accordion content

    </ion-col>
    </ion-row>
<ion-row>
    <ion-col>

Accordion 2

Accordion content

    </ion-col>
    </ion-row>
</ion-content>

Version info

cli packages: (F:\classette\node_modules)
@ionic/cli-plugin-cordova       : 1.6.2
@ionic/cli-plugin-ionic-angular : 1.4.1
@ionic/cli-utils                : 1.7.0
ionic (Ionic CLI)               : 3.7.0

global packages:
Cordova CLI : 7.0.1

local packages:
@ionic/app-scripts : 1.3.7
Cordova Platforms  : android 6.2.3
Ionic Framework    : ionic-angular 3.3.0

System:
Node : v6.10.2
OS   : Windows 10
npm  : 3.10.10

Where's your class definition? Could you please fix the .ts file? I think it's something else there unless you just selected all and copypasted the file


AFN 3.0 Post method body without form boundary

all of the method in @protocol  for us to construct Post method body ,will create [ form boundary] . If I'd like to post body without [form boundary] , It seems impossible?

you can inherit AFJSONRequestSerializer and AFHTTPSessionManager to implementation requirements


move minimize simulator button under simulator

This is a preparation of the pairing button. It is a UI change that should be shipped with micro:bit - pairing button will come later.

only impacts "computer" size

The plan here was to bump the entire editor to the right and show a big unminimize button to the left. ie: move it away from the download button entirely

Correct but that requires more work. For now, I would like to get the change of moving the minize button in the simulator because it will impact most screenshots of the bbc microbit editor. The collapsed state polish can be worked on later.


artifacthub api browser

add an artifacthub api browser that serializes and sanitizes api data.

marked this issue as blocking #125

marked this issue as blocked by #58

marked this issue as blocking #19

added 10m of time spent


On inject, evaluate script directly

I've tried to evaluate with script.textContent, but no success.
What would you recommend instead ?

Can you write an example of what you've tried?
Thanks!
Lucho

Hi @vadimnicolai !
Could you solve the issue?
Cheers!
Lucho

Closed due to lack of activity. If you didn't solved it, please feel free to reopen it :)
Thanks!
Lucho


Added the Project Tools

Project Tools

Added CONTRIBUTING.md guide
Added CI/CD pipeline with GitHub
PR template
Pr-Commit Hooks
Added Project Environment Management via poetry.toml
Added version in package

@deshraj : since you were collaborating on this, can you review this?

Looks good overall. Please resolve the conflicts and incorporate minor comments. ❤


[SPARK-14289][WIP] Support  multiple eviction strategies for cached RDD partitions

What changes were proposed in this pull request?
Currently, LRU is the only eviction strategy for cached RDD partitions in Spark.
This pull request will refactor and add support to multiple eviction strategies, such as FIFO, LFU(WIP), LCS(WIP).
How was this patch tested?
Manual test by set "spark.memory.entryEvictionPolicy" to LRU(default), FIFO or LCS.

Can one of the admins verify this patch?

Thanks for the pull request. Is this actually motivated by a real use case, or just doing it because it might be good to support more than one policy?

@rxin The use case that motivate this is about below.

Java objects consume a factor of 2-5x more space than the “raw” data inside their fields.

Running graphx.LiveJournalPageRank example on a 8 nodes cluster (1 work as Master, each configured with 45GB memory for Spark running in  legacy memory management mode). The dataset (about 30GB) is generated by HiBench, while running 5 iterations, time of each iteration is getting worse and worse.

By analyzing the log file, I realize that it is because memory space for cached RDD is not sufficient, and lots of partition with high recomputing cost is dropped. Recomputing these partitions brought in lots of time.

FIFO can be implemented by initialize entries with LinkedHashMap[BlockId, MemoryEntry[_]](32, 0.75f, false). And even FIFO can get much better performance than LRU.

Storage level such as MEMORY_AND_DISK  may partial solve the problem, but the effect is not very good.

An eviction strategy taken the computing cost into consideration may work well (even in unified memory mode or use the MEMORY_AND_DISK level). Some cost-aware replacement policy already exists in K-V stores, such as GD-Wheel(EuroSys’15).
This PR can be separated to below sub-task.

[ ] Refactor to  support more than one policy (LRU, FIFO, LFU).

[ ] Add a policy that taken the computing cost into consideration.

[ ] Taken serialize and deserialize cost into consideration.

@Earne is something relevant merged in spark 2.0.1, do we have FIFO eviction policy?.
If yes how can I leverage it?

This branch appears to be incomplete. The configuration parameter entryEvictionPolicy does not exist and there is a good chunk of the code that does not do anything.

@Earne, is it still active and any opinion on the comments above? Otherwise, I will propose to close this.

I'm working on my thesis to improve cache management systems. But i don't know anything about Spark! I found this program and I don't know how to even run it. If possible, can someone refer to me a video or steps in order to run this file? If i can see a sample implementation of LRU and know how it's made step by step then I'll be able to implement my own algorithm. I would be very grateful if someone can offer their help!

As best I can tell, the code that was pushed here is incomplete. However, Spark's default cache eviction policy is LRU. You can find the code which performs eviction here. It basically just works by storing all the data in a LinkedHashMap configured to track which elements were accessed most recently.


6.8.3: PKG-INFO is missing License-File entries

The 6.8.3 sdist package at PyPI is missing License-File entries in its PKG-INFO file.  This is regression from version 6.8.2.

I think v6.8.3 was accidentally created with an older version of setuptools. The license files are included in the sdist.
v6.9 will specify a more up to date version of setuptools.


NixOS modules should not set nix store paths or executable names available in PATH in environment variables

Describe the bug
When updating system using nixos-rebuild switch or nixos-rebuild test, environment variables usually are not being updated in running processess and user sessions, and in order for them to be updated, a session relog or system restart would need to happen.
Thus, environement variables could contain outdated store path, and that's the reason why nix store paths should not be used in environment variables and be actively discouraged.
Executable names should not be used in environemt variables too, expected to be always available in PATH. For example, using nix-shell --pure --keep EDITOR where EDITOR environment variable is nvim, may make some software (like ranger file manager) that rely on this variable fail to run executable.
for executables that are present on the system already, /run/current-system/sw/bin directory could be used as an alternative.
for configuration files, /etc directory could be used as an alternative.
I have found that these NixOS modules use nix store paths or executable names in environment variables

nixos/modules/config/shells-environment.nix:142 - store path fcitx5Package
nixos/modules/programs/environment.nix:21 - dependent on executable less being in PATH
nixos/modules/programs/environment.nix:22 - dependent on executable nano being in PATH
nixos/modules/programs/freetds.nix:45 store path pkgs.freetds
nixos/modules/programs/less.nix:118 default value of lessopen has store path pkgs.lesspipe
nixos/modules/programs/neovim.nix:152 - dependent on executable nvim being in PATH - https://github.com/NixOS/nixpkgs/pull/310982
nixos/modules/programs/plotinus.nix:31 - store path pkgs.plotinus
nixos/modules/programs/plotinus.nix:32 - store path pkgs.plotinus
nixos/modules/programs/ssh.nix:342 - default value of askPassword has store path pkgs.x11_ssh_askpass
nixos/modules/programs/vim.nix:23 - dependent on executable vim being in PATH - https://github.com/NixOS/nixpkgs/pull/311114
nixos/modules/services/desktops/gnome/tracker.nix:61 - store path subcommandPackagesTree
nixos/modules/services/editors/emacs.nix:88 - dependent on executable emacseditor being in PATH - https://github.com/NixOS/nixpkgs/pull/311157
nixos/modules/services/misc/disnix.nix:50 - dependent on executable disnix-client being in PATH
nixos/modules/services/network-filesystems/kubo.nix:288 - store path fakeKuboRepo

Steps To Reproduce
Steps to reproduce

Steps to reproduce the behaviour of dependency being in PATH (bash shell is used here, but I am sure it will be reproducible with other shells)

set an environment variable SOMETHING using export command to an executable that you have installed in system - export SOMETHING=nvim
verify that you can run it using environment variable - $SOMETHING
nix-shell -p hello --pure --keep SOMETHING
notice that you cannot run the executable through environment variable - $SOMETHING

Add a :+1: reaction to issues you find important.

When updating system using nixos-rebuild switch or nixos-rebuild test, environment variables usually are not being updated in running processess and user sessions, and in order for them to be updated, a session relog or system restart would need to happen.
Thus, environement variables could contain outdated store path (or even non existing store paths after nix-collect-garbage --delete-old), and that's the reason why nix store paths should not be used in environment variables and be actively discouraged.

This I agree with. We should never put Nix store paths into session env vars.

Executable names should not be used in environemt variables too, expected to be always available in PATH. For example, using nix-shell --pure --keep EDITOR where EDITOR environment variable is nvim, may make some software (like ranger file manager) that rely on this variable fail to run executable.

This I do not agree with. Discovering executables via $PATH is a standard unix mechanism and we should not break it.
nix-shell --pure's explicit purpose is to unset env vars such as $PATH. If the env var was set to an absolute path like you suggest, commands ran inside nix-shell --p nvim -I nixpkgs=... --keep EDITOR would still use editor from the system which I think breaks the principle of least surprise as I'd expect it to use nvim from the shell here. IMHO it is also expected behaviour for software dependant on $PATH to break if $PATH is mangled; that's how it should work.
The difference between the absolute path and exe name is forcing the usage of the system instance of the editor vs. using the one from the current context. Unless we have a very good reason to force the system instance, I think we should do the normal thing and use $PATH.

I'd like to bracket out removing nix store paths from session variables from this issue as it should be uncontroversial. Direct references have no place in a context that may outlive the reference's target; everyone who has used a systems programming language knows that.
There is some nuance on what to replace the store path reference with though: Whether you should use $PATH or an absolute path to the sw bin instead of the store path depends on whether the referenced program should sensibly be available globally or only concerns certain isolated components. In the latter case, an absolute path should be preferred, in the former the exe name.
For instance, fcitx should probably not be available in the gloabl $PATH and not be changed depending on $PATH context as it's more or less a component of the desktop session and should probably not change when entering a nix shell.
As a counter example, the disnix client should be in the $PATH as it's supposed to be invoked by the user and also taken from $PATH as the user may want to be able to override it.
(Disclaimer: I am making assumptions about these two components here.)

environement variables could contain outdated store path (or even non existing store paths after nix-collect-garbage --delete-old)

Are you sure?  My experiment shows that nix-collect-garbage keeps all store paths referenced by environment variables.

Are you sure? My experiment shows that nix-collect-garbage keeps all store paths referenced by environment variables.

Indeed you can check sudo nix-store --gc --print-roots to see which paths have an implicit GC root on them and where it comes from (i.e. a process' env, exe or maps).
Still, such stale references can cause other issues and annoyances like requiring logging out for some changes to actually apply.

environement variables could contain outdated store path (or even non existing store paths after nix-collect-garbage --delete-old)

Are you sure? My experiment shows that nix-collect-garbage keeps all store paths referenced by environment variables.

my bad, this was my bad assumption on how nix behaves.

For instance, fcitx should probably not be available in the gloabl $PATH and not be changed depending on $PATH context as it's more or less a component of the desktop session and should probably not change when entering a nix shell.

for non executable references to the nix store and for executable refrences to the nix store that are not in /run/current_system/sw/bin I had idea to make a new directory under system build, in similar way how etc is, to store symlinks to the nix store, which would stay the same even if those references to nix store after nixos-rebuild test would be updated.

for non executable references to the nix store and for executable refrences to the nix store that are not in /run/current_system/sw/bin

That's actually a good point; those can exist. Executables that should be uniform globally but should not be in the global $PATH.
I believe that's what the libexec convention is for, so /run/current-system/sw/libexec/ would be the logical place to put these.

I had idea to make a new directory under system build, in similar way how etc is, to store symlinks to the nix store, which would stay the same even if those references to nix store after nixos-rebuild test would be updated.

This part I don't understand. How would they "stay the same"? Bound by what scope?
The difficulty here is that the first set must get there in some way but a boot is indistinguishable from a subsequent activation (I believe).


Annotation Function for the pseudocode list

Is there a function in lovelace that can add annotation commonly used in algorithm like "// insert x to y"? If no, may I join in and try to find one?

There was something like that in earlier versions but it felt a bit too opinionated. I think that people have widely varying preferences how comments should look in pseudo code, so just build your own. It's not too hard in Typst.


Typing Global Objects?

Sometimes we need to use properties on global objects that haven't been typed for access. For instance, we may import a module dynamically, and then want to access it as a property off of window.
  /* tfjs is loaded dynamically here */
  // ...
  return window.tf; // will cause a typescript error

In cases like these, should we prefer Global Augmentation or avoid the typing situation (like the following)?
  return window['tf'];

This issue came up a few types in a recent PR,.

One way to get around this is to cast to the desired type.
return window['tf'] as TensorFlowThingie;

I think this is possibly a bad example. The only reason tf ends up on Window (or used to) was because it was dictated by the tfjs code itself.
Today, this detail is hidden in platform/tf-web.ts. That module exports and async function called requireTf which returns the needed reference. The use of window is encapsulated as an implementation detail.

Appears resolved in earlier discussion, reopen if further.


build_topic_model_browser.py

i want to run this app build_topic_model_browser.py ,i got this unexpected error ,i noticed two errors "AttributeError: 'str' object has no attribute 'items'" and "TypeError: unhashable type: 'dict'"
Traceback (most recent call last):
File "C:\Users\IBL\AppData\Local\Programs\Python\Python37-32\lib\site-packages\networkx\classes\function.py", line 649, in set_node_attributes
for n, v in values.items():
AttributeError: 'str' object has no attribute 'items'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "build_topic_model_browser.py", line 68, in
utils.save_json_object(corpus.collaboration_network(topic_associations[topic_id]),
File "C:\Users\IBL\Desktop\Topic modelling\TOM\tom_lib\structure\corpus.py", line 153, in collaboration_network
nx.set_node_attributes(nx_graph, 'betweenness', bb)
File "C:\Users\IBL\AppData\Local\Programs\Python\Python37-32\lib\site-packages\networkx\classes\function.py", line 656, in set_node_attributes
G.nodes[n][name] = values
TypeError: unhashable type: 'dict'

Hi,
Could you share more information about the corpus you're studying? Are the author lists specified in the CSV file?
Cheers,
Adrien

hi ,
it 's french_corpus that includes many informations about law  ,legal text ..etc  ,it was cleaned and preproccessed  before i put it in inputs folder ,and the author list isn't specified .
So ,what can i do in this case?
Idris


Initial value incorrect when 'update_input_field_name' is setted

The bond field always gets initial value 5.
This wrong value is set in line 173:
this.value = this.toValue(selected_width * $(base_layer).textWidth());

@debaser The update_input_field_name is used to set a text field that gets updated with the value of the rate once it's changed. If you want to set an initial value for the rater, you have to use the initial_value option. Also, line 173 uses selected_width and that's calculated based on the initial value at line 121. Please let me know if I misunderstood and there's actually a bug there.

Hi!,
Please, test this simple code, and notice that the input value will change
to 5. Thank you

Rater

<input type="text" id="rate" value="2" />

El mar., 9 feb. 2016 a las 0:51, Mohammad A.Raji<EMAIL_ADDRESS>escribió:

@debaser https://github.com/debaser The update_input_field_name is used
to set a text field that gets updated with the value of the rate once it's
changed. If you want to set an initial value for the rater, you have to use
the initial_value option. Also, line 173 uses selected_width and that's
calculated based on the initial value at line 121. Please let me know if I
misunderstood and there's actually a bug there.
—
Reply to this email directly or view it on GitHub
https://github.com/auxiliary/rater/issues/4#issuecomment-181629740.

Here is a simpliest code, better to understand, with the main info isolated:
<input type="text" id="rate" value="2" />

hmm, I see. it should be fixed now. I'll close this issue. If the problem persists please reopen it.


Update the getRuleName function to handle complex rules.

This is a very basic attempt at updating the logic to handle rules with more than one selector. I am not sure if this is enough of a change to handle all different possibilities, (but it worked for my needs!).
I can add some additional tests if you think needed.
thanks again for putting this out there!

Thanks!
If you would be able to publish with a release-candidate version that would
be great. I'd like to start out using this in the wild a bit more but don't
want to fork off my own private version.
/jeremy
On Mon, Jul 10, 2017 at 2:51 PM, Jarrett Widman<EMAIL_ADDRESS>wrote:

Merged #2 https://github.com/vokal/declassify/pull/2.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/vokal/declassify/pull/2#event-1157389224, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ACAh5kzxuQKIEq1Sg25fuITia-jwHrYyks5sMnK4gaJpZM4OS4vF
.

--
Jeremy Blumenfeld
Front-End Engineer
Chartbeat
<EMAIL_ADDRESS>| chart.bt/office


remove test code in docs sync workflow script

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


Section "Set your visual to send data" has wrong instruction in Step 2.

Step 2 says: Replace the content of the ReactCircleCard class, with the following code.
It should say, Add the content of the ReactCircleCard class, with the following code.
If you replace the code, the render() method would get lost and you wouldn't see anything in the visual.

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

ID: abfc5549-16a6-5afd-dac4-64021c25dfa9
Version Independent ID: b8bf0ca1-1f11-bac0-76fa-cfd6a0d1231b
Content: Create a React-based visual for Power BI in Power BI embedded analytics for better embedded BI insights - Power BI
Content Source: powerbi-docs/developer/visuals/create-react-visual.md
Service: powerbi
Sub-service: powerbi-custom-visuals
GitHub Login: @KesemSharabi
Microsoft Alias: kesharab

Thanks for your comment, @KayUnkroth. We’ve forwarded your feedback to the writer, who should respond to this thread shortly. Thanks!

Thanks @KayUnkroth, I've made the update.


v1.21.0-rc.1: service deployment vs docker deployment

Describe the bug
After testing v1.21.0-rc.1 on service deployment - the test mainnet node I found its performance is clearly better than docker deployment

Service deployment, mesh peer

Docker deployment, mesh peer

Service deployment, attestation validation

Docker deployment, attestation validation

it could be linked to the napi-rs binding #6894 cc @wemeetagain @matthewkeil
Expected behavior
Docker deployment should be as great as service deployment's performance
Steps to reproduce
No response
Additional context
No response
Operating system
Linux
Lodestar version or commit hash
v1.21.0-rc.1

could be the performance of aggregateWithRandomness is not the same between service deployment vs docker deployment due to gc

service deployment is great which is what I see when we deploy the PR branch https://github.com/ChainSafe/lodestar/pull/6894/files#r1687368640

docker deployment, although it has less mesh peers gc is higher

closed via the above PR

hash_tree_root() time is always better on service deployment

this is service deployment on a test mainnet node

this is docker deployment on the stable mainnet node

it's consistent to other types of node. Anyway we're going to go with batch hash which uses a totally different library hashtree #6939


FIX link reference in README.md

change TensorRT-LLM model input specification link reference address.

Hi, @sunjiabin17, thanks for your contributing. We've merged your contribution into code base and will add you into contributor list.


Recurring weekly events are one day earlier

Recurring weekly events are shown one day earlier, at the correct time. The events are loaded from a google calendar.
Any tips how to solve this?
Thanks

There is an update in MagicMirror related to this issue, see https://github.com/MichMich/MagicMirror/issues/2068

I have the same issue - any weekly recurring event is pre-poned by one day since the update of version 2.13.0

I have the same issue - any weekly recurring event is pre-poned by one day since the update of version 2.13.0.
I'm not using Google Calendar but three iCloud calendars (mine, wifes, family)
I just figured out that

I can confirm @wakawalli's report.  I have the exact same issue with a combination of Google and iCloud calendars.

I think it depends on the timezone of the calendar item, in my timezone recurrent items are 2 hours earlier

I have exactly this issue. Has anyone found a (temporary) solution to this?

no .. although I think it is solved in MagicMirror itself..


Libusb with timeout

rebased

https://github.com/andersson/qdl/pull/12
https://github.com/andersson/qdl/pull/11
https://github.com/nullog/qdl/pull/1
to be merged on master

This is unmergable. Proposal for libusb introduction alone is made in #59 .


[Blog Contribution] MicroProfile 6.1 preview in Open Liberty <IP_ADDRESS>-beta

MicroProfile.io WordPress
Hi @aeiras
I can't seem to reopen closed issues so I've created this one from #833 as I think there was some confusion about which draft to edit and my draft was mistakenly edited as the MP6.1 release post (then moved to trash) when it was actually meant to be about the MP6.1 preview available in the recent Open Liberty beta. I've fixed the draft (linked above). Thanks
Social Media Description
Try out MicroProfile 6.1 (Metrics 5.1, Telemetry 1.1, OpenAPI 3.1) in @OpenLibertyIO <IP_ADDRESS>-beta now.
Design Card  (for MicroProfile designer)

[ ]  Minimal requirements highlight the MicroProfiler & the title of the blog

Notes
To help with everything

@lauracowen :) Please take a look at my reply in another ticket copied here. Many thanks for being such an amazing content contributor!

-----
@rstjames,
Please tell us how often the MP.6 announcement blog will be reposted in the 4th quarter.
Automatically, the implementor's blog is already posted within the Release announcement; @lauracowen do you wish 1 independent media post on the blog as well?  You wrote:
Social Media Description
Try out MicroProfile 6.1 (Metrics 5.1, Telemetry 1.1, OpenAPI 3.1) in @OpenLibertyIO <IP_ADDRESS>-beta now.

@aeiras @rstjames If you can do an independent post, that'd be great, please but whatever works. It's a beta/preview so it'd be for people really eager to try things out rather than properly use yet. Thanks.

Say no more, Laura.
@rstjames can you please publish via media the IBM blog that deals with 6.1? Thank you!

Scheduled for Monday next week


chore: use TreeSet for structure members

This PR would be made ready for review once we explore option to retain ordering of members.
Issue #, if available:
Fixes: https://github.com/aws/aws-sdk-js-v3/issues/1683
Description of changes:
use TreeSet to sort structure members in their natural order.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Superceded by https://github.com/awslabs/smithy-typescript/pull/254


What std and mean to use when use the pretrained model

in this repo the default mean and std is the mean of activitynet and the std of kinetics but in your another repo(video-classification-3d-cnn-pytorch) you defaut use std=[1,1,1]in your code,which one is correct?

It seems the pretrained model in these two repo same

There is no resnet34,50 in the link
Do you have a pretraining model tuned in ucf101 or hmdb51? I need it very much, thank you. @caijh23


Add handling of separation options for input types

@RebeccaAnne,
Thanks for your contribution as a Microsoft full-time employee or intern. You do not need to sign a CLA.
Thanks,
Microsoft Pull Request Bot


Fixing shell function one liner's missing line break.

The missing semi-colon was giving me issues. Works fine as a not one liner, and also works fine if you include the semi colon. I figured the second option was probably the better one.

The original one-liner worked in zsh and bash, but I must admit I only checked the updated one in zsh. Sorry about that. :(

Closed via 416d186.


DBeaver 3.6.2 unresponsive executing long text query (MS SQL Server)

Hi,
i don't know if this is somehow related to issue #154 (which seems solved in the last version), i found that DBeaver becomes unresponsive when executing a very long query (8000+ lines) to SQL Server.
The unresponsiveness shows up when clicking/scrolling in the results table.
I attach a thread dump.
thread-dump-3.6.2-big-query.txt
OS: Ubuntu 15.10
Java:
openjdk version "1.8.0_66-internal"
OpenJDK Runtime Environment (build 1.8.0_66-internal-b17)
OpenJDK 64-Bit Server VM (build 25.66-b17, mixed mode)

SQL Server 2014
Regards,
Dario

It is not related to #154. Seems to be a combination of different issues in DBeaver and in SWT - as a result UI freezes during execution of very long queries.
Thanks for report (thread dump was very useful).

Hi, sorry for the delay, i confirm that the problem is fixed in 3.6.3! Thank you very much!


[FR] Add custom information to LogMonitor Events/Conditions

Description
Currently it seems like we can define a default message for new conditions that are introduced.
"conditions": [
        {
                "type": "SomeNodeProblem",
                "reason": "NoProblem",
                "message": "some node problem not seen in the node"
        }
],

However, when rules are defined against this condition, we can only do a regex match for the logs and NPD will report the the matching log as is. In cases where we want to customize the message posted, there is no option to do this.
"rules": [
        {
                "type": "permanent",
                "condition": "SomeNodeProblem",
                "reason": "HaveProblem",
                "pattern": "failed: some node problem regex log"
        }
]

Is it possible to have an additional field to add to the matching log posted to by NPD? It can be a simple static message tha tis concatenated to the matching log message posted to NPD.
"rules": [
        {
                "type": "permanent",
                "condition": "SomeNodeProblem",
                "reason": "HaveProblem",
                "pattern": "failed: some node problem regex log",
                "message": "refer www.foo.com/docs for playbook on how to fix the issue"
        }
]

Type                Status    Reason                Message
------              ------    ------                ------
SomeNodeProblem     True.     HaveProblem.          failed: some node problem regex log; refer www.foo.com/docs for playbook on how to fix the issue

If this request makes sense I am happy to send a pull request to integrate it.

/assign
It seems like a reasonable. 🤔  In addition to matching errors, we should customize and add some info(e.g. : troubleshooting info or other), which will help SRE to solve better.


Skottie causing crashes on Android release build only on Expo SDK 51

We've recently upgrade expo SDK 51 and didn't realise this as it only happened in release build. However, the crash are rather hard to pin-point because the only trace in sentry/crashlytics is [TypeError: undefined is not a function]. It doesn't show at which line and which function, and doesn't point that to skottie at all.
At first I thought it was reanimated issue, then I suspect it to be Skia. Anything that have the Canvas will crash the app instantly. Not until I found this issue..
After replacing all skotie instance with rn-lottie, the issue gone away.
I will try to create a repro tomorrow, if that's needed.

Hi everyone,
I am also experiencing the same issue with react-native-skottie on Android in release mode. I started a new project with the latest Expo SDK 51, and my app crashes at launch with the error below in logcat, but without any specific trace pointing to skottie.
07-27 13:29:50.483 17945 17974 E ReactNativeJS: TypeError: undefined is not a function, js engine: hermes
07-27 13:29:50.484 17945 17974 E ReactNativeJS: TypeError: Cannot read property 'ErrorBoundary' of undefined
07-27 13:29:50.484 17945 17974 E ReactNativeJS:
07-27 13:29:50.484 17945 17974 E ReactNativeJS: This error is located at:
07-27 13:29:50.484 17945 17974 E ReactNativeJS:     in SceneView
07-27 13:29:50.484 17945 17974 E ReactNativeJS:     in RCTView
07-27 13:29:50.484 17945 17974 E ReactNativeJS:     in Unknown
...

After removing skottie usage, the issue was resolved.
Here are my configurations for reference:
Proguard Rules
# react-native-reanimated
-keep class com.swmansion.reanimated.** { *; }
-keep class com.facebook.react.turbomodule.** { *; }

# react-native-skia
-keep class com.shopify.reactnative.skia.** { *; }

# react-native-skottie
-keep class com.skiaskottie.** { *; }

# hermes
-keep class com.facebook.hermes.unicode.** { *; }
-keep class com.facebook.jni.** { *; }

# react-native-svg
-keep public class com.horcrux.svg.** {*;}

#https://github.com/react-native-device-info/react-native-device-info/issues/1607
-keep class com.android.installreferrer.api.** {
  *;
}

#https://github.com/react-native-device-info/react-native-device-info#proguard
-keep class com.google.android.gms.common.** {*;}

# react-native-reanimated
-keep class com.swmansion.reanimated.** { *; }
-keep class com.facebook.react.turbomodule.** { *; }

# expo.modules.kotlin.views.GroupViewManagerWrapper.createViewInstance
# Fatal Exception: java.lang.ClassCastException: android.view.View cannot be cast to android.view.ViewGroup
# https://github.com/expo/expo/issues/20122#issuecomment-1337041362
-keep class expo.modules.** { *; }

package.json
 "dependencies": {
    ...
    "@shopify/react-native-skia": "^1.2.3",
    "expo": "~51.0.18",
    "react": "18.2.0",
    "react-dom": "18.2.0",
    "react-native": "0.74.3",
    "react-native-reanimated": "~3.10.1",
    "react-native-skottie": "^2.1.4",
    ...
  }

any solution?

Same issue for me, see https://github.com/Shopify/react-native-skia/issues/2430#issuecomment-2427764570
Will be moving to lottie-react-native as this breaking production right now.


Copying files when target directory doesn't exist

Would adding an optional param for the copy methods indicating whether or not the directory should be created if it doesn't exist be a worthwhile effort?
For example you have some build task that builds and copies a certain set of files to a target directory in which you want created if it doesn't exist -- currently throws.
example: https://gist.github.com/brettkc/1dc01c16a011014105fc

Well, I think it's good to require the target directory to exist before copying stuff. Prevents a lot of subtle mistakes and keeps the API clean and straight forward.
Better to add a separate alias method for this like CopyFilesAndCreateTargetDirectory (or a less verbose name).
@devlead @gep13: Any opinions about this?

@patriksvensson true, a new alias is probably more appropriate

I'm not totally against it though as long as we make it difficult for the user to accidentally do something wrong :)

@brettkc do you still see this as an issue? If so would you be in a position to supply a PoC PR for review?

I still think it's something worth considering but no, I'm currently not in a position to supply anything on it.

@brettkc no worries, then I'm going to close this for now.


Getting TypeError: getPolyfill is not a function after update

Hello!
After the latest update, I'm seeing an error in my code. It looks like the error is actually coming from array.prototype.foreach but seeing as you recently changed this project to use that code, I figured this is the place to report it. I've added a screenshot of the error below:

whoops, will fix in just a second.

actually, wait, that looks like it should be working just fine. require('./polyfill') loads<EMAIL_ADDRESS>which definitely exports a function.

Is there perhaps something in your webpack or babel config that's transforming dependencies?

The project is a create-react-app project and I haven't messed with any of the webpack or babel config files. It is from a few years ago, so maybe that has something to do with it?

ah, CRA does transpile node_modules. it's entirely possible that's where the issue is, but I'm not really sure - i use the pattern in array.prototype.foreach in dozens of widely used packages, and CRA's never had an issue before. Can you share your babel and webpack configs, just in case?

So I ran it on a fresh CRA install, only installing react-admin, the library that has this as a dependency. I got the same issue with a slightly different stack trace:

Repro steps: run create-react-app test, run yarn add react-admin (or some other package that has a dependency on this), update App.js to add import { Admin } from 'react-admin'; and then <Admin title="test"></Admin>.

Wait, the issue doesn't appear when not using react-admin?

Also, what do you get when you click "view compiled" on the final bit of the stack trace?

Yeah, react-admin is the library my app is using that depends on node-polyglot so I knew I'd be able to use that library to repro the issue.
Here's view compiled

I'm just very confused. Can you try removing react-admin and just installing array.prototype.foreach, and importing/requiring that directly?

Same error unfortunately:

Do you get the same error if you try other es-shim packages, like array.prototype.map or array.prototype.flat? (no need to paste the screenshot if it's the same)

Requiring array.prototype.map and array.prototype.flat works

If it's helpful, the value of getPolyfill is:

ohh hmm, it's pulling the ES Module. Looking into it.

What version of node are you using?

node version is 12.16.3. I get the same error for string.prototype.at.

That's a pretty old version of node 12 - just curious, can you try with node 12.17 or later, which is the one with ESM support? (ideally, latest 12)

I upgraded to 12.22 and then also to 14.17 and got the same error for both.

Released in array.prototype.foreach v1.0.1. Does that fix it?

That did it! Thanks so much for your help!


Tallying On Device

Introduction
This PR introduces tracklength tallying on device. Most tracklength tallies/filters/scores are allowed with a few exceptions that are enforced in the code. @paulromano started the ball rolling on this PR and I just finished it up by cleaning up a few remaining items and ironing out a few small issues here and there.
Changes
The main changes are:

Mapping tally/filter/mesh data
Executing the tallying kernel on the device rather than the host
Adding a tidal flow of tally data to/from device when in the active batches of the simulation.
Removal of tidal flow of particles to/from device that was previously required to do tallying on the host

A few other smaller miscellaneous changes to note:

Simplification of a few compiler presets to leverage inheritance.
Removal of the static_map.cpp file that contained a templated function, as this was causing issues with non-unity build. The function has been moved to the header.
Added a timer for the tallying event. Also changed when the active region timer ends so as to exclude statepoint file I/O costs from that timer.
Active tallies are no longer mapped at program initialization, but rather when tallies are initialized when entering the active phase of the simulation.
The setup_active_tallies() function is now only called once when entering the active phase of the simulation to avoid having to map data multiple times. Previously, this function was called before every batch, which seemed redundant to me (though let me know if there is a use case motivating repeatedly calling this function).

Performance
To validate on-device tallying capabilities, we've also added a set of tally tests to the testing benchmark repository. For the most realistic test problem (HM_large_tally) on a single A100 GPU, with 20 million particles per batch, we are seeing the below performance (in terms of particles/second):

MPI Ranks
In-Flight Particles per Rank
Inactive
Active

1
8 million
363,038
228,252

2
4 million
370,220
231,118

4
2 million
383,046
232,943

This is about a 37% - 40% slowdown in active batches as compared to inactive. Only about 30% of this slowdown is caused by the tally function directly. The majority of the slowdown is caused by doing depletion XS lookups in the main fuel XS lookup kernel.
There is likely some performance optimization that can be done in the tallying routines as we haven't done anything special with them, however, as they are running so fast it's likely we'll want to focus first on further optimization of the fuel XS lookup routine. In particular, we think we may have lost some performance in that kernel when adding in the ability to do depletion cross section lookups into the XS kernel a few PRs back.
Validation
I have verified that the tally results match with the historical CPU version of OpenMC that this fork is based off of for the smaller tally problems in the set. However, for the very largest problem (HM_large_tally), we do see general divergence after a few million particles are run (which was the case before this PR as well), which is likely caused by small rounding differences in GPU intrinsics. Generally though, I think things are statistically correct as we are getting full reproducibility for all the smaller problems in the testing repository.
Compilers
As of 9/8/2022 there is a one line bug in the nightly build of LLVM that is causing a compiler crash. The fix is known and it should go into LLVM any day now, but for the time being I have a patched version of llvm that works available on JLSE via:
module use /gpfs/jlse-fs0/projects/intel_anl_shared/openmc_data/Modules/modulefiles
module load llvm/sep1_patched

@pshriwise alerted me to an issue with the standard examples/pincell model that was resulting in a seg fault. It looks like for problems that have a tally mesh that's finer than the problem geometry we are overflowing the statically allocated bins_ and _weights static arrays in the FilterMatch object. Their size is controlled by the FILTERMATCH_BINS_WEIGHTS_SIZE macro, and in the case of the examples/pincell model it is a single pincell with a 100x100 tally mesh so a particle will be scoring to many bins in a single tally event. I'm working on fix so that the program will at least alert the user that this is happening. We may also want to consider increasing the size of the macro or perhaps even considering a more complex/general solution that avoids the need for static arrays for this.

Following up on @pshriwise's finding, I've made a change to give us a lot more flexibility in the number of filter matches we allow by default. Previously, each Particle object owned a statically allocated array of FilterMatch objects, each of which had two statically allocated arrays (bins_ and weights) of length FILTERMATCH_BINS_WEIGHTS_SIZE. While we could fix the issue with the examples/pincell model by simply increasing the size of FILTERMATCH_BINS_WEIGHTS_SIZE from 4 to 100, this has the unwanted affect of increasing the Particle object size by 4x.
With the most recent commit, we remove ownership of the FilterMatch objects from the Particle and onto the stack of the tallying kernel. To avoid a lot of refactoring, we still keep the original filter_matches_ field in the Particle object, but convert it from a static array into just a bare pointer. We can then set the pointer to a stack location when entering the tally kernel, i.e.,:
    // Allocate particle FilterMatch array on the stack
    FilterMatch filter_matches[FILTER_MATCHES_SIZE];
    p.filter_matches_ = filter_matches;

    auto filter_iter = FilterBinIter(tally, p);
    auto end = FilterBinIter(tally, true, p.filter_matches_);

By default we will still have only allocate 4 FilterMatch objects, but inside of each FilterMatch we will now allocate space for 125 bins instead of the original default of 4. This allows it to pass the examples/pincell example.
I was worried that this might use up way too much stack memory and result in really poor tally kernel performance, but it does not appear to have had any effect on performance in my testing, so that's good.
I also made some other changes to improve the way we are adding new hits to a given FilterMatch. Previously, all throughout the code, we were doing operations like:
match.bins_[match.bins_weights_length_] = bin;
match.weights_[match.bins_weights_length_] = 1.0;
match.bins_weights_length_++;

which is a lot of repetition for a simple operation, and also makes it a pain to add in any sort of error checking here to see if we are overflowing the size of the static arrays. To make this a little more flexible and cleaner, I added in push_back(int bin, double weight) methods to the FilterMatch class to do the above operation and print an error if too many bins are hit.
In the future we might want to have more robust error checking on device. One idea is maybe to have a global variable that can be set to an error code and then transferred back to the host and checked periodically, but I'll leave that for another PR.

Also -- it looks like the patch went into LLVM so this PR should now work with the nightly build of LLVM.

This is great @jtramm!! Thanks for digging into it. This is a good solution with a pretty minor code change.
I'm wondering, do we know at what point the number of allowed matches does start to impact performance?

I ran a test that allows for 1250 matches on the A100 and this resulted in it running out of memory in the active region. Basically, I think the extra stack data is spilling to global memory, and if there's enough of that it eventually runs out of memory. I was however able to get it running by reducing the number of in-flight particles, but we lose some in performance by doing that.
Currently, we print out the device memory required by the in-flight particle buffer and the tally result buffers so the user has some idea if they're allocating a ton of memory. It would be nice if we could do this with the filter match buffers, but it's tricky as it is stack data so I can't say off-hand how much memory it's going to need, as I'm not totally sure how many blocks will be active on the device at any point in time. It's possible this could be calculated with knowledge of a specific device and how many register spills the compiled kernel has, but I don't think it would be feasible for OpenMC to give an estimate of overall memory usage needed by the matches in a compiler and device agnostic manner. So, for now, I think the 125 hits buffer gives a reasonable balance between not using too much memory but still being able to run a decent variety of problems.
Longer term, I think a better solution for GPU is to restructure the tallying logic to just score one bin at a time in a loop rather than pushing the match hits to some buffer. This may involve some preprocessing steps and would be less algorithmically efficient, but as the tallying kernel is not very expensive the more important thing here seems to be removing all the memory pressure.

I ran a test that allows for 1250 matches on the A100 and this resulted in it running out of memory in the active region. Basically, I think the extra stack data is spilling to global memory, and if there's enough of that it eventually runs out of memory. I was however able to get it running by reducing the number of in-flight particles, but we lose some in performance by doing that.
Currently, we print out the device memory required by the in-flight particle buffer and the tally result buffers so the user has some idea if they're allocating a ton of memory. It would be nice if we could do this with the filter match buffers, but it's tricky as it is stack data so I can't say off-hand how much memory it's going to need, as I'm not totally sure how many blocks will be active on the device at any point in time. It's possible this could be calculated with knowledge of a specific device and how many register spills the compiled kernel has, but I don't think it would be feasible for OpenMC to give an estimate of overall memory usage needed by the matches in a compiler and device agnostic manner. So, for now, I think the 125 hits buffer gives a reasonable balance between not using too much memory but still being able to run a decent variety of problems.
Longer term, I think a better solution for GPU is to restructure the tallying logic to just score one bin at a time in a loop rather than pushing the match hits to some buffer. This may involve some preprocessing steps and would be less algorithmically efficient, but as the tallying kernel is not very expensive the more important thing here seems to be removing all the memory pressure.

Nice! Very interesting. Yeah, since that number is going to be device-specific it's tricky to set to a fixed value. I think 125 should be alright for most problems we're going to see, particularly for the ones we're looking at for milestones here. And since there's now a warning about overflow, we know enough to adjust it for outlier problems. Thanks for trying that out!


[CELEBORN-1245] Support Celeborn Master(Leader) to manage workers

What changes were proposed in this pull request?

Support Celeborn Master(Leader) to manage workers by sending event when heartbeat
Add Worker Status to Worker then we can know the status of the workers(such as during decommission...)
Add Http interface for master to handleWorkerEvent/getWorkerEvent

Why are the changes needed?
Currently, we only support managing the status of workers on the worker side. This pr supports the master to manage the status of all workers. By sending events such as (Decommission/Graceful/Exit) when heartbeat, workers can be asynchronously execute the command from master. MeanWhile we can't know what the worker status during worker decommission so this pr add worker status to tell the exactly status of the worker.
Does this PR introduce any user-facing change?
No
How was this patch tested?
Pass GA

@AngersZhuuuu @SteNicholas @FMX @waitinfuture PTAL.

Thanks, merge to main(v0.5.0)

@RexXiong Shall we add doc describing how to manager workers though master?


Fix the automatical strategy when shared.

The automatical strategy has an issue when shared, it behaves as the
wrong strategy if the matrices using it have different properties.
This fixes this issue only by extending the current interface, and not
changing any existing function. All other (more elegant) approaches
I thought of would break the current interface. In effect:

Add a new virtual copy function to the strategies in order to create
a new shared pointer polymorphically.
The approach used is to always copy the strategy, whenever a CSR
matrix is instantiated or copied. Thankfully, the strategies are
currently light objects so this should create few overhead.
Add tests which ensure that matrices with difference properties work
correctly with the automatical strategy.

Fixes https://github.com/ginkgo-project/ginkgo/issues/426

@yhmtsai I do not understand your issue properly. I think with the current implementation there is no way to change the executor dynamically. If the user wants to use automatical for both AMD and NVIDIA hardware, then he will need to anyway declare two different make_shared<Csr::automatical>(cudaExec) and make_shared<Csr::automatical>(hipExec) to have the proper values. In this case, there should be no issue with copies happening with the wrong values?

Originally, I think the case about amd_csr->copy_from(nvidia_csr) directly.
we do not support copy/move between amd/nvidia, right?
in host matrix -> amd matrix, the host matrix has warp_size = 32 by default. It will pass this to amd_csr, which leads inconsistent warp_size. strategy_rebuild_helper to reset the strategy by executor to make sure that the strategy uses the parameters from executor not others.

@yhmtsai Indeed, so far we do not even support raw_copy_to between AMD hardware and CUDA hardware. I think there would some work required to make it work.
Now I see the issue, I will try to see what I can do for that.

@yhmtsai I should have fixed that issue now. In the end, I put @upsj code from the convert_to<Csr<next_precision...>> into a helper, as that is exactly what needs to be called to fix this issue I believe.
Please tell me if I'm missing anything.

@tcojean I am fine with these changes. I do not have any question in this PR.


mutations

please see my other comment. the solutions need to be named according to the instructions in the README


[F000372] Rep. Rodney Frelinghuysen

Rep. Rodney Frelinghuysen:
http://frelinghuysen.house.gov
Likely contact form URL to start with:
http://frelinghuysen.house.gov/contactus/form.cfm

YMAL file not found. I am working on it.


Get all dead genesis objects

Description
Describe the changes or additions included in this PR.
Test plan
How did you test the new or updated feature?

Release notes
Check each box that your changes affect. If none of the boxes relate to your changes, release notes aren't required.
For each box you select, include information after the relevant heading that describes the impact of your changes that a user might notice and any actions they must take to implement updates.

[ ] Protocol:
[ ] Nodes (Validators and Full nodes):
[ ] Indexer:
[ ] JSON-RPC:
[ ] GraphQL:
[ ] CLI:
[ ] Rust SDK:
[ ] REST API:

This will serve as a reference in case we ever need to run this, but should not be merged.


No joke: I just had the same idea. Can i help in any way?

Hi @wwhtrbbtt, thanks for your proposition ! Any PR is welcome 😃
Right now my bigger concern is to handle tanks "snapping" together (when you put two tank sizes side by side). It should be handled by width_a and width_b. I didn't find yet a nice way to match the game behaviour. Also we need to find  a way to render "trapeze-scaled" snapped tanks and it will be challenging to do this with react-konva !


fatal error: bulkBarrierPreWrite: unaligned arguments (go 1.19.1, looks like regression)

What version of Go are you using (go version)?

$ go version
go version go1.19.1 linux/amd64

Does this issue reproduce with the latest release?
It appears with the latest release (go 1.19.1 at the time of writing), while everything is fine when compiling with go 1.18.6.
The problem is, I can't reproduce it reliably, as I have no testing environment with the same amount of real-life load.
However, while everything is the same, on 1.19.1 I get (1) first crash after 5 hours, (2) second crash after 6 hours, and on 1.18.6 I have 35+ hours without a panic.
More info might eventually appear at https://github.com/lightningnetwork/lnd/issues/6923 if LND developers engage in testing on 1.19
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/akovalenko/.cache/go-build"
GOENV="/home/akovalenko/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/akovalenko/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/akovalenko/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/lib/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.19.1"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/dev/null"
GOWORK=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build1107032562=/tmp/go-build -gno-record-gcc-switches"

What did you do?
I've built the LND project (see https://github.com/lightningnetwork/lnd/issues/6923 for details) and used it under a significant load for several hours.

What did you expect to see?
No panic
What did you see instead?
Two panics in a row, after several hours each, triggered by the same line of seemingly innocent assignment

Sep 15 17:50:53 murphy lnd[2756008]: fatal error: bulkBarrierPreWrite: unaligned arguments
Sep 15 17:50:53 murphy lnd[2756008]: goroutine 10179 [running]:
Sep 15 17:50:53 murphy lnd[2756008]: runtime.throw({0x1c20812?, 0x9ba5f0?})
Sep 15 17:50:53 murphy lnd[2756008]:         runtime/panic.go:1047 +0x5d fp=0xc0024c2930 sp=0xc0024c2900 pc=0x43807d
Sep 15 17:50:53 murphy lnd[2756008]: runtime.bulkBarrierPreWrite(0x0?, 0x40db47?, 0x20?)
Sep 15 17:50:53 murphy lnd[2756008]:         runtime/mbitmap.go:582 +0x428 fp=0xc0024c29a0 sp=0xc0024c2930 pc=0x415068
Sep 15 17:50:53 murphy lnd[2756008]: runtime.typedmemmove(0x1867fc0, 0xc0083db3f1, 0xc0024c2a84)
Sep 15 17:50:53 murphy lnd[2756008]:         runtime/mbarrier.go:162 +0x45 fp=0xc0024c29d8 sp=0xc0024c29a0 pc=0x414245
Sep 15 17:50:53 murphy lnd[2756008]: github.com/lightningnetwork/lnd/lnwire.ReadElement({0x1f7b820, 0xc01151c7b0}, {0x18b19a0?, 0xc0083db3f1?})
Sep 15 17:50:53 murphy lnd[2756008]:         github.com/lightningnetwork/lnd/lnwire/lnwire.go:477 +0x173c fp=0xc0024c2cc8 sp=0xc0024c29d8 pc=0x9b8b5c
Sep 15 17:50:53 murphy lnd[2756008]: github.com/lightningnetwork/lnd/lnwire.ReadElements(...)
Sep 15 17:50:53 murphy lnd[2756008]:         github.com/lightningnetwork/lnd/lnwire/lnwire.go:879
Sep 15 17:50:53 murphy lnd[2756008]: github.com/lightningnetwork/lnd/lnwire.(*NodeAnnouncement).Decode(0x1f7b820?, {0x1f7b820, 0xc01151c7b0}, 0x2?)
Sep 15 17:50:53 murphy lnd[2756008]:         github.com/lightningnetwork/lnd/lnwire/node_announcement.go:112 +0x150 fp=0xc0024c2d88 sp=0xc0024c2cc8 pc=0x9ba8b0
Sep 15 17:50:53 murphy lnd[2756008]: github.com/lightningnetwork/lnd/lnwire.ReadMessage({0x1f7b820, 0xc01151c7b0}, 0x1c8?)
Sep 15 17:50:53 murphy lnd[2756008]:         github.com/lightningnetwork/lnd/lnwire/message.go:314 +0x91 fp=0xc0024c2de8 sp=0xc0024c2d88 pc=0x9ba1b1
Sep 15 17:50:53 murphy lnd[2756008]: github.com/lightningnetwork/lnd/peer.(*Brontide).readNextMessage.func1(0xc003d3c000)
Sep 15 17:50:53 murphy lnd[2756008]:         github.com/lightningnetwork/lnd/peer/brontide.go:1114 +0x146 fp=0xc0024c2e60 sp=0xc0024c2de8 pc=0x164e026
Sep 15 17:50:53 murphy lnd[2756008]: github.com/lightningnetwork/lnd/pool.(*Read).Submit.func1({0x1f87e28?, 0xc002680ca0?})
Sep 15 17:50:53 murphy lnd[2756008]:         github.com/lightningnetwork/lnd/pool/read.go:50 +0x37 fp=0xc0024c2e88 sp=0xc0024c2e60 pc=0x1648557
Sep 15 17:50:53 murphy lnd[2756008]: github.com/lightningnetwork/lnd/pool.(*Worker).spawnWorker(0xc0088eae60, 0xc002680c90)
Sep 15 17:50:53 murphy lnd[2756008]:         github.com/lightningnetwork/lnd/pool/worker.go:232 +0x316 fp=0xc0024c2fc0 sp=0xc0024c2e88 pc=0x1649556
Sep 15 17:50:53 murphy lnd[2756008]: github.com/lightningnetwork/lnd/pool.(*Worker).requestHandler.func2()
Sep 15 17:50:53 murphy lnd[2756008]:         github.com/lightningnetwork/lnd/pool/worker.go:161 +0x2a fp=0xc0024c2fe0 sp=0xc0024c2fc0 pc=0x16491aa
Sep 15 17:50:53 murphy lnd[2756008]: runtime.goexit()
Sep 15 17:50:53 murphy lnd[2756008]:         runtime/asm_amd64.s:1594 +0x1 fp=0xc0024c2fe8 sp=0xc0024c2fe0 pc=0x46c241

This is strange. Copying a NodeAlias, which is just a named [32]byte, shouldn't be calling typedmemmove, it should compile to a pair of 16-byte moves. Even if it called typedmemmove, that function should not call bulkBarrierPreWrite for a pointerless data type like NodeAlias is.
Are you using any special command-line flags when building?

@randall77 surely no special command-line flags from me, seems also nothing special from the build system (just trimpath and other harmless stuff).
While comparing -gcflags -S output, I see:
go 1.18.6:

lightningnetwork/lnd/lnwire/lnwire.go:477)     MOVUPS  "".alias+172(SP), X0
lightningnetwork/lnd/lnwire/lnwire.go:477)     MOVQ    ""..autotmp_1115+384(SP), CX
lightningnetwork/lnd/lnwire/lnwire.go:477)     MOVUPS  X0, (CX)
lightningnetwork/lnd/lnwire/lnwire.go:477)     MOVUPS  "".alias+188(SP), X0
lightningnetwork/lnd/lnwire/lnwire.go:477)     MOVUPS  X0, 16(CX)

go1.19.1:

lightningnetwork/lnd/lnwire/lnwire.go:477)     MOVQ    github.com/lightningnetwork/lnd/lnwire..autotmp_1115+384(SP), BX
lightningnetwork/lnd/lnwire/lnwire.go:477)     TESTB   AL, (BX)
lightningnetwork/lnd/lnwire/lnwire.go:477)     PCDATA  $0, $-2
lightningnetwork/lnd/lnwire/lnwire.go:477)     CMPL    runtime.writeBarrier(SB), $0
lightningnetwork/lnd/lnwire/lnwire.go:477)     JNE     5928
lightningnetwork/lnd/lnwire/lnwire.go:477)     MOVUPS  github.com/lightningnetwork/lnd/lnwire.alias+172(SP), X0
lightningnetwork/lnd/lnwire/lnwire.go:477)     MOVUPS  X0, (BX)
lightningnetwork/lnd/lnwire/lnwire.go:477)     MOVUPS  github.com/lightningnetwork/lnd/lnwire.alias+188(SP), X0
lightningnetwork/lnd/lnwire/lnwire.go:477)     MOVUPS  X0, 16(BX)
lightningnetwork/lnd/lnwire/lnwire.go:477)     JMP     6062
lightningnetwork/lnd/lnwire/lnwire.go:477)     LEAQ    type.github.com/lightningnetwork/lnd/lnwire.OpaqueReason(SB), AX
lightningnetwork/lnd/lnwire/lnwire.go:477)     LEAQ    github.com/lightningnetwork/lnd/lnwire.alias+172(SP), CX
lightningnetwork/lnd/lnwire/lnwire.go:477)     CALL    runtime.typedmemmove(SB)
lightningnetwork/lnd/lnwire/lnwire.go:477)     JMP     6062

(it's my first time with go's assembly output, sorry, I probably should have made it more informative but I don't yet know how).
Looks like much more interesting things happen in 1.19.1 for the same assignment, and somehow there is a branch with typedmemmove.

That does look like a compiler bug. It seems it is trying to assign to a NodeAlias, which is a [32]byte underneath, from an OpaqueReason, which is a []byte underneath. But only on the write barrier path, maybe?
My immediate suspicion is something going wrong with the type switch. I will continue investigating.

Reproducer:
package main

func main() {
	for i := 0; i < 10000; i++ {
		h(i)
		sink = make([]byte, 1024) // generate some garbage
	}
}

func h(iter int) {
	var x [32]byte
	for i := 0; i < 32; i++ {
		x[i] = 99
	}
	g(&x)
	if x == ([32]byte{}) {
		return
	}
	for i := 0; i < 32; i++ {
		println(x[i])
	}
	panic(iter)
}

//go:noinline
func g(x interface{}) {
	switch e := x.(type) {
	case *[32]byte:
		var c [32]byte
		*e = c
	case *[]byte:
		*e = nil
	}
}

var sink []byte

Fails on 1.19.1 and tip, doesn't fail for 1.19 and earlier.
@gopherbot please open a backport issue for 1.19.

Probably caused by https://go-review.googlesource.com/c/go/+/425076 . Or more correctly, that CL tickled an existing bug.
The problem is that the memmove -> OpMove rewrite uses the type of the first argument to decide what type it is that we're moving. That type is somewhat fragile, and gets broken during type switches on argument values.
We have 2 different IData ops for the same argument, each with different types (*[]byte and *[32]byte). After expand_calls, both of these IData ops are just copies of the input register, and that happens to get the type *[]byte, so the memmove thinks it is operating on a slice, not a [32]byte.
SSA passes shouldn't really depend on the base types of pointer types to make decisions like this. At least, as long as we make pointer casts just OpCopy, and rewrite always does (OpCopy x) -> x. I think the memmove call needs to carry along the type explicitly somewhere.
The CL referenced above was backported to both 1.19 and 1.18. Not sure why 1.18 isn't failing, but it may need the backport as well.

This bug does happen on 1.18.6, I have a test case in the CL above.
@gopherbot please open a backport issue for 1.18.

This bug does happen on 1.18.6, I have a test case in the CL above.
@gopherbot please open a backport issue for 1.18.

You have to create the backport manually, gopherbot only listen to the first backport comment.


Move operator from personal quay.io

Move Operator and workloads to shared namespace...

Cleaned this up already.


Add media type context to start of result link titles

Fixes

Fixes #1010 by @sarayourfriend
Description

Adds SR accessible context as per the issue. There are two "todos" that I'll ping folks on to clarify what to do with them.
I also made some changes to the playwright configuration to make it easier to use start instead of prod to quickly re-run the tests inside the container. I can revert these changes if they're not wanted, but it is merely a codification of what was present in the comment I moved and updated.
Testing Instructions

Confirm CI runs. I changed a test to exercise the accessible title.
Checklist

[x] My pull request has a descriptive title (not a vague title likeUpdate index.md).
[x] My pull request targets the default branch of the repository (main) or a parent feature branch.
[x] My commit messages follow best practices.
[x] My code follows the established code style of the repository.
[x] I added or updated tests for the changes I made (if applicable).
[N/A] I added or updated documentation (if applicable).
[x] I tried running the project locally and verified that there are no visible errors.
[N/A] I ran the DAG documentation generator (if applicable).

Developer Certificate of Origin

Developer Certificate of Origin
Developer Certificate of Origin
Version 1.1

Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
1 Letterman Drive
Suite D4700
San Francisco, CA, 94129

Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.

Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
    have the right to submit it under the open source license
    indicated in the file; or

(b) The contribution is based upon previous work that, to the best
    of my knowledge, is covered under an appropriate open source
    license and I have the right under that license to submit that
    work with modifications, whether created in whole or in part
    by me, under the same open source license (unless I am
    permitted to submit under a different license), as indicated
    in the file; or

(c) The contribution was provided directly to me by some other
    person who certified (a), (b) or (c) and I have not modified
    it.

(d) I understand and agree that this project and the contribution
    are public and that a record of the contribution (including all
    personal information I submit with it, including my sign-off) is
    maintained indefinitely and may be redistributed consistent with
    this project or the open source license(s) involved.

After much debugging and fighting with Microsoft's servers to actually successfully download the Playwright Docker image from their registry and then the browser binary from their distribution endpoint, both of which were impossibly slow on my connection, I finally found the issue.
The audio cells did not have title on the elements, just aria-label. This meant that when the tests tried to walk the DOM via keyboard to find the audio element, it never finds it, span forever, and eventually crashed the browser, failing all the tests in that module.
I tried to add title to the audio links, but for some reason it was not possible. I'm not sure if it's because of our use of component in VAudioTrack to render the link, but nothing I did seemed to pass the title through to the anchor element eventually created.
Instead of trying to continue fighting with it, I opted for the navigation code to fall back to aria-label if title is empty. This avoids the issue entirely and still exercises the context that a screen-reader user would have for the link.

After much debugging and fighting with Microsoft's servers to actually successfully download the Playwright Docker image from their registry and then the browser binary from their distribution endpoint, both of which were impossibly slow on my connection, I finally found the issue.
The audio cells did not have title on the elements, just aria-label. This meant that when the tests tried to walk the DOM via keyboard to find the audio element, it never finds it, span forever, and eventually crashed the browser, failing all the tests in that module.
I tried to add title to the audio links, but for some reason it was not possible. I'm not sure if it's because of our use of component in VAudioTrack to render the link, but nothing I did seemed to pass the title through to the anchor element eventually created.
Instead of trying to continue fighting with it, I opted for the navigation code to fall back to aria-label if title is empty. This avoids the issue entirely and still exercises the context that a screen-reader user would have for the link.

In Vue 2, if a parent component passes a parameter to the child component, and it is not declared as the child component's prop, it becomes a part of the child component'sattrs object. There are 2 options for it:

if the child component is an HTML Element, then all attrs are applied as the element's attributes.
if the child component is a Vue Component, the id, class and style attrs "fall through" to the HTML element that is a child of this Vue Component, but other attrs are discarded.

For VLink, title is not a prop. So, it becomes an attr that is attached to the VLink. VLink, in turn, is a Vue Component that is a wrapper for NuxtLink component (which, in turn, is a wrapper for VueRouter). So, the non-prop parameter that you pass to VLink (except for id, class and style) are discarded.
Behavior for internal links:

VLink (parameters: id, class, style, title)

NuxtLink - id, class, style fall through to child HTML element, title is discarded

a - "catches" the fall-through attrs (id, class, style)

Behavior for external links:

VLink (parameters: id, class, style, title)

a -  all parameters passed by the parent (id, class, style and title) are applied to the HTML element

To make sure that all VLink parameters are passed to both external and internal links, we should add v-bind="$attrs" to NuxtLink inside VLink.
diff --git a/frontend/src/components/VLink.vue b/frontend/src/components/VLink.vue
index f96dcfc1b..237485597 100644
--- a/frontend/src/components/VLink.vue
+++ b/frontend/src/components/VLink.vue
@@ -5,6 +5,7 @@
     :class="{ 'inline-flex flex-row items-center gap-2': showExternalIcon }"
     :to="linkTo"
     v-on="$listeners"
+    v-bind="$attrs"
     @click.native="$emit('click', $event)"

For images screen reader reads "Link Image Cat", and for audio it reads "Cat audio player, press spacebar to play" - and has no indication that the element is actually a link. I don't know what the best solution here is, though: would adding something like "Press enter to go to the Audio details" to the end of the audio player instructions be enough?

Thanks for testing this. I haven't had access to a screen reader and need to fix that soon; realistically I probably shouldn't have taken on this issue due to that.
I agree audio should read similarly to images. I don't know if our current approach might be annoying though: it's quite wordy. For a page full of audio results, moving through them would be pretty chatty already, with the instructions repeated on each one.
Could we implement something like the Gutenberg's a11y utility to announce the toast with instructions and only do so once per page load, and then unify the aria label on all media type links?
I'm also not sure how best to approach this but do agree that it is suboptimal. This issue was stemmed from https://github.com/WordPress/openverse/issues/448 which has a host of other already-identified improvements. My inclination is that we should prioritise fixing those issues, especially because the issue describes specific fixes for almost everything listed.

I'm also not sure how best to approach this but do agree that it is suboptimal. This issue was stemmed from https://github.com/WordPress/openverse/issues/448 which has a host of other already-identified improvements. My inclination is that we should prioritise fixing those issues, especially because the issue describes specific fixes for almost everything listed.

I agree with prioritizing those issues. I think this PR adds a good incremental change for the Image results, and could be merged because it's useful as is. We should also open an issue for improving the overall experience for the search results, and exploring the a11y utility you mentioned.

I'm going to merge this and create a follow-up issue for some of the further identified accessibility improvements. I've also created one to fix the box audio layout: #2124


Add a list of channels excluded from bridging

I have a situation where I would like to be in all rooms of a guild, apart from one, and have autoinvite on.
This is currently not possible, but it would be nice if you could unbridge a room and it stay that way :rofl:

Tracked by https://gitlab.com/mx-puppet/discord/mx-puppet-discord/-/issues/192


tests: lib: spsc_pbuf: libraries.spsc_pbuf_utilization fails

Describe the bug
The tests/lib/spsc_pbuf/libraries.spsc_pbuf_utilization fails
Tests:

tests/lib/spsc_pbuf/libraries.spsc_pbuf_utilization

Observed for

nrf52dk_nrf52832

To Reproduce
Steps to reproduce the behavior:

have nrf52dk_nrf52832 connected
go to your zephyr dir
call ./scripts/twister -T tests/lib/spsc_pbuf -p nrf52dk_nrf52832 --device-testing --device-serial /dev/ttyACM0 -v --inline-logs
See console output with error

Expected behavior
Valid console output
Impact
Not clear
Logs and console output
[2023-03-23T01:22:13.785Z] ERROR   - *** Booting Zephyr OS build zephyr-v3.3.0-1516-g1dce3c3ee2e9 ***
[2023-03-23T01:22:13.785Z] Running TESTSUITE test_spsc_pbuf
[2023-03-23T01:22:13.785Z] ===================================================================
[2023-03-23T01:22:13.785Z] START - test_0cpy
[2023-03-23T01:22:13.785Z] PASS - test_0cpy in 0.001 seconds
[2023-03-23T01:22:13.785Z] ===================================================================
[2023-03-23T01:22:13.785Z] START - test_0cpy_corner1
[2023-03-23T01:22:13.785Z] PASS - test_0cpy_corner1 in 0.001 seconds
[2023-03-23T01:22:13.785Z] ===================================================================
[2023-03-23T01:22:13.785Z] START - test_0cpy_corner2
[2023-03-23T01:22:13.785Z] PASS - test_0cpy_corner2 in 0.001 seconds
[2023-03-23T01:22:13.785Z] ===================================================================
[2023-03-23T01:22:13.785Z] START - test_0cpy_discard
[2023-03-23T01:22:13.785Z] PASS - test_0cpy_discard in 0.001 seconds
[2023-03-23T01:22:13.785Z] ===================================================================
[2023-03-23T01:22:13.785Z] START - test_0cpy_smaller
[2023-03-23T01:22:13.785Z] PASS - test_0cpy_smaller in 0.001 seconds
[2023-03-23T01:22:13.785Z] ===================================================================
[2023-03-23T01:22:13.785Z] START - test_largest_alloc
[2023-03-23T01:22:13.785Z] PASS - test_largest_alloc in 0.001 seconds
[2023-03-23T01:22:13.785Z] ===================================================================
[2023-03-23T01:22:13.785Z] START - test_spsc_pbuf_ut
[2023-03-23T01:22:13.785Z] PASS - test_spsc_pbuf_ut in 0.001 seconds
[2023-03-23T01:22:13.785Z] ===================================================================
[2023-03-23T01:22:13.785Z] START - test_spsc_pbuf_ut_cache
[2023-03-23T01:22:13.785Z] PASS - test_spsc_pbuf_ut_cache in 0.001 seconds
[2023-03-23T01:22:13.785Z] ===================================================================
[2023-03-23T01:22:13.785Z] START - test_stress
[2023-03-23T01:22:13.785Z] Reading from an interrupt, writing from a thread
[2023-03-23T01:22:13.785Z] 0% remaining:14000 ms
[2023-03-23T01:22:13.785Z] 0% remaining:13000 ms
[2023-03-23T01:22:13.785Z] 0% remaining:12000 ms
[2023-03-23T01:22:13.785Z] Ztress execution report:
[2023-03-23T01:22:13.785Z] context 0:
[2023-03-23T01:22:13.785Z] - executed:25383, preempted:0
[2023-03-23T01:22:13.785Z] - ticks initial:4, optimized:4
[2023-03-23T01:22:13.785Z] context 1:
[2023-03-23T01:22:13.785Z] - executed:7774, preempted:2001
[2023-03-23T01:22:13.785Z] - ticks initial:4, optimized:4
[2023-03-23T01:22:13.785Z] Average CPU load:28%, measurements:32
[2023-03-23T01:22:13.785Z] Writes:11749 failures: 0
[2023-03-23T01:22:13.785Z] Writing from an interrupt, reading from a thread
[2023-03-23T01:22:13.785Z] 100% remaining:14000 ms
[2023-03-23T01:22:13.785Z] Ztress execution report:
[2023-03-23T01:22:13.785Z] context 0:
[2023-03-23T01:22:13.785Z] - executed:11230, preempted:0
[2023-03-23T01:22:13.785Z] - ticks initial:4, optimized:4
[2023-03-23T01:22:13.785Z] context 1:
[2023-03-23T01:22:13.785Z] - executed:3117, preempted:1000
[2023-03-23T01:22:13.785Z] - ticks initial:4, optimized:4
[2023-03-23T01:22:13.785Z] Average CPU load:27%, measurements:14
[2023-03-23T01:22:13.785Z] Writes:19491 failures: 9118
[2023-03-23T01:22:13.785Z] PASS - test_stress in 4.686 seconds
[2023-03-23T01:22:13.785Z] ===================================================================
[2023-03-23T01:22:13.785Z] START - test_stress_0cpy
[2023-03-23T01:22:13.785Z] 7% remaining:14000 ms
[2023-03-23T01:22:13.785Z] 16% remaining:13000 ms
[2023-03-23T01:22:13.785Z] 24% remaining:12000 ms
[2023-03-23T01:22:13.785Z] 33% remaining:11000 ms
[2023-03-23T01:22:13.785Z] 42% remaining:10000 ms
[2023-03-23T01:22:13.785Z] 48% remaining:9000 ms
[2023-03-23T01:22:13.785Z] 56% remaining:8000 ms
[2023-03-23T01:22:13.785Z] 64% remaining:7000 ms
[2023-03-23T01:22:13.785Z] 73% remaining:6000 ms
[2023-03-23T01:22:13.785Z] 83% remaining:5000 ms
[2023-03-23T01:22:13.785Z] 93% remaining:4000 ms
[2023-03-23T01:22:13.785Z] Ztress execution report:
[2023-03-23T01:22:13.785Z] context 0:
[2023-03-23T01:22:13.785Z] - executed:45456, preempted:0
[2023-03-23T01:22:13.785Z] - ticks initial:4, optimized:4
[2023-03-23T01:22:13.785Z] context 1:
[2023-03-23T01:22:13.785Z] - executed:42837, preempted:1000
[2023-03-23T01:22:13.785Z] - ticks initial:4, optimized:4
[2023-03-23T01:22:13.785Z] Average CPU load:56%, measurements:116
[2023-03-23T01:22:13.785Z] 9% remaining:14000 ms
[2023-03-23T01:22:13.785Z] 16% remaining:13000 ms
[2023-03-23T01:22:13.785Z] 23% remaining:12000 ms
[2023-03-23T01:22:13.785Z] 31% remaining:11000 ms
[2023-03-23T01:22:13.785Z] 39% remaining:10000 ms
[2023-03-23T01:22:13.785Z] Assertion failed at ../../../../../../../../zephyr/zephyr/tests/lib/spsc_pbuf/src/main.c:502: stress_claim_free: check_buffer(buf, len, ctx->read_cnt) is non-zero
[2023-03-23T01:22:13.785Z] FAIL - test_stress_0cpy in 17.521 seconds
[2023-03-23T01:22:13.785Z] ===================================================================
[2023-03-23T01:22:13.785Z] START - test_utilization
[2023-03-23T01:22:13.785Z] PASS - test_utilization in 0.001 seconds
[2023-03-23T01:22:13.785Z] ===================================================================
[2023-03-23T01:22:13.785Z] TESTSUITE test_spsc_pbuf failed.
[2023-03-23T01:22:13.785Z] ------ TESTSUITE SUMMARY START ------
[2023-03-23T01:22:13.785Z] SUITE FAIL -  90.91% [test_spsc_pbuf]: pass = 10, fail = 1, skip = 0, total = 11 duration = 22.216 seconds
[2023-03-23T01:22:13.785Z] - PASS - [test_spsc_pbuf.test_0cpy] duration = 0.001 seconds
[2023-03-23T01:22:13.785Z] - PASS - [test_spsc_pbuf.test_0cpy_corner1] duration = 0.001 seconds
[2023-03-23T01:22:13.785Z] - PASS - [test_spsc_pbuf.test_0cpy_corner2] duration = 0.001 seconds
[2023-03-23T01:22:13.785Z] - PASS - [test_spsc_pbuf.test_0cpy_discard] duration = 0.001 seconds
[2023-03-23T01:22:13.785Z] - PASS - [test_spsc_pbuf.test_0cpy_smaller] duration = 0.001 seconds
[2023-03-23T01:22:13.785Z] - PASS - [test_spsc_pbuf.test_largest_alloc] duration = 0.001 seconds
[2023-03-23T01:22:13.785Z] - PASS - [test_spsc_pbuf.test_spsc_pbuf_ut] duration = 0.001 seconds
[2023-03-23T01:22:13.785Z] - PASS - [test_spsc_pbuf.test_spsc_pbuf_ut_cache] duration = 0.001 seconds
[2023-03-23T01:22:13.785Z] - PASS - [test_spsc_pbuf.test_stress] duration = 4.686 seconds
[2023-03-23T01:22:13.785Z] - FAIL - [test_spsc_pbuf.test_stress_0cpy] duration = 17.521 seconds
[2023-03-23T01:22:13.785Z] - PASS - [test_spsc_pbuf.test_utilization] duration = 0.001 seconds
[2023-03-23T01:22:13.785Z] ------ TESTSUITE SUMMARY END ------
[2023-03-23T01:22:13.785Z] ===================================================================
[2023-03-23T01:22:13.785Z] RunID: ab40a64ac3bc2b6d4ae74c1f54f7c396
[2023-03-23T01:22:13.785Z] PROJECT EXECUTION FAILED

Environment (please complete the following information):

OS: Ubuntu 20.04.1 LTS
Toolchain Zephyr SDK 0.15.2
Commit SHA or Version used: zephyr-v3.3.0-1516-g1dce3c3ee2e9

Run it few times but could not reproduce.

Run it few times but could not reproduce.

Checking at CI, current reproduction rate is 1/11. Can you do more testing?

The same issue occurred on the board nrf5340dk_nrf5340_cpuapp_ns for scenario tests/lib/spsc_pbuf/libraries.spsc_pbuf.
[2023-04-26T22:03:33.265Z] ERROR   - *** Booting Zephyr OS build zephyr-v3.3.0-3164-ga0ad7b7752e6 ***
[2023-04-26T22:03:33.265Z] Running TESTSUITE test_spsc_pbuf
[2023-04-26T22:03:33.265Z] ===================================================================
[2023-04-26T22:03:33.265Z] START - test_0cpy
[2023-04-26T22:03:33.265Z] PASS - test_0cpy in 0.001 seconds
[2023-04-26T22:03:33.265Z] ===================================================================
[2023-04-26T22:03:33.265Z] START - test_0cpy_corner1
[2023-04-26T22:03:33.265Z] PASS - test_0cpy_corner1 in 0.001 seconds
[2023-04-26T22:03:33.265Z] ===================================================================
[2023-04-26T22:03:33.265Z] START - test_0cpy_corner2
[2023-04-26T22:03:33.265Z] PASS - test_0cpy_corner2 in 0.001 seconds
[2023-04-26T22:03:33.265Z] ===================================================================
[2023-04-26T22:03:33.265Z] START - test_0cpy_discard
[2023-04-26T22:03:33.265Z] PASS - test_0cpy_discard in 0.001 seconds
[2023-04-26T22:03:33.265Z] ===================================================================
[2023-04-26T22:03:33.265Z] START - test_0cpy_smaller
[2023-04-26T22:03:33.265Z] PASS - test_0cpy_smaller in 0.001 seconds
[2023-04-26T22:03:33.265Z] ===================================================================
[2023-04-26T22:03:33.265Z] START - test_largest_alloc
[2023-04-26T22:03:33.265Z] PASS - test_largest_alloc in 0.001 seconds
[2023-04-26T22:03:33.265Z] ===================================================================
[2023-04-26T22:03:33.265Z] START - test_spsc_pbuf_ut
[2023-04-26T22:03:33.265Z] PASS - test_spsc_pbuf_ut in 0.001 seconds
[2023-04-26T22:03:33.265Z] ===================================================================
[2023-04-26T22:03:33.265Z] START - test_spsc_pbuf_ut_cache
[2023-04-26T22:03:33.265Z] PASS - test_spsc_pbuf_ut_cache in 0.001 seconds
[2023-04-26T22:03:33.265Z] ===================================================================
[2023-04-26T22:03:33.265Z] START - test_stress
[2023-04-26T22:03:33.265Z] Reading from an interrupt, writing from a thread
[2023-04-26T22:03:33.265Z] 0% remaining:14000 ms
[2023-04-26T22:03:33.265Z] 0% remaining:13000 ms
[2023-04-26T22:03:33.265Z] Ztress execution report:
[2023-04-26T22:03:33.265Z] context 0:
[2023-04-26T22:03:33.265Z] - executed:23683, pre
[2023-04-26T22:03:33.265Z] 0% remaining:12000 msempted:0
[2023-04-26T22:03:33.265Z] - ticks initial:4, optimized:4
[2023-04-26T22:03:33.265Z] context 1:
[2023-04-26T22:03:33.265Z] - executed:6801, preempted:2001
[2023-04-26T22:03:33.265Z] - ticks initial:4, optimized:4
[2023-04-26T22:03:33.265Z] Average CPU load:32%, measurements:30
[2023-04-26T22:03:33.265Z] Writes:10174 failures: 0
[2023-04-26T22:03:33.265Z] Writing from an interrupt, reading from a thread
[2023-04-26T22:03:33.265Z] 100% remaining:14000 ms
[2023-04-26T22:03:33.265Z] Ztress execution report:
[2023-04-26T22:03:33.265Z] context 0:
[2023-04-26T22:03:33.265Z] - executed:8436, preempted:0
[2023-04-26T22:03:33.265Z] - ticks initial:4, optimized:4
[2023-04-26T22:03:33.265Z] context 1:
[2023-04-26T22:03:33.265Z] - executed:2283, preempted:1000
[2023-04-26T22:03:33.265Z] - ticks initial:4, optimized:4
[2023-04-26T22:03:33.265Z] Average CPU load:42%, measurements:10
[2023-04-26T22:03:33.265Z] Writes:15842 failures: 7008
[2023-04-26T22:03:33.265Z] PASS - test_stress in 4.151 seconds
[2023-04-26T22:03:33.265Z] ===================================================================
[2023-04-26T22:03:33.265Z] START - test_stress_0cpy
[2023-04-26T22:03:33.265Z] 8% remaining:14000 ms
[2023-04-26T22:03:33.265Z] 20% remaining:13000 ms
[2023-04-26T22:03:33.265Z] 33% remaining:12000 ms
[2023-04-26T22:03:33.265Z] 43% remaining:11000 ms
[2023-04-26T22:03:33.265Z] 52% remaining:10000 ms
[2023-04-26T22:03:33.265Z] 62% remaining:9000 ms
[2023-04-26T22:03:33.265Z] 74% remaining:8000 ms
[2023-04-26T22:03:33.265Z] 85% remaining:7000 ms
[2023-04-26T22:03:33.265Z] 96% remaining:6000 ms
[2023-04-26T22:03:33.265Z] Ztress execution report:
[2023-04-26T22:03:33.265Z] context 0:
[2023-04-26T22:03:33.265Z] - executed:36028, preempted:0
[2023-04-26T22:03:33.265Z] - ticks initial:4, optimized:4
[2023-04-26T22:03:33.265Z] context 1:
[2023-04-26T22:03:33.265Z] - executed:33689, preempted:1000
[2023-04-26T22:03:33.265Z] - ticks initial:4, optimized:4
[2023-04-26T22:03:33.265Z] Average CPU load:61%, measurements:94
[2023-04-26T22:03:33.265Z] 6% remaining:14000 ms
[2023-04-26T22:03:33.265Z] 13% remaining:13000 ms
[2023-04-26T22:03:33.265Z] 21% remaining:12000 ms
[2023-04-26T22:03:33.265Z] 28% remaining:11000 ms
[2023-04-26T22:03:33.265Z] 35% remaining:10000 ms
[2023-04-26T22:03:33.265Z] 41% remaining:9000 ms
[2023-04-26T22:03:33.265Z] 46% remaining:8000 ms
[2023-04-26T22:03:33.265Z] 53% remaining:7000 ms
[2023-04-26T22:03:33.265Z] 60% remaining:6000 ms
[2023-04-26T22:03:33.265Z] Assertion failed at ../../../../../../../../zephyr/zephyr/tests/lib/spsc_pbuf/src/main.c:502: stress_claim_free: check_buffer(buf, len, ctx->read_cnt) is non-zero
[2023-04-26T22:03:33.265Z] FAIL - test_stress_0cpy in 19.016 seconds
[2023-04-26T22:03:33.265Z] ===================================================================
[2023-04-26T22:03:33.265Z] START - test_utilization
[2023-04-26T22:03:33.265Z] PASS - test_utilization in 0.001 seconds
[2023-04-26T22:03:33.265Z] ===================================================================
[2023-04-26T22:03:33.265Z] TESTSUITE test_spsc_pbuf failed.
[2023-04-26T22:03:33.265Z] ------ TESTSUITE SUMMARY START ------
[2023-04-26T22:03:33.265Z] SUITE FAIL -  90.91% [test_spsc_pbuf]: pass = 10, fail = 1, skip = 0, total = 11 duration = 23.176 seconds
[2023-04-26T22:03:33.265Z] - PASS - [test_spsc_pbuf.test_0cpy] duration = 0.001 seconds
[2023-04-26T22:03:33.265Z] - PASS - [test_spsc_pbuf.test_0cpy_corner1] duration = 0.001 seconds
[2023-04-26T22:03:33.265Z] - PASS - [test_spsc_pbuf.test_0cpy_corner2] duration = 0.001 seconds
[2023-04-26T22:03:33.265Z] - PASS - [test_spsc_pbuf.test_0cpy_discard] duration = 0.001 seconds
[2023-04-26T22:03:33.265Z] - PASS - [test_spsc_pbuf.test_0cpy_smaller] duration = 0.001 seconds
[2023-04-26T22:03:33.265Z] - PASS - [test_spsc_pbuf.test_largest_alloc] duration = 0.001 seconds
[2023-04-26T22:03:33.265Z] - PASS - [test_spsc_pbuf.test_spsc_pbuf_ut] duration = 0.001 seconds
[2023-04-26T22:03:33.265Z] - PASS - [test_spsc_pbuf.test_spsc_pbuf_ut_cache] duration = 0.001 seconds
[2023-04-26T22:03:33.265Z] - PASS - [test_spsc_pbuf.test_stress] duration = 4.151 seconds
[2023-04-26T22:03:33.265Z] - FAIL - [test_spsc_pbuf.test_stress_0cpy] duration = 19.016 seconds
[2023-04-26T22:03:33.265Z] - PASS - [test_spsc_pbuf.test_utilization] duration = 0.001 seconds
[2023-04-26T22:03:33.265Z] ------ TESTSUITE SUMMARY END ------
[2023-04-26T22:03:33.265Z] ===================================================================
[2023-04-26T22:03:33.265Z] RunID: 6458b3e1649a38a66c5f941f1ae35424
[2023-04-26T22:03:33.265Z] PROJECT EXECUTION FAILED
[2023-04-26T22:03:33.265Z]


TTS needs a way to drop inputs for Video Auto Prompt

Since the auto prompt with video input generates excessive output, TTS can't keep up, resulting in increasing delays. It would be ideal if we could skip past outputs and use only the latest one. However, this might not work with the 'word' output. Perhaps we could use the 'final' output to jump to the most recent whole output?

Hi Tadayuki!  Yes that is a good point, I hadn't tried hooking TTS directly up to autoprompter output yet - lets try using the 'final' output, disabling the TTS buffering, and setting drop_inputs=True on TTS.  That way it will at least process the latest response if it gets behind.

From: TadayukiOkada @.>
Sent: Sunday, June 16, 2024 11:59:16 AM
To: dusty-nv/NanoLLM @.>
Cc: Subscribed @.***>
Subject: [dusty-nv/NanoLLM] TTS needs a way to drop inputs for Video Auto Prompt (Issue #19)
Since the auto prompt with video input generates excessive output, TTS can't keep up, resulting in increasing delays. It would be ideal if we could skip past outputs and use only the latest one. However, this might not work with the 'word' output. Perhaps we could use the 'final' output to jump to the most recent whole output?
—
Reply to this email directly, view it on GitHubhttps://github.com/dusty-nv/NanoLLM/issues/19, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ADVEGKZHIGDQFAOU273SMULZHWY5JAVCNFSM6AAAAABJMWQKTWVHI2DSMVQWIX3LMV43ASLTON2WKOZSGM2TKOBVGEZTENY.
You are receiving this because you are subscribed to this thread.Message ID: @.***>


Bypass case/control requirements

Would be great to have an official way to bypass the case/control requirements, i.e. if you're QCing a cohorts that is all cases or all controls. Mat and I came up with a temporary fix, but others might want this feature as well

if case/control variant pruning methods are called without phenotype, warning will be thrown


Tools: Current Directory is wrong for two project layouts

My application is split in two projects:
TwoProjectLayout -> Web project
DatabaseModel -> Entities, DBContext, Migrations
In my web project I would have a config.json containing the connection string to the database. When using the ef command on the DatabaseModel project, the current directory is not set properly and thus the config.json cannot be found when using Directory.GetCurrentDirectory() as BasePath, simliar to what is described in #7588.
 D:\downloads\eftest\TwoProjectLayout\DatabaseModel>dotnet ef migrations list -s ..\TwoProjectLayout CURRENT DIRECTORY: D:\downloads\eftest\TwoProjectLayout\TwoProjectLayout\bin\Debug\netcoreapp2.0
Steps to reproduce
(Note: the config.json described above is not part of this demo project)

https://github.com/leak/TwoProjectLayout
Run dotnet ef migrations list -s ..\TwoProjectLayout from DatabaseModel project
Check "CURRENT DIRECTORY:" output on console from here https://github.com/leak/TwoProjectLayout/blob/master/TwoProjectLayout/Program.cs#L17

Further technical details
EF Core version: 2.0.0
Database Provider: any i guess
Operating system: win10 x64
IDE: VS2017

Turns out this issue was handmade by copy/pasting from the wrong location:
https://github.com/leak/TwoProjectLayout/blob/master/DatabaseModel/DatabaseModel.csproj#L8
Lesson learned here: Check your tools version number properly (had 1.0.0 instead of 2.0.0)


Mouse cursor not visible/working after pressing Ctrl+W while holding right mouse button on open world

Like previous now fixed issue, this happens when world is open.
How to reproduce
Load a world => hold right mouse button (don't release) => press Ctrl+W => Release the button
Effect
The world closes normally but there's no visible mouse; only keyboard controls are working. can't alt-tab out; Ctrl+q only way to exit. Also happened before while looking at unloaded chunks on loaded world.
MCEdit - Latest (v<IP_ADDRESS>) or whatever version on github (w->ctrl crash fixed)
Minecraft 1.9.1-pre3
OS Ubuntu Linux 64bit (xfwm4 4.12.3/Xfce 4.12)
Python 2.7.10
No errors on log.

I don't experience this on my side, even disabling the window management with '--no-wm' CLI switch.
It may be due to your desktop environment.
Can you reproduce this issue in the default Unity desktop?
What is the version of your OS?

Can you reproduce this issue in the default Unity desktop?
Unity is not installed here (xubuntu); to check I have to install it whitch takes time; will update later
What is the version of your OS?
Linux; Ubuntu 15.10, running Xubuntu (xfce) desktop environment

I can confirm this from Ubuntu live cd.  Installed all prerequisites and made a test world. Holding right click and hitting Ctrl+w still hides the cursor after you release the mouse button. So it meens it's reproduceable in default Unity desktop :/ p.s. typing this from live cd atm.

Fixed!
Thanks for all the help, keep the bugs coming :)

By the way, you shall install PyGTK 2 with sudo apt-get install python-gtk2
This fixed the issue on my VM even before Naor's commit.
Moreover, MCEdit will use the Linux file/folder chooser instead of the internal one.

By the way, you shall install PyGTK 2 with sudo apt-get install python-gtk2

Package already installed before, no need to reinstall. Btw thanks.

Does Naor's stuff fixed the issue?

Fixed. MCEdit Working ok.

OK
Thank you for the report!


Sender authentication

Hello @ksigler7,Thanks again for the PR! We appreciate your contribution and look forward to                                              continued collaboration. Thanks!                                             Team SendGrid DX


Couldn't (switch-to-buffer nil) because of a hook

What did you expect to happen?
(switch-to-buffer nil) should switch to (other-buffer) as per documentation.
What actually happened?
eq: Wrong type argument: stringp, nil thrown by get-buffer here

As of 6e8487e this issue should be resolved. Let me know if that isn't the case and I'll reopen it. Thanks for bringing it to my attention!

Hm, it's not working for me. This condition evals to false: (eq orig-fn #'switch-to-buffer)
Maybe it's because the function has other advices?
Anyway, do you really need to do (eq (current-buffer) (other-buffer), I've fixed it with (and buffer-or-name (eq (current-buffer) (get-buffer buffer-or-name))) and it works for me.

Anyway, do you really need to do (eq (current-buffer) (other-buffer)

Huh, on closer inspection I suppose not. My bad.
I've removed the change in c96bbf9. Let me know if the issue persists and I'll reopen this.


'reindent all lines' removes leading space in comment

Testing #19091:
In a typescript file:
/*---------------------------------------------------------------------------------------------
 *  Copyright (c) Microsoft Corporation. All rights reserved.
 *  Licensed under the MIT License. See License.txt in the project root for license information.
 *--------------------------------------------------------------------------------------------*/

'use strict';
class A {
}

use the 'Reindent all lines' command
check out the file comment. The space before '*' has been removed

/*---------------------------------------------------------------------------------------------
*  Copyright (c) Microsoft Corporation. All rights reserved.
*  Licensed under the MIT License. See License.txt in the project root for license information.
*--------------------------------------------------------------------------------------------*/

Block comment's indentation is currently handled by onEnterRules and not filtered out in Indentation Rules. There are actually two ways to mitigate this issue

Honor onEnterRules in Reindent lines, which is a breaking change
Enhance Indentation Rules for TypeScript. The indentation rule set I mentioned in https://github.com/Microsoft/vscode/issues/19140#issuecomment-274913963 still doesn't fix this problem. A proper fix is likely filtering block comments in unIndentPattern if possible.

Just wanted to ask whether this is still being worked on as it is still buggy even more than one year after the initial report of the issue.

FWIW, this affects pretty much all languages with doc comments, not just typescript.  I experienced this bug today in a PHP file.

Yes, I'm not sure the typescript label is relevant here.
My use case is I'm about to sort out lots of formatting issues in a rough-looking ES6 codebase that does at least have JSDoc comments, and I cant use "Reindent lines" to do so without messing up the comments (thereby annoying linters, and/or changing the code style). I will have to subsequently do a regexp find & replace on all the block comments (also regexp may vary per file), or a lot of copy & pasting around :(
Also see this stackoverflow issue (I am not the author of that).


Add camel link

Thanks @spatnity and I suppose this PR is going to resolve

#3580

And if I understand well, it seems we also need to add the similar content in modules/ROOT/pages/user-guide/index.adoc. When rebuild the camel website, it should appear in https://camel.apache.org/camel-quarkus/3.0.x/user-guide/index.html

This PR has been risen by mistake.Hence,closing this and the actual PR is
#4941


webkit-search-cancel-button

What do you think about this selection?
.search::-webkit-search-cancel-button{
display: none;
}

This project aims to normalize styles across browsers, not make opinionated styles.