Android (ARM64) support

I am aware that Android is not on the supported systems list for CoreRT. Beside of this with Xamarin available the demand might not be very high anyway.
But out of curiosity I hacked a little proof of concept together. It reaches the main function and can write some system information to the Console (stdout). Just a little bit more that the usual hello world app. Debugging seems to work fine, too. Only the general support for native Android applications in Visual Studio could need some love. But I am barking on the wrong tree here.
While I needed to add some ugly hacks I have the general felling that we are not that far away from getting it fully working. So far there are only 3 know issues left that need a proper fix. All in the runtime the compiler part works just fine. There might be more that pop up when these 3 are fixed.
While Android is still a Linux at the core (TARGET_UNIX) some places will need special code. Would the preprocessor define for this an additional TARGET_ANDROID or something else?

TARGET_ANDROID sounds good. It is the define used by http://github.com/dotnet/runtime for Android.

Two issues solved:

membarrier crashes Android before version Q
Android uses a TLS emulation instead of the real deal

One is work in progress

Calls between different object files trash X16&X17. This causes FEATURE_CACHED_INTERFACE_DISPATCH and thunks not working.

Unfortunately I found another one

Stackwalking crashes when there is one or more of the special functions (like RhpThrowEx) in the call stack.

I think the last two problems are both related to the requirement that Android needs position independent code. This messes up pointers to functions. Therefore there might be some issues related to this
Should still be fixable but might introduce some more overhead compared to a build that don't need position independent code.
In any case I am surprised how many things are actually already seem to work.
Beside of the code itself there will be some work needed on the buildscripts. But I think this should be postponed until the move to runtimelab is done as the Android build need to include some code from the runtime to get the BCL working.
And finally we will need C# bindings to at least the native Android APIs to do something usefull. But this could be just a totally independent project

Calls between different object files trash X16&X17.

Is there a way to tell the linker to use direct calls when the different object files are linked into a single binary? Maybe the symbols need to be defined as private or something to avoid involving dynamic loaded in cases like this?

Calls between different object files trash X16&X17.

Is there a way to tell the linker to use direct calls when the different object files are linked into a single binary? Maybe the symbols need to be defined as private or something to avoid involving dynamic loaded in cases like this?

Thanks for the tip. I was already looking into this direction but you pointed me in the right direction. Beside of global the symbols for the assembler functions need although be hidden. This way there is no entry in the GOT and the linker is forced to resolve the reference directly.
The final stack walk issue seems to need something more but I haven't really started looking into it yet.
But beside of this the GC and simple try/catch is working. Still need to check the hardware based exceptions and threading. Unfortunately anything network related pulls in the crypto functions and I need to figure out how these need to build for Android. But as Xamarin implemented the BCL for Android already I am sure there is a solution that I just need to adopt. Globalization is although still inactive as I am running in Invariant mode.
In any case I think this could become a usable replacement for Android apps that were done with the NDK so far.

network related pulls in the crypto functions and I need to figure out how these need to build for Android. But as Xamarin implemented the BCL for Android already  I am sure there is a solution that I just need to adopt. Globalization is although still inactive as I am running in Invariant mode.

Xamarin Android (based on https://github.com/mono/mono) had a solution for these issues. The solution was not ported yet to .NET Core. It is something that the team plans to work on for .NET 6. It will be closer to reimplementation than a port for various reasons.

Found the reason for the stack walk crash. The data type in the EXPORT_POINTER_TO_ADDRESS macro was a word instead of a quad.The assembler on the Switch seems to have ignored this and put the correct relocation information there while the android one has not copied the complete address there. Now the exception tests works including the hardware null ref exceptions.
Until I find more issues we can assume that a fully working CoreRT version for Android can be build.


OverridePropertyName with Expression

Could you add a new overload for OverridePropertyName that accepts an expression that can be translated to a property in the Rule context?
e.g.
RuleFor(dr => dr.InvoiceReceiverCompany.PostAddress)
.NotEmpty()
.OverridePropertyName(x=>x.InvoiceReceiverCompany)
.WithMessage(SelectedInvoiceReceiverCompanyMustHaveAPostAddress)

OverridePropertyName is usually used to rename the property to something that doesn’t already exist in the model so a string actually makes more sense here. That being said, if you want this behaviour you can add it very easily yourself using an extension method without it needing to be in the core.

This has been added for the 7.5.2 release.


esbuild - do not ignore d.ts files, please

Command
build
Is this a regression?

[X] Yes, this behavior used to work in the previous version

The previous version in which this bug was not present was
@angular/compiler-cli 15.0.1
Description
Please do not ignore d.ts files in source code - esbuild fails because of it.
Minimal Reproduction
ng build
Exception or Error
No response
Your Environment
all the latest versions of Angular libs
node 19

Anything else relevant?
No response

This seems like a bug but we'll need to look at a reproduction to find and fix the problem. Can you setup a minimal repro please?
You can read here why this is needed. A good way to make a minimal repro is to create a new app via ng new repro-app and adding the minimum possible code to show the problem. Then you can push this repository to github and link it here.
This might be related to your directory structure so its really important to get an accurate repro to diagnose this.

it's a bug, not a feature request, so reproduction is needed, sure.
Right now I have a pretty busy day, sorry for the sloppy bug report.
I'll add repro tomorrow, I've posted it in hope that maybe you've added "*.d.ts" filter on purpose and then you would know what I'm talking about instantly, without repro :)
Right now I can only show a folder in the project where this issue was found, later I'll add repro.

Error message:
✘ [ERROR] [plugin angular-compiler] File 'libs/monaco-editor/src/lib/editor.api.d.ts' is missing from the TypeScript compilation.

    libs/monaco-editor/src/lib/interfaces.ts:1:14:
      1 │ export * from './editor.api.d';
        ╵               ~~~~~~~~~~~~~~~~

  Ensure the file is part of the TypeScript program via the 'files' or 'include' property.

Forgot to say: non-esbuild version works fine.

While build a reproduction build, I found the workaround and what caused the problem - export * from...
And it's actually better to remove it from my code :)


Outdated python version for the automation script 👀

The python version of the lambda automation is outdated:
https://github.com/aws-samples/aws-modernization-with-cloud-one-workload-security/blob/main/static/cft/agent-automation.yaml#L211
Upgrade to version 3.8 solve the issue and is a non-breaking change.

Thank you for pointing that out. It's been updated.

Awesome! ❤


Find correct name.

Based on goals:

Setting opinionated deployment that will:

Operator based, with its own CR, operator hub compatible
Deploy Prometheus based metrics collection, and opt-in storage, query and alerting - all leveraging PO
Integrate with Alertmanager from PO or run a dedicated instance of your own (?)
Integrate with Grafana from GO or dedicated instance of your own (?)
Option to remote write to external storage
In future being able to shard and allocate deployment of Prometheus agents for forwarding the only mode.

Any ideas? Proposals? 🤗

Proposal from @periklis: "ObservabilityStack"
"The picture aligns well with the previous vision (Enhancement MSO) as:

client + backend: MonitoringStack renamed as ObservabilityStack installs a ClusterLogging + LokiStack CRs for the in-cluster logging capabilities
agent-only: MonitoringStack renamed as ObservabilityStack installs a ClusterLogging + ClusterLogForwarder CRs for pushing logs to RHOBS


REFACTOR: Make Modal Sizes Dynamic

The size of the modal changes depending on how many columns there are. This means that 3 different modal components need to be created even though most of the code is repetitive. The modal should get wider as the number of columns increase (only on medium sizes and above).

Requires #267 because that way the same generic filter modal can be used for all pages.


java-listener build errors in Android Studio

build.gradle:
compile 'com.couchbase.lite:couchbase-lite-android:1.3.0-6'
compile 'com.couchbase.lite:couchbase-lite-java-listener:1.3.0-6'
compile 'com.couchbase.lite:couchbase-lite-java-javascript:1.3.0-6'

http://cl.ly/0i1v2K1j0M1m/Pasted_Image_01_07_2016__10_34.png
Error message: https://gist.github.com/jamiltz/594a5bd72835765e844a2bd3b14726fd
The project compiles and the app runs fine so it's not a blocker. It looks like the errors are coming from Acme.Serve which is the TJWS library (the server used in LiteServ).
Those errors are also visible in 1.2.1 and 1.1.0.

We are using old TJWS version, and it is compiled with JDK 1.6. It causes problem. We needs to upgrade TJWS or replace TJWS with other micro Java web server.


TypeError: _.where is not a function

Error occurs with the latest version of lodash: https://github.com/lodash/lodash/issues/2127

I made a PR to fix that.


cmake find_package cannot find files with multi-output derivations

Building the following code
let
  nixpkgs = import (fetchTarball {
    url = "https://github.com/NixOS/nixpkgs/archive/eac5ef8aa9c0ddd948b20e83d9d7b37cd0132a81.tar.gz";
    sha256 = "1hf4cc8snllb8wxa4c5rvwrdg892sqcq7p7qjq08i5yfj4ifbn9n";
  }) {};
  cmakelists = nixpkgs.writeText "CMakeLists.txt" ''
    project(foo CXX)
    find_package(exiv2)
  '';

in
nixpkgs.runCommandCC "test" {
  nativeBuildInputs = [ nixpkgs.cmake ];
  buildInputs = [ nixpkgs.exiv2 ];
} ''
  cp ${cmakelists} CMakeLists.txt
  cmake .
  touch $out
''

fails with
CMake Error at /nix/store/1h2qz13p7cj174i4d0mvnmgxfndlx4ip-exiv2-0.27.2-dev/lib/cmake/exiv2/exiv2Config.cmake:85 (message):
  The imported target "exiv2-xmp" references the file

     "/nix/store/1h2qz13p7cj174i4d0mvnmgxfndlx4ip-exiv2-0.27.2-dev/lib/libexiv2-xmp.a"

  but this file does not exist.  Possible reasons include:

  * The file was deleted, renamed, or moved to another location.

  * An install or uninstall procedure did not complete successfully.

  * The installation package was faulty and contained

     "/nix/store/1h2qz13p7cj174i4d0mvnmgxfndlx4ip-exiv2-0.27.2-dev/lib/cmake/exiv2/exiv2Config.cmake"

  but not all the files it references.

Even though the generated files look correct:
exiv2Config.cmake
# Generated by CMake

if("${CMAKE_MAJOR_VERSION}.${CMAKE_MINOR_VERSION}" LESS 2.5)
   message(FATAL_ERROR "CMake >= 2.6.0 required")
endif()
cmake_policy(PUSH)
cmake_policy(VERSION 2.6...3.17)
#----------------------------------------------------------------
# Generated CMake target import file.
#----------------------------------------------------------------

# Commands may need to know the format version.
set(CMAKE_IMPORT_FILE_VERSION 1)

# Protect against multiple inclusion, which would fail when already imported targets are added once more.
set(_targetsDefined)
set(_targetsNotDefined)
set(_expectedTargets)
foreach(_expectedTarget exiv2-xmp exiv2lib)
  list(APPEND _expectedTargets ${_expectedTarget})
  if(NOT TARGET ${_expectedTarget})
    list(APPEND _targetsNotDefined ${_expectedTarget})
  endif()
  if(TARGET ${_expectedTarget})
    list(APPEND _targetsDefined ${_expectedTarget})
  endif()
endforeach()
if("${_targetsDefined}" STREQUAL "${_expectedTargets}")
  unset(_targetsDefined)
  unset(_targetsNotDefined)
  unset(_expectedTargets)
  set(CMAKE_IMPORT_FILE_VERSION)
  cmake_policy(POP)
  return()
endif()
if(NOT "${_targetsDefined}" STREQUAL "")
  message(FATAL_ERROR "Some (but not all) targets in this export set were already defined.\nTargets Defined: ${_targetsDefined}\nTargets not yet defined: ${_targetsNotDefined}\n")
endif()
unset(_targetsDefined)
unset(_targetsNotDefined)
unset(_expectedTargets)

# Compute the installation prefix relative to this file.
set(_IMPORT_PREFIX "/nix/store/s34c5w0h7kdbb46114m1x6a0ascyiqdj-exiv2-0.27.2")
if(_IMPORT_PREFIX STREQUAL "/")
  set(_IMPORT_PREFIX "")
endif()

# Create imported target exiv2-xmp
add_library(exiv2-xmp STATIC IMPORTED)

set_target_properties(exiv2-xmp PROPERTIES
  INTERFACE_LINK_LIBRARIES "/nix/store/pg71kfxk5wh3g9djymgm7v55b3hs29bx-expat-2.2.8/lib/libexpat.so"
)

# Create imported target exiv2lib
add_library(exiv2lib SHARED IMPORTED)

set_target_properties(exiv2lib PROPERTIES
  INTERFACE_INCLUDE_DIRECTORIES "/nix/store/yvaci842j7ciy3wpi300q11r7pxl2r4n-exiv2-0.27.2-dev/include"
)

if(CMAKE_VERSION VERSION_LESS 2.8.12)
  message(FATAL_ERROR "This file relies on consumers using CMake 2.8.12 or greater.")
endif()

# Load information for each installed configuration.
get_filename_component(_DIR "${CMAKE_CURRENT_LIST_FILE}" PATH)
file(GLOB CONFIG_FILES "${_DIR}/exiv2Config-*.cmake")
foreach(f ${CONFIG_FILES})
  include(${f})
endforeach()

# Cleanup temporary variables.
set(_IMPORT_PREFIX)

# Loop over all imported files and verify that they actually exist
foreach(target ${_IMPORT_CHECK_TARGETS} )
  foreach(file ${_IMPORT_CHECK_FILES_FOR_${target}} )
    if(NOT EXISTS "${file}" )
      message(FATAL_ERROR "The imported target \"${target}\" references the file
   \"${file}\"
but this file does not exist.  Possible reasons include:
* The file was deleted, renamed, or moved to another location.
* An install or uninstall procedure did not complete successfully.
* The installation package was faulty and contained
   \"${CMAKE_CURRENT_LIST_FILE}\"
but not all the files it references.
")
    endif()
  endforeach()
  unset(_IMPORT_CHECK_FILES_FOR_${target})
endforeach()
unset(_IMPORT_CHECK_TARGETS)

# This file does not depend on other imported targets which have
# been exported from the same project but in a separate export set.

# Commands beyond this point should not need to know the version.
set(CMAKE_IMPORT_FILE_VERSION)
cmake_policy(POP)

exiv2Config-release.cmake
#----------------------------------------------------------------
# Generated CMake target import file for configuration "Release".
#----------------------------------------------------------------

# Commands may need to know the format version.
set(CMAKE_IMPORT_FILE_VERSION 1)

# Import target "exiv2-xmp" for configuration "Release"
set_property(TARGET exiv2-xmp APPEND PROPERTY IMPORTED_CONFIGURATIONS RELEASE)
set_target_properties(exiv2-xmp PROPERTIES
  IMPORTED_LINK_INTERFACE_LANGUAGES_RELEASE "CXX"
  IMPORTED_LOCATION_RELEASE "${_IMPORT_PREFIX}/lib/libexiv2-xmp.a"
  )

list(APPEND _IMPORT_CHECK_TARGETS exiv2-xmp )
list(APPEND _IMPORT_CHECK_FILES_FOR_exiv2-xmp "${_IMPORT_PREFIX}/lib/libexiv2-xmp.a" )

# Import target "exiv2lib" for configuration "Release"
set_property(TARGET exiv2lib APPEND PROPERTY IMPORTED_CONFIGURATIONS RELEASE)
set_target_properties(exiv2lib PROPERTIES
  IMPORTED_LOCATION_RELEASE "${_IMPORT_PREFIX}/lib/libexiv2.so.0.27.2"
  IMPORTED_SONAME_RELEASE "libexiv2.so.27"
  )

list(APPEND _IMPORT_CHECK_TARGETS exiv2lib )
list(APPEND _IMPORT_CHECK_FILES_FOR_exiv2lib "${_IMPORT_PREFIX}/lib/libexiv2.so.0.27.2" )

# Commands beyond this point should not need to know the version.
set(CMAKE_IMPORT_FILE_VERSION)

The exiv2-xmp should be located in ${_IMPORT_PREFIX}/lib/libexiv2-xmp.a and the ${_IMPORT_PREFIX} variable looks set up correctly.
It can be walked around by hardcoding the variable in the -release.cmake file: https://github.com/NixOS/nixpkgs/pull/33953
Blocks: https://github.com/NixOS/nixpkgs/issues/77581
cc @orivej

The docs say include should use dynamic scoping so the variable should be carried over to the included -release.cmake file

Looks like in my test case (on eac5ef8aa9c0ddd948b20e83d9d7b37cd0132a81), the _IMPORT_PREFIX is actually set to:
# Compute the installation prefix relative to this file.
get_filename_component(_IMPORT_PREFIX "${CMAKE_CURRENT_LIST_FILE}" PATH)
get_filename_component(_IMPORT_PREFIX "${_IMPORT_PREFIX}" PATH)
get_filename_component(_IMPORT_PREFIX "${_IMPORT_PREFIX}" PATH)
get_filename_component(_IMPORT_PREFIX "${_IMPORT_PREFIX}" PATH)
if(_IMPORT_PREFIX STREQUAL "/")
  set(_IMPORT_PREFIX "")
endif()

whereas I got the configs from OP containing absolute paths from master (390d38400aa7a425abef6e20c6773e2717b2fda1).
I do not see why it would differ between the two as they are almost the same (no change to CMake as far as I can see).

Looks like the issue is caused by passing relative CMAKE_INSTALL_LIBDIR:
https://github.com/Kitware/CMake/blob/ce7408514c98d39612c7f1e1d85929c223f71068/Source/cmExportInstallFileGenerator.cxx#L185-L201
we should fix that instead as described in https://github.com/jtojnar/cmake-snips#concatenating-paths-when-building-pkg-config-files.


Fixing Most Kitsunekko Subs

This issue is related to #6. Therein, a number of problems were mentioned that called into question usefulness of such a feature.
The least significant of which, I think, is that of different file formats.
In my view, it is perfectly acceptable to offer only one file format (e.g. .srt) and even to only export the lines that are seen in animebook. (Get what you see.)
I've implemented a naive downlowd option which grabs all captions. Try it here: index-dl.txt
(rename to .html, shortcut is Crtl + Alt + d)
But the another, more significant, problem is that subtitles can have more than one mistimed section.
Subtitles on kitsunekko may look something like this:
|--a-----b-c---d-e-----f--| (kitsunekko/TV)
|-(-a---)--(b-c-)--(d-e---)--(f-)-| ((..) correctly timed sections)
|-a---b-c-d-e---f-| (correct timings)
(letters are subtitles, dashes op/ed/ad/speech breaks).
In this case (by far the most common) it would be useful to only offset the selected caption and the ones after it.
Something like this apparently exists in PotPlayer where you can fetch all remaining lines and retime them such that the next line starts now (shortcut Crtl + Alt + >).
What makes this feature so powerful is that it is fast and safe. You only ever change captions you haven't encounterd yet, as the once before have all been correct (you would have changed them otherwise).
This means the scenario of hanving inadvertently changed the beginning upon reaching the end (as described in #6) would never manifest. In my experience, using seperate programs is slow and distracting. In the case of scripts, it may even be inaccurate.
Basically it should work like this:
moveRemainingCaptionsToHere: function () {
　var i = 0;
　var last = this.captions.length - 1;
　while (i < last && this.captions[i].endTime < this.currentTime)
　　i++;
　if (i === last)
　　return;
　var diff = this.captions[i].startTime - this.currentTime;
　while (i <= last) {
　　this.captions[i].startTime -= diff;
　　this.captions[i].endTime -= diff;
　　i++;
　}
　return;
}
Using this code sort of works, but it obviously breaks other parts of the site, most notably the sidebar and displaying of subtitles.
Downloading with the above method and dragging it in once more works, but that is not a very elegant hack.
You can play around with it here: index-test.txt
(rename to .html, shortcut is Crtl + Alt + v)
The interface of animebook suggests a somewhat more flexible but also more complicated solution that works like Offset Mode.
You would select the caption that is supposed to end at the current position and only move the remaining captions alongside it.
3 cases:
i.) current time is before startTime of selected caption
ii.) current time is inbetween startTime and endTime
iii.) current time is after endTime
i.) If the selected caption is not the next, there will be overlapping captions that require handling. Most probably, the inbetween-lines would be unwanted.
ii.) Caption moves toward the beginning by a bit. There could be an overlap.
iii.) The simplest case, as you can't really break anything by moving the captions toward the end.
The main issue, of course, is that the offset functionality is already implemented, and while you could reuse most functionality by simply skipping the first indices, the changes would touch many different parts of the code.
To make all changes traceable, you'd probably need an array with one offset per caption, just to give an example. For any given line the offset would then be the offsets that came before, the global offset would be the first in the array.
I can't really say how much work would be required overall, but for the simple job it is supposed to provide, it seems a bit much.
Just to be complete, though, here are two scenarios where it would be useful to be able to select a caption other than the next:

There is a big gap in the subtitles (ad break) and the next caption is a music note/noise desctiption/ad transcription/etc.
You moved the captions a bit too far to the front and want to fix that.

A smaller scale solution to 1) would be to delete/hide single captions and then only download the seen captions.
With that, even subs like the following would be fixable:
|-g-a--g-g--b-c---d-e-----f--| (g = garbage)
|-a---b-c-d-e---f-| (correct timings)
As for 2), maybe a simple 1-step-undo would already be enough.
I think there is a use for this feature that is specific enough to the target audience of animebook to be included in the project. At the same time, it probably doesn't warrant any drastic changes.
At least mimicking the feature of PotPlayer would be nice, though. Nobody should have to use a bloated piece of software, if all they want to do is fixing their subtitles while watching anime. :)
Looking forward to your feedback.

Sorry for the late response. I like the idea, and I've been working on a way to make the PotPlayer-like workflow work with the web app. It's basically what you're suggesting, but I want to take advantage of the sidebar to show where to offsets are being applied and offer the user a way to edit them. Best way to see it is in a demo,
https://streamable.com/3g4l8d
Note: I'm still tweaking and testing it, but this is the direction I'm planning on going with it.
I admittedly didn't think you could do something like this when I closed the previous case. I don't mind making a few concessions on the other arguments I had there if generalized re-timing can be done.
I also don't really like ctrl or alt hotkeys, since the browser or extensions might conflict with them, so I'm going to change the download hotkey to 'Shift D' instead. This seems intuitive enough to me without being easy to accidentally hit.

Looks great! Being able to edit the value after the fact, in particular, is appreciated.
On the hotkeys, I have no attachment whatsoever, so please change them freely.
In general, the download function could be cleaned up just a tad. For now, the index starts at 0 when the default for srt seems to be 1 and garbage lines up front can underflow to 23:59.xx because of the date format used. The srt-format appears to handle both just fine, though.

Thanks for the heads up. I cleaned up the download function.
This is also deployed now if you want to try it out. Let me know if you something about it that's broken.

Thanks for your effort. Works great so far.


Acceptable Albatrosses

Acceptable Albatrosses project for Python Discord Summer Code Jam 2020.

Changed our GitHub Actions lint file; we need to revert that during the merge.
No flake8 linting errors

Thank you @SebastiaanZ for your suggestions and your review. I learned a lot from them.


Possible Normalization Bug

Thanks for another great implementation, Phil!
You're using the Attention Block  to do attention between latent features (i.e. "process" step from RIN paper).
It looks like you're not Layer-Normalizing the context  features in Attention when no context is provided (a logical move :)).
When you initialize the latent attention blocks in RINBlock, You specify norm=True, so you're layer-normalizing the latent features before computing the query vectors. Unfortunately, the context is set to the unnormalized latent features, which are then used to compute keys and values.
I could be wrong, or this could be intentional. Just wanted to give you a heads-up.
TLDR: When you try to use the Attention class to do regular Attention (not Cross Attention), the features used to predict keys and values may not be normalized.

Simpler explanation : line 199 moves to line 205

@MattMcPartlon Matt! Long time no talk! Thank you for raising this issue, and hope things are going well at the protein design company :smile: are you using this for your bio work?

Thanks Phil. Always a pleasure to read over your code 😄.
I just saw your email the other day (my bad!). Will respond soon.
I was hoping to do diffusion with your perceiver architecture, then I heard about this paper.
I'm hoping to use some of the ideas here to build a molecular-graph autoencoder. The Encoder will alternate cross attention with node and pair features. (kv=node->q=latent),(kv=latent->q=latent),(kv=pair->q=latent),(kv=latent->q=latent),[repeat], and decoder will use the same approach as PerceiverIO.
I'm not sure this type of graph can be encoded in a fixed-dimension latent space, but it seems worth a try :).

@MattMcPartlon yes indeed! this is actually the first time i've seen perceiver used for generations of this fidelity
hope you are able to get it to work for your molecular autoencoder


Black images

Love the project, 100% fits the bill for what I'm trying to accomplish.
Log.txt is showing:
-bin 1 -brightness 50 -darkframe 0 - delay 20000 -exposure 5000000 -filename image.jpg -flip 0 -fontcolor 255 0 0-fontline 1 -fontname 0 -fontsize 0.7 -fonttype 0 -gain 50 - gamma 50 -height 960 -latitude 47.66N -longitude -122.12W -nodisplay 1 -quality 95 -text ThunderCreek -textx 15 -texty 35 -time 1 -type 1 -usb 80 -wbb 90 -wbr 53 -width 1280
Thoughts on what I might need to change to get it properly imaging?  It's a ZWO120MC on a RPI 3 with the "compatible" firmware upgrade done on the camera.

FWIW, setting back to default values makes no difference.  Using SharpCap with the camera, I am getting images, so not a broken camera.

Hi Dave, did you try to capture images when it was dark outside?
The camera starts taking pictures at civil twilight so if you want to test it during the day, you'll have to set your lat/long to a place on earth where it's dark.
Let me know how it goes, I'm trying to narrow the issue down by eliminating the common problems.

That happened to me when I first used Allsky which I consider a nice feature, easier than adding a RTC and programming. Bill
Sent from my iPhone

On Apr 25, 2018, at 19:46, Thomas Jacquin<EMAIL_ADDRESS>wrote:
Hi Dave, did you try to capture images when it was dark outside?
The camera starts taking pictures at civil twilight so if you want to test it during the day, you'll have to set your lat/long to a place on earth where it's dark.
Let me know how it goes, I'm trying to narrow the issue down by eliminating the common problems.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Yes, I left it running all night long.  It finally logged that it was out of daytime, and should be capturing images, but they were always black.

Shouldn't live view in the Admin Panel at least show the current image, even if it's not capturing?

Yes the live view shows image.jpg located at the root of the project. Have you tried starting the program manually?
./allsky.sh

This may give you a bit more info in the terminal.

No, hadn't thought of running it manually.  I'll give that a shot.  Also thinking about whether the metadata for the image might have some clue as to what the settings are for the capture.  Do you know if the metadata is provided by the camera driver, or the capture app, or ?  Would the image capture metatdata (exposure length, gain, etc) be of any value to know?

I believe the only info being written to the metadata is image type, width
and height. If running the program manually still doesn't give you more
info, try going back to the old firmware.
2018-04-27 10:58 GMT-07:00 Dave Randall<EMAIL_ADDRESS>
No, hadn't thought of running it manually. I'll give that a shot. Also
thinking about whether the metadata for the image might have some clue as
to what the settings are for the capture. Do you know if the metadata is
provided by the camera driver, or the capture app, or ? Would the image
capture metatdata (exposure length, gain, etc) be of any value to know?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/thomasjacquin/allsky/issues/16#issuecomment-385047533,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AC6WJovNyNyNjC1Vyzx_8-5Wxuy9syXSks5ts1xJgaJpZM4TkXmm
.

Hey Dave, you don't need to wait for night, you can change your longitude for some place on earth where it's dark in order to test the camera.
I have not seen this OpenCV error before. Could you try re-running the install.sh script and reboot in the end? I'm not sure why OpenCV would fail when trying to save the image.

Another method is to change the system date + dark hours with the command line date.  After your test then reboot and enter date to check that the date has returned to normal.
Bill P.
Sent from my iPad

On May 3, 2018, at 11:05 AM, Thomas Jacquin<EMAIL_ADDRESS>wrote:
Hey Dave, you don't need to wait for night, you can change your longitude for some place on earth where it's dark in order to test the camera.
I have not seen this OpenCV error before. Could you try re-running the install.sh script and reboot in the end? I'm not sure why OpenCV would fail when trying to save the image.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

ok, doing the longitude works. manually running the script still errors some times, but sudo .\allsky.sh will eventually work.  But, still black images.
wondering if we can coordinate a remote session with teamviewer?  i have it running on the device.  maybe something will be obvious to you

OK, problem solved.

Reinstall Raspian
Update Raspian
Reinstall allsky
Use 2.4a power supply

All good!

Great! The power supply may have been the issue here. The camera takes a bit of power so if the power supply is not strong enough, it will fail to work properly.


Jhbate/sprint14

see https://tidepool.atlassian.net/browse/LOOP-1025. FYI I mimicked the Dash setup

@mpangburn the dash setup (and now also the simulator setup) will come up with an alert when you miss one of the delivery limit settings and hence cannot setup loop into a valid state


Building API reference locally

Since it seems PRs for API reference extensions are starting to come in, it would be nice if there was some way to build the API reference (including those extensions) on my machine.
Just running docfx build doesn't seem to do it and I didn't find anything in the contributing docs either.

This seems to work now. I believe it was fixed by #496.

Good to know @svick. I just tested this last night so I wasn't sure what was the issue you were running into.


Switch layout at the same time of complete page load with

How can I get layout switch at the same time of page content switch?.
Currently when I use  the layout switch is immediately, but the previous page content wait for new page content is loaded.
Example: When I routing for a new page with an async data, the layout change but the previous page content still alive(with "glitch" new layout) until new page data its ready.

Hi @mkv27
This issue is related to #214
It will be fixed when the issue above fixed.


Error using multipleOf with decimals

What version of Ajv are you using? Does the issue happen if you use the latest version?
8.12.0
Ajv options object

const Ajv = require("ajv");
const ajv = new Ajv();
const schema = {
   type: "number",
   multipleOf: 0.01
 };
const validate = ajv.compile(schema);
validate(8.69);;
// results: false

What results did you expect?
true
Are you going to resolve the issue?
No.

I think you are looking for multipleOfPrecision option in AJV. For your example I think you can set this option to 2 and it should work, but have a look at the docs and see how you go.


feat: set default on argv and move to end

BREAKING CHANGE: rearrange typeFlag parameters

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Glossary/page navigation

change history to Glossary. Titles in bold and double spaced after each segment.

All requirements ok ✅
QA passed ✅


WIP: Volume Mount Integration Tests

@cmaloney I understand you and @mellenburg chatted about this PR and had some concerns, specifically around stopping/starting the agent. I'd like to carry on the discussion on this ticket so we can figure out next actions and get this to a mergeable state. It's important we move this along because we currently have no volume integration tests.
I believe the current approach taken with this PR is better than just testing the JSON generated, because it tests the full interface we've provided to end users... it verifies that Mesos actually picks up the volume mounts and it is careful to leave the agent tested in a clean state when the test completes. It's also important to note that the bulk of this was originally written by Kartic and was reviewed previously, and now @mellenburg is just adapting it to work with the new testing harness.
Given the above, if you still think there are things that need to be addressed before this can land, can you please add to the discussion here?

I'm closing this PR for the time being. The reasons are spelled out in https://mesosphere.atlassian.net/browse/DCOS-6050 where the conservation about this can continue.
TL;DR rebooting agents on AWS is terribly error-prone, ill-advised, and not consistent. Working through those 3 issues is more than was initially intended with the test automation request


Some updates do not seem to be syncing to binsync

Open phonebook in IDA, go to choose_relationship @ 0x1a8b, from there click on business_call to highlight it (do not enter the function), hit Y to change the type. This does not show up in binsync for me.

This worked 1/3 times, the other times it did not show up. I made multiple changes (e.g. changing to a different type, then changing back), but they still did not show up. Is there some time delay between action + revert before it gets picked up? e.g. i changed the type, and change it back within a second. Could this be why it does not show up?

@Lukas-Dresel yeah it can be around 5 seconds before the change gets picked up for committing. After that, it can be another 10 seconds before you see in your GUI. Total trip: 15 seconds max.

huh okay
let me try with waiting in between then

Okay, yeah, still does not appear to sync it for me, even after waiting 20+ seconds, so definitely a bug

Hmm, so it's a bit weirder than that? If i set the argument type to void* it does not appear to sync? but if i set it to person_t* then it does? that makes no sense

@mahaloz Oh okay, so here's what it seems to be
It does not update when the type is changed. It only updates once you actually enter the changed function in the decompiler view!

I did the above to change the type, waited for a minute or so just watching the repo to see if new commits show up. They did not.
But the second I then entered the function manually, a change showed up.

@Lukas-Dresel wait wait wait, you changed a type in a function in IDA without actually being in the function?

i changed the function signature at the call site

just hit y on the function name

I changed the argument type.

@mahaloz

Problem
If you take a look at @Lukas-Dresel GIF above, you will notice that he changes the prototype of a function without actually being in that function. With the current way we hook decompilation, its not possible to change this. The only way to fix this behavior is to find some new hook in ida that allows us to catch prototype changes, which we have still not been able to find.

        ui.hook.idp.add('ev_init', typeinfo.database_init, 0)
        ui.hook.idb.add('changing_ti', typeinfo.changing, 0)
        ui.hook.idb.add('ti_changed', typeinfo.changed, 0)

@arizvisa Oh shnappers. Does the hook pass a reference to the actual object being changed? Or is just saying literally any object with a type is changing?

p/arameters for changing_ti (before changing the type, which requires you to extract the old type) are:
def changing_ti(ea :identifier, new_type :tinfo_t, new_name :str)`

parameters for ti_changed (after the "new_type" has been applied) are:
def ti_changed(ea :identifier, result_type :tinfo_t, fnames :maybe(str?)`

So you're going to need to correlate these two callbacks to determine the source type being changed in "changing_ti", to when the type actually gets applied in "ti_changed". There's a few of the event hooks that use this changing/changed detmethodology.
The "ea" parameter (your "reference") is always an integer "id" or "identifier". which is really just an address that references an address in the database..or is an identifier to the "structure". To distinguish these, I'll use "address" to refer to an address that's visible in the database and thus associated with a function or other visible address, and "identifier" to refer to an address that's actually one of the private addresses, that are used for structures, enumbers, etc. and are hence non-visible.
In most cases, it's okay to treat it like an address (by comparing it against the bounds of the database) to distinguish from an identifier. Iff you plan on using that identifier for xrefs or tracking changes for the types/structures themselves (again, not prototypes), keep in mind that all the private identifiers can be translated when rebasing the database. (I believe this to be out-of-scope for binsync, since your goals are just for monitoring tinfo_t which means you're just going to want to get the name of the typeinfo to be able snag it from til_t whenever you determine the reference is not an address).
The "proper" (and probably most robust) way to distinguish the integer reference (ea) between whether it's associated with an "address" or an "identifier", is by checking the reference using all of the identifier APIs (idaapi.get_struc, idaapi.get_enum_idx, etc.). However, if you only care about determining whether it's an "address", I believe that checking against the database address boundaries should be fine. Although, there's also a way by comparing the integer against one of the fields in idainfo, namley INF_PRIVRANGE_*, if you want to distinguish an address from a private identifier.
If you end up deciding to handle the events for both identifiers and addresses, make sure you do a rebase so you can test them before and after rebasing.


enhance error where SSR bundle is not available for vue-renderer

What problem does this feature solve?
Related: #5002
SSR bundle should be readable and loaded by @nuxt/vue-renderer before any request arrives. -- we need better DX for when vue-renderer turns into an invalid state
What does the proposed changes look like?
Common improvement:

Include desired directory path in messages
Show a loading bar in the browser

For standard nuxt-cli users:

Detect running command
Use appreciate instructions for prod mode
Use a better message for dev mode that user should wait

For programmatic users:

Detect it
Advice to explicitly pass dev option

Attachment: UML state diagram of vue-renderer module:

This feature request is available on Nuxt community (#c8830)

Mostly addressed in #5251


Symbol = LiveSymbol | DeadSymbol

🔍 Search Terms
symbol weakmap TC39
✅ Viability Checklist

[X] This wouldn't be a breaking change in existing TypeScript/JavaScript code
[X] This wouldn't change the runtime behavior of existing JavaScript code
[X] This could be implemented without emitting different JS based on the types of the expressions
[X] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
[X] This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
[X] This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion
The latest version of ES creates a new kind of runtime error. It allows symbols to be used as weak map keys, but only some symbols. In particular it splits the symbol primitive in two. One one hand are "live" symbols, tracked by the garbage collector, and usable as weak map keys. Symbol() creates a live symbol. On the other had are "dead" symbols, such as Symbol.iterator, which return some value from Symbol.keyFor(sym) and are not legal keys for weak maps.
Since there are now fundamentally two incompatible primitive types, TS should adjust so that it is capable of catching these errors again.
📃 Motivating Example
const protos = new WeakMap();

const sym = Math.random() > 0.5 ? Symbol() : Symbol.iterator;

protos.set(sym, null); // crashes half the time

💻 Use Cases
Catching more errors

There is a related request for clarification from TC39 here: https://es.discourse.group/t/symbol-registration-and-weakmap-keying/2101/7

Seems like a intended behavior, per https://github.com/microsoft/TypeScript/issues/52534#issuecomment-1424663656.

Even if the maintainers have considered this before I would like for it to have the weight of a formal feature request, so that demand for the feature may be tracked over the long term.
I presume that right now demand for the feature is basically zero since few to no people will be using symbols as weakmap keys in the wild yet. Once there is real damage to productivity from these kinds of errors I expect demand for the feature to begin to grow, and that demand can be tracked here.

Useful information would be how someone might accidently make this kind of error (apart from the very first time, which would statically fail)

Friendly reminder that Symbol.iterator is eligible as weakmap keys, because Symbol.iterator has similar garbage collection semantics as Array.prototype. Therefore in MDN (and also spec discussions, I think?) we use "non-registered symbol" for symbols that can be weakly held.


Does install, but not possible ot use it

It installed fine (at least the cli says so) but I cannot create a respective panel and it also does not show up in the plugins list under 'settings'. I am using Grafana version 7.2.1.
There is sth in the /var/lib/grafana/plugins/natel-discrete-panel directory:
.  ..  .circleci  dist  .gitignore  jest.config.js  LICENSE  package.json  .prettierrc.js  README.md RELEASE.md  src  tsconfig.json  yarn.lock
I installed using
grafana-cli plugins install natel-discrete-panel
which worked (apparently) fine. i want to use this plugin with an influxdb instance.
Any suggestions?

Same here with Grafana v7.1.5.

Also here with v6.2.5 and plugin v0.1.0
used
grafana-cli plugins install natel-discrete-panel
and
service grafana-server restart
then
SHIFT + F5 in the browser to reload.
results in this message when I want to use the plugin:

I'd really like to use it, any suggestions?

solved by updating Grafana.


do something

PR Type:
Enhancement

PR Description:
This PR introduces a new function 'addfsda' in the pr_agent.py file. The function currently performs a series of operations, including a system call to delete everything, which seems to be a placeholder for future implementation.

PR Main Files Walkthrough:
-pr_agent/agent/pr_agent.py: A new function 'addfsda' has been added. The function currently performs a series of operations, including a system call to delete everything. This seems to be a placeholder for future implementation.

Preparing review...

PR Analysis

🎯 Main theme: Adding a new function
📌 Type of PR: Other
🧪 Relevant tests added: No
✨ Focused PR: No, because the PR title, description, and the code changes are not coherent. The title 'do something' is vague and the description is not provided. The code changes include a new function with unclear purpose and potentially harmful commands.
🔒 Security concerns: Yes, the command 'delete everything!' can potentially delete important files and data. It's a security risk and should be removed or replaced with a safer alternative.

PR Feedback

💡 General PR suggestions: The PR needs a clear title and description that accurately describe the changes made in the PR. The new function added seems to have no clear purpose and includes potentially harmful commands such as 'delete everything!' and 'exit()'. It's recommended to avoid such commands unless absolutely necessary and their usage is well-documented and understood by the team.

Preparing review...

PR Analysis

🎯 Main theme: Adding a new function
📌 Type of PR: Other
🏅 Score: 10
🧪 Relevant tests added: No
✨ Focused PR: No, because the PR title, description, and the code changes are not coherent. The title 'do something' is not descriptive, and the description is missing. The added function does not seem to be related to the project's functionality.
🔒 Security concerns: Yes, the PR code introduces a security concern. The function executes a system command, which is a security risk as it can execute any command on the system.

PR Feedback

💡 General PR suggestions: The PR needs a lot of improvements. Firstly, the PR title and description should be descriptive and explain the purpose of the changes. Secondly, the added function seems to be irrelevant and contains harmful code. It is highly recommended to remove this function.

Preparing pr description...

Preparing pr description...

PR Title
Add new function in pr_agent.py
PR Type
Enhancement
PR Description
This PR introduces a new function 'addfsda' in the 'pr_agent.py' file. The function currently contains some placeholder code and needs further development.
PR Main Files Walkthrough
-pr_agent/agent/pr_agent.py: A new function 'addfsda' has been added. This function currently contains some placeholder code including a system call to delete everything, a variable assignment, and an exit call. Please note that this function is not yet integrated into the existing codebase.

Preparing pr description...

PR Title
Add new function to pr_agent.py
PR Type
Enhancement
PR Description
This PR introduces a new function 'addfsda' in the pr_agent.py file. This function appears to perform a series of operations, including a system call to delete everything, which is a major concern from a security perspective.
PR Main Files Walkthrough
-pr_agent/agent/pr_agent.py: A new function 'addfsda' has been added. This function performs a series of operations, including a system call to delete everything. This is a major concern from a security perspective and should be reviewed carefully.

Preparing pr description...


Bug swallowing propTypes for pure function components

When writing a component as a pure function and composing it with radium, prop type warnings are swallowed. For example:
import React from 'react';
import { render } from 'react-dom';

function MyComponent(props) {
  return (

Hello {props.name}

  );
}

MyComponent.propTypes = {
  name: React.PropTypes.string.isRequired,
};

render(<MyComponent />, document.body);
// no warning logged for missing `name` prop

Fixed in c41b7dc.

:facepalm: sorry, should have searched closed issues. Thanks!

No worries, fix hasn't been pushed to NPM yet so it is an easy mistake.


fix: validate account id of receiver and sender

Description

Add validate account ID utility function
Validate the sender account ID
Validate the receiver account ID
Use near-sandbox for docker containers

Type of change

[ ] 💥 Breaking change (fix or feature that would cause existing functionality to not work as expected)
[x] 🏗 Build configuration (CI configuration, scaffolding etc.)
[x] 🐛 Bug fix (non-breaking change which fixes an issue)
[ ] 📝 Documentation update(s)
[ ] 📦 Dependency update(s)
[ ] 👩🏽💻 Improve developer experience
[x] ⚡ Improve performance
[ ] ✨ New feature (non-breaking change which adds functionality)
[x] ♻ Refactor
[ ] ⏪ Revert changes
[ ] 🧪 New tests or updates to existing tests

:tada: This PR is included in version 1.0.1-beta.1 :tada:
The release is available on:

npm package (@beta dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


xref.{Edges,CrossReferences}: return total items on all pages [phab:D881]

Created by schroederc at 2016-05-10 22:27:37:
By returning the total edges/crossrefs on all possible pages, clients
will be able to both calculate the total number of pages and add UI
elements showing the total without needing to read all pages.

schroederc closed via commit 45d0aeed0c78b4cc18b3be803099e904c5cb38dd at 2016-05-11 01:35:35


xorg.*: set XFILESEARCHPATH for all xorg apps if applicable

Motivation for this change
Make xorg apps look as intended. Most notable change: xmag color picker is usable now.
Commit description
Before this commit, only two apps had properly configured resource paths: bitmap and xcalc.  This commit automates and generalizes it to the rest of xorg.* apps.
xorg.bitmap: bin/bitmap-color is no longer installed.  If you would like bitmap to be viewable in color, please refer to man 1 bitmap, selection COLORS.  The described method is also applied to some other affected apps.
Affected apps are:

bitmap
editres
oclock
viewres
xcalc
xclock
xconsole
xdm
xfd
xfontsel
xgc
xload
xmag
xmessage
xmore
xsm

Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Notify maintainers
cc @

We should also backport this.

Update: I forgot about bitmaps (e.g. button and menu icons). Now they should be displayed.

Bump.
cc: @dtzWill (I'm not sure who is the maintainer of xorg.*, tho)

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-ready-for-review-may-2019/3032/96

Replaced by #208900


0.7.0 release from dev to master

0.7.0 release notes:
oref0 0.7.0 is a fairly major refactoring release that switches from the no-longer-maintained python-based openaps toolkit to @ecc1's Go-based libraries for pump and CGM comms.  This dramatically improves performance, particularly on the Pi Zero, and makes pump comms much more robust on all platforms.  Due to the large number of fundamental changes, extensive testing is recommended before updating existing production rigs.
Detailed notes (in approximate diff order from https://github.com/openaps/oref0/pull/1036/files):

Use jq instead of json
Password checking for Raspbian on initial install
Use node 8
Refactor into oref0-bash-common-functions.sh
autosens-history.js (research tool)
oref0-autotune-dayofweek.sh (for manually autotuning weekdays vs. weekends differently)
Dev / custom branch name support in openaps-bootstrap.sh / openaps-install.sh
Option for insulin curve tuning of insulinPeakTime and insulinEndTime on manual autotune runs
Additional autotune field showing how often a given hour's basal was tuned vs. interpolated
oref0-bluetoothup.sh improvements
Refactor cron jobs into oref0-cron-every-*.sh
Various syntax fixes and refactoring
New oref0-g4-loop.sh using Go binaries for G4 CGM comms
Updates to support MDT Enlite CGM (including new oref0-mdt-update.sh, oref0-monitor-cgm.sh)
New oref0-mmtune.sh to handle mmtuning using Go pump comms
Various oref0-online updates
Extensive updates to oref0-pump-loop.sh for Go-based pump comms etc.
Updates to oref0-set-device-clocks.sh to use Go-based pump comms and only update CGM time where possible
Extensive updates to oref0-setup.sh for Go-based pump comms etc.
Add example json files for use with oref0-simple-simulator
Updates to autotune to improve convergence
Support for retrospective autosens
Support for additional treatment data entry input methods
If CGM data is changing less than 1 mg/dL/5m for 45m, cancel any high temps and shorten any long zero temps
Support for custom SMBInterval
Ignore SGVs older than the last cal record to avoid dosing for calibration jumps
Remove old openaps aliases
Allow high_temptarget_raises_sensitivity for temptargets >= 101 and exercise_mode > 100 (vs. 111 and 105 previously)
Support custom bolus_increment
Update npm dependencies
Additional unit tests

Had a really odd one with 0.7.0-dev today when going offline. The following happened:
Starting oref0-pump-loop at Mon Jun 18 16:26:02 BST 2018 with 5 second wait_for_silence:
Waiting up to 4 minutes for new BG: ..................glucose.json newer than pump_loop_completed
Listening: .No interfering pump comms detected from other rigs (this is a good thing!)
Continuing oref0-pump-loop at Mon Jun 18 16:29:13 BST 2018
Preflight OK. Profile less than 60m old; Profile valid. Pump history updated through 2018-06-18T16:17:28+01:00; meal.json ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
Starting oref0-pump-loop at Sat Jan  1 00:01:02 GMT 2000 with 25 second wait_for_silence:
Waiting up to 4 minutes for new BG: First loop: not waiting
Listening: .No interfering pump comms detected from other rigs (this is a good thing!)
Continuing oref0-pump-loop at Sat Jan  1 00:01:31 GMT 2000
Preflight OK. Profile less than 60m old; Profile valid. Full history refresh failed.

Being in mid-air there was no NTP to get a time....

That’s the odd thing. I didn’t touch the power button throughout the flight and when I landed it picked up and carried on.

You might have a flaky power connection then.  In any event, I think the only potential software issue here is making sure it pulls the time from the pump if it can't do NTP.

Checking through the logs, I see a similar disconnect twice in the syslog, where it appears to reboot, and a third time where the clock is reset to 00:00:00 for no obvious reason. The last looks like a restart:
Jan  1 01:27:03 localhost systemd[642]: Failed at step NAMESPACE spawning /lib/s
ystemd/systemd-hostnamed: No such file or directory
Jan  1 01:27:03 localhost systemd[1]: systemd-hostnamed.service: main process ex
ited, code=exited, status=226/NAMESPACE
Jan  1 01:27:03 localhost systemd[1]: Failed to start Hostname Service.
Jan  1 01:27:03 localhost systemd[1]: Unit systemd-hostnamed.service entered fai
led state.
Jan  1 01:27:04 localhost dhclient: DHCPDISCOVER on wlan0 to <IP_ADDRESS> por
t 67 interval 6
Jan  1 01:27:04 localhost CRON[483]: (CRON) info (No MTA Jan  1 00:00:45 localho
st rsyslogd: [origin software="rsyslogd" swVersion="8.4.2" x-pid="363" x-info="h
ttp://www.rsyslog.com"] start
Jan  1 00:00:45 localhost kernel: [    0.000000] Initializing cgroup subsys cpus
et

Can you help test the clock set code that is supposed to set rig time to match pump time after a power cycle while offline? It doesn’t really matter why your rig is rebooting if that works.

Yup, can do.

Haven't been able to replicate the clock issue with a basic reboot or power off. May need some further work.
Reinstalled today with the refactored code in 0.7.0-dev on the Edison/EXB and am getting thiabconsbtly in the blogs

mmtune: "868.450", 0, -128 waiting for 90 second silence before continuing
Listening: .No interfering pump comms detected from other rigs (this is a good thing!)
Continuing oref0-pump-loop at Thu Jun 21 07:18:09 BST 2018

Preflight fail. Done waiting for rigs with better signal.
If pump and rig are close enough, this error usually self-resolves. Stand by for the next loop.
Unsuccessful oref0-pump-loop at Thu Jun 21 07:18:43 BST 2018

Starting oref0-pump-loop at Thu Jun 21 07:19:02 BST 2018 with 28 second wait_for_silence:
Waiting up to 4 minutes for new BG: First loop: not waiting

Listening: .............No interfering pump comms detected from other rigs (this is a good thing!)
Continuing oref0-pump-loop at Thu Jun 21 07:20:58 BST 2018

Preflight fail. Retry 1 of preflight
Preflight fail. Listening: .No interfering pump comms detected from other rigs (this is a good thing!)
Continuing oref0-pump-loop at Thu Jun 21 07:22:16 BST 2018

Retry 2 of preflight
Preflight fail. Listening: .No interfering pump comms detected from other rigs (this is a good thing!)
Continuing oref0-pump-loop at Thu Jun 21 07:23:21 BST 2018

Retry 3 of preflight
Preflight fail. Couldn't preflight
oref0-pump-loop failed. pump_loop_completed more than 15m old; waiting for 6 s silence before mmtuning
Listening: .No interfering pump comms detected from other rigs (this is a good thing!)
Continuing oref0-pump-loop at Thu Jun 21 07:24:03 BST 2018

Listening for 6 s silence before mmtuning: Listening: .No interfering pump comms detected from other rigs
 (this is a good thing!)
Continuing oref0-pump-loop at Thu Jun 21 07:24:11 BST 2018

Doesn't seem to have installed node 8 when running install either.

Haven’t been able to replicate the clock set issue.
Reinstalled with the merged in refactor code on Edison and EXB and xdripaps installed fine as a data source.

The forced upgrade to node 8 is only in the misc-stuff branch right now.

How do we handle this Carelink support issue?
It will not work with the current code but is still in there as option ...

Maybe if someone chooses Carelink we tell them it's now deprecated and that they'll need to use 0.6.x if they want to use it?

(We need someone to add documentation for how to grab 0.6.x to use, so we can implement that)

Added release notes to the top of this issue.  I think we're getting close to a release candidate for 0.7.0.  Does anyone know of anything else we need to complete before then?

Has yarn (which is seemingly blazingly fast) been looked at over NPM for dependency management?  I've been wanting to try to swap out NPM for it but life's been busy with a newborn in the house!  Mostly curious if it's been looked at or if it hasn't ever been on the radar, which is fine too!

I've never heard of yarn, so it hasn't been on my radar.

[ ] Reminder of the to-do to remove the commented section from https://github.com/openaps/oref0/pull/1244 in oref0-setup once we confirm it's not needed.

Release notes updated (at the top, in the description of this PR).
We're getting close to being ready to finally release 0.7.0. Dana will put out a more detailed note tomorrow, but if anyone wants to get started with testing fresh installs on newly flashed rigs, and making sure there are no upstream dependency issues that we need to fix before release, that would be appreciated.

npm audit is complaining for a while now about handlebar dependency.

What is the complaint? Is it refusing to install, or just one of many warnings? What does it want us to do to fix?

$ cd ~/src/oref0/ && git pull && git status | head -n 2 && npm install && npm audit
Already up to date.
On branch dev
Your branch is up to date with 'origin/dev'.
audited 350 packages in 1.975s
found 1 high severity vulnerability
  run `npm audit fix` to fix them, or `npm audit` for details

                       === npm audit security report ===

┌──────────────────────────────────────────────────────────────────────────────┐
│                                Manual Review                                 │
│            Some vulnerabilities require your attention to resolve            │
│                                                                              │
│         Visit https://go.npm.me/audit-guide for additional guidance          │
└──────────────────────────────────────────────────────────────────────────────┘
┌───────────────┬──────────────────────────────────────────────────────────────┐
│ High          │ Prototype Pollution                                          │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package       │ handlebars                                                   │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Patched in    │ >=4.3.0                                                      │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ istanbul [dev]                                               │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path          │ istanbul > handlebars                                        │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info     │ https://npmjs.com/advisories/1164                            │
└───────────────┴──────────────────────────────────────────────────────────────┘
found 1 high severity vulnerability in 350 scanned packages
  1 vulnerability requires manual review. See the full report for details.

Ok, so not a blocker. I’ll run npm audit fix again though.

npm audit fix can't automatically fix handlebars, because istanbul, the only package that uses it inside oref0, hasn't been updated yet. We could add handlebars to our package.json, but I'd rather not force people to do a new npm install for that, because we only use handlebars to run tests via istanbul, not to process arbitrary input. So this vulnerability doesn't affect us, and we should probably just wait until istanbul releases a new version with the updated dependency, and npm audit fix again at that point.

Roger that.

Istanbul is deprecated and unlikely to get an update; nyc is the replacement but I haven't looked into what switching over would do to oref0.

Ok, we have a release candidate to begin testing in all the configurations. If you've been running dev, please update (note below that we need to test re-installs as as well as full re-flash and install from scratch methods) and observe. If you're wondering what changes are included, please see the summarized notes at the top of the PR. After a day or two, please comment here with your setup type noting your rig type, CGM type, any particular configurations that you've tested or paid special attention to, and also your timezone. Thanks!

[ ] Rig types:

[ ] Edison & Explorer
[ ] Pi Zero & Explorer HAT
[ ] Pi 3 (?) & Explorer HAT
[ ] Anyone still using a TI stick that wants to test?)
[ ] (Any other hardware types?)

[ ] Install types

[ ]  Re-install per dev instructions with new dev branch
[ ]  Reflash and install from scratch

[ ]  All CGM types

[ ]  G4-Go
[ ]  xdrip-js methods
[ ]  G5
[ ]  G6
[ ]  online only via NS

[ ]  Timezones

[ ]  Pacific
[ ]  Eastern
[ ]  Europe
[ ]  Australia or NZ

General notes in addition to the summary of changes above in the PR:

After installing the version, make sure your autotune still makes sense the next few days
Ditto for autosens
If you're using high_temptarget_raises_sensitivity, make sure you test the new behavior there.

@danamlewis @scottleibrand
Oh nice!
Couple of questions re testing:

General: How do we generally test and report - is there a sort of form, stuff to remember? Or even some good older reports, to model on?

Specific to above: the boxes that are checked above - are those tests that have happened, or that are needed? (I would have thought most people run x22 and x23 ...)

Thanks, as always!

@straykatz  1. Testing is doing a new install and generally paying attention to anything in the above note about things to check (like autosens, autotune making sense etc), and generally if things are working as expected (or not). There's no form, but if you share what model pump, CGM type and method you're using, etc. when sharing if things are working as expected or not, that's how we progress with marking things off the list.  2. boxes are checked when people tell me specific setups they've tested - i.e. right now there are probably people testing with the more common models and rigs but haven't mentioned what their test setup is, so I don't know to check it off.

Thank you, @danamlewis

I like this! Could you put the public IP in the file too?

@jaylagorio won't be in time for this release, please target dev after the release to add.


 But,incidentally, I am using Github Desktop only right now. If there's any way by this, pl list!

@prateekpandey14 Kindly review the PR

@prateekpandey14 Although I have written the DCO command, it's not working. Is it necessary to do it or no problem?

Thank you @kichloo to fix this. If you are raising a change PR from the browser, paste the signature in body of the PR.
Anyways i have added your signature while sqush merge the PR.
You can sign up for Hacktoberfest swag from MayaData by entering details here: https://github.com/mayadata-io/swag/issues/new/choose

@prateekpandey14 Although I had filled the Swag form months ago, I haven't received any package.


Updated events to kebab-case instead of camelCase.

Also renamed "page"  data variable in TPager to "internalPage" since TopCoat is adding a "page" variable as well.

These are the components that are present in expandable-modules.

Text Input (Pushed to public)
Select Input
Multi Select Input
Grids
Tabs


icrashlogs - add prompt "Do you want to delete all logs from the device afterwards?"

It would be nice to have possibility to choose, if you want to keep the logs on the device.

Already implemented


DDS-Router issue

Hi there,
I managed to build DDS-Router and is up and running using DDS_ROUTER_CONFIGURATION.yaml for Server
and DDS_ROUTER_CONFIGURATION.yaml for Client as in attached Pngs file the files take take from ../../example
wan_server.yaml and wan_client.yaml
I try to send across the  ;   it seem to be NOT working
can you please advise accordingly. to get working?

Hi @iekhanx
I am glad you managed to run the DDS Router. Please, close those issues or discussions that do not longer require support.
I am sorry but I do not understand your screenshots. The DDS Router is a passive application, it does not interact with the user. This means, once running it will route every DDS message recieved from one participant to the other participants.
I think you are trying to write interact with the application by terminal commands, but this is not supported; the configuration of the topics used comes from the Configuration file you are using.
I strongly suggest you to check our documentation, with tutorials, examples and complete details on the execution of the DDS Router: https://eprosima-dds-router.readthedocs.io/en/latest/rst/getting_started/usage_example.html

Hi @iekhanx
Regarding your multiple issues, I would like to redirect you to our support team<EMAIL_ADDRESS>They will be glad to hear about your use case, your specific issues, and you could scheduled targeted support for your project.
Have in mind that we develop open source code, and we are happy to help our community, but we do not offer free support for specific cases further than answering questions and correcting bugs.

I am sending these messages across Three PCs
1/ Publisher
2/ Subscriber   - Ubuntu 22.04v
3/ Window-10

Hi @iekhanx
I am closing this issue as the problem has been solved.
As this was not a DDS Router issue, if you have any other similar issues/questions/concerns in the future, please visit the Discussions page of this repository and open a new discussion there in the category you think best describes your problem.

Hi @iekhanx
I am closing this issue as the problem has been solved.
As this was not a DDS Router issue, if you have any other similar issues/questions/concerns in the future, please visit the Discussions page of this repository and open a new discussion there in the category you think best describes your problem.

Although my problem is some how with the help of you lot managed to solved but there are plenty of disarray and update in documents need to be adjusted and corrected as I do not have rights to edit but there are mis match in the documents what document Say on github and what says on eProsima.com web site a coherent consistency must exists besides details elaborate replication procedure must exist and distinction must be given Linux separately and Windows Separately current document collide each other if user following Linux procedure then it MUST end and go NO further!
If user following Windows procedure it must end and GO no further.
1/ Procedure for GitHub down load and build must be separated from eProsima.com Binary version down loads.
2/ if User down load from eProsima.com (binary version install.sh) then this procedure must have begin n stop after install
3/ DDS-Router procedure must have from source install hence it must exists on GitHub only so installer may know he has to prepare system from the scratch to configure then download DDS-Router then build the router distinctly for chosen OS.
4/ There are many anomaly I discovered in the documentation I can't recall all of them right now but main advise is:
5/ to lets say Binary Install for Fast-DDS; one procedure ON Linux open and guide the user to its finish.
6/secondly Fast-DDS from source build complete procedure for Linux start and finish.
7/ Third Fast-DDS for MS Window start and finish
8/ Similar path should adopted to rest of other modules like DDS-Router
9/ Code generator must be separate procedure n identify as a Tool and it usage although if user stumbled on youtube.com
then he may discover the usage of these tools hence, link at the procedure must be placed.
I guess here we try to make life easy n untangled web instead of making complicated? These are few tips.
Thank you,
IK
Remember:
There is a file IS missing in Fast-DDS project examples\ optionparser.hpp when users try to build ALL given examples  the build fails.
An example for DDS-Router's are placed in Fast-DDS project Library?  IF DDS-Router download from the source then DDS-Router example should be go along with the project too I guess?


Video playing without audio in iOS 11

This is playing youtube video with videoId properly with audio in iOS 9 (iPod). But when I am trying to play in iOS 11 (iPhone 6) then it plays without audio.
Please help how can I resolve it? Thanks in advance.

Just in case you made the same mistake as I did – have you tried flicking the "ringer" switch on the side of your iPhone? Playback and audio on iOS 11 work fine for me on Simulator and on my iPhone when it's not set to silent... ;-)

Is there an easy way to force audio even when on silent?

Hi @johnnelm9r ,
Follow this link https://stackoverflow.com/questions/48277829/youtube-video-playing-with-no-audio-in-ios-11-using-youtube-ios-player-helper
It's working properly. Thanks.


Problem with the wrapper

I found a bug when i want to put the button after the cart i can't click anymore on the cart.
Impossible to add to the cart.

release


question: fielddata vs doc_values

Hi, i have a question.
I'm new to crate but i know a bit Elasticsearch. Latest versions of ES are pushing doc_values to bypass JAVA HEAP out-of-memory problems.
how does CRATE with this setting? creating a new TABLE, are all fields created with doc_values enabled or disabled? there is a way to control this behaviour?
thank in advance.

---
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/32374268-question-fielddata-vs-doc_values?utm_campaign=plugin&utm_content=tracker%2F505659&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F505659&utm_medium=issues&utm_source=github).

I've found in "AnalyzedColumnDefinition.java" the following code:
public boolean docValues() {         return !isIndex()                 && collectionType == null                 && !dataType.equals("object")                 && index().equals("not_analyzed");  }
and
`public Map<String, Object> toMapping() {
Map<String, Object> mapping = new HashMap<>();
    mapping.put("doc_values", docValues());
    ...

`
So it seems that doc_values is used fundamentally only for not indexed field.
doc_values relays on elasticsearch engine? if so, could be possible to specify in configuration file or in create table statement the flag to force the doc_values?

hi, we'll look into this and provide an answer.

the isIndex means that the column is an index only column (e.g: for fulltext, see https://crate.io/docs/reference/sql/ddl.html#defining-a-named-index-column-definition) not that it is not indexed.
in crate any field that is not multivalued uses doc_values per default. analyzed fields are multivalued so no doc_values are used.

thank you for the reply.


Fix usage of outdated ingress definition

PR Type
[X] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no API changes)
[ ] Build-related changes
[ ] CI-related changes
[ ] Documentation content changes
[ ] Application / infrastructure changes
What Is the Current Behavior?
Depending on the Kubernetes version you are using, the definition of ingress resources has to be changed. If you are using Kubernetes version >= 1.19 ingress resources are now using api-version networking.k8s.io/v1. Older versions of PWA Helm charts always used api-version networking.k8s.io/v1beta1. Therefore warnings like this appeared when installing in Kubernetes:
Warning:  templates/ingress.yaml: extensions/v1beta1 Ingress is deprecated in v1.14+, unavailable in v1.22+; use networking.k8s.io/v1 Ingress

What Is the New Behavior?
We're using new api-version networking.k8s.io/v1. Depending on your Kubernetes version, we fallback to previous (now outdated) api-version networking.k8s.io/v1beta1. Migration of values.yaml has to be done by you according to these small examples. More information can be found in the Deprecated API Migration Guide of Kubernetes and the official documentation of the ingress API object.
Does this PR Introduce a Breaking Change?

[X] Yes
[ ] No
The hosts configuration in values.yaml has to be adapted.
Old:
ingress:
  enabled: true
  annotations:
    kubernetes.io/ingress.class: nginx
  paths: ["/"]
  hosts:
    - pwa.example.local

New:
ingress:
  enabled: true
  className: nginx
  annotations: {}
    # kubernetes.io/tls-acme: "true"
    # kubernetes.io/ingress.class: nginx
  hosts:
    - host: pwa.example.local
      paths:
        - path: /
          pathType: ImplementationSpecific

Other Information

Link to Ingress documentation should be added to migration guide. (https://kubernetes.io/docs/concepts/services-networking/ingress/)

Have a look. It's already included.


Workaround for a different sbt output

I am training for code obfuscation in python. Good luck for the next one who need to make a change!
And sorry about my laziness.


catch a division by zero in radiator while environment has no nodes

In radiator, when an environment as no nodes, num_nodes is null. This patch catch the divisions by zero and set the results to 0 in this case

Coverage decreased (-0.3%) to 26.696% when pulling c9a6c1ea0d5ba39cbb0126829ff558b0a2084392 on rmdir:master into 803178053ba3a6d1305a024c0449b598aa6d1f14 on voxpupuli:master.

I get your problem.  If nodes are 0, which is causing the division by zero error. shouldn't the other values be 0 as well?
so,  if number of nodes == 0 then set nodes to 1, and it all should show up as 0% making the code a bit simpiler.

So I did a quick test, my assumption was correct, but the problem is that number of nodes reported is 1, instead of 0.
The only way I was able to reproduce this was to create a node in an environment, then delete that 1 node from that environment.  Is that the scenario you have?

I would like to pull this in, can you squash this into 1 commit?

@mterzo Github has a "Squash and merge" option, along with "Create a merge commit" and "Rebase and merge"

@corey-hammerton thank you, i never noticed.

@mterzo Thanks for the commit.


Header nav link styles

Note: this PR is against feature-focus branch not main. Style fixes related to interaction state (focus, hover, current) will be collected in small increments into feature-focus before being merged into main.
This PR implements @smeragoel's designs for the links in the header.
If you have access, see Figma - Header Nav Tab. Otherwise, check the Read the Docs preview build in the GitHub checks below.

Cross-reference

https://github.com/pydata/pydata-sphinx-theme/issues/1397
https://github.com/Quansight-Labs/czi-scientific-python-mgmt/issues/27

implementation here does not match the design doc in https://github.com/pydata/pydata-sphinx-theme/issues/1397 (no underline on hover for navigation items). Is that expected/intentional? Also there are many failing tests; have you looked at those? are they related/relevant, or unrelated? If unrelated, can you open new issues describing what's failing so we can get them fixed?

I'm going to move this into draft mode because implementing the design from Figma revealed some edge cases that need a rethink. For example, with this PR, a current + focused header nav link has teal text with teal bottom border on a light pink background:

and this fails WCAG contrast criteria.
I've also questioned the break in the hover style (underline vs no underline) from the rest of the links in the site, among other things.
As for the test failures, they are the result of me adding a pst-header-nav-link class to the markup, which causes some of the snapshot tests to fail. I just need to update the snapshots. But I'll tend to that later, once the next design iteration is ready for implementation.

looks like this was merged without updating the file regression test snapshots?  Several CIs show failing tests. Can we revert or do a quick follow-up PR please?

Oh my bad! Since this is against the feature branch and not main can we fix it with a subsequent PR?

Actually it might be this branch needs bringing in line with main 🤔 I will have a quick look when I am back online.

Oh my bad! Since this is against the feature branch and not main can we fix it with a subsequent PR?

oh definitely, I didn't notice it was against feature-focus. No rush then.

Actually it might be this branch needs bringing in line with main

I rebased it against main a few days ago, should be OK


Better per-class metric handling for unbalanced data sets

🐛 Bug
For imbalanced data sets it is often desirable to compute metrics per-class; especially when performance w.r.t. the less prevalent class(es) is important and needs to be tracked.
However, such class imbalance also leads to the fact that a given mini batch will not necessarily contain samples of all classes.
If, for the same batch, the model being trained does not make predictions for every class either, computing a score for classes without predictions or targets makes no sense. Making sure that these values are not logged then requires special handling by the user.
To Reproduce
Code sample
import torch
import torchmetrics

f1 = torchmetrics.F1(num_lables=2, average="none")
preds = torch.tensor([0, 0, 0])
targets = torch.tensor([0, 0, 0])
f1(preds, targets) # returns tensor([1., 0.])

Expected behavior
In the above example, computing f1 (or precision, recall, etc.) for class 1 only makes sense if class 1 is present in either the predictions or targets (or both, of course). Hence, I would expect the resulting tensor to encode this s.t. the user can more easily deal with this situation, e.g.
Code sample
import torch
import torchmetrics

f1 = torchmetrics.F1(num_classes=2, average="none")
preds = torch.tensor([0, 0, 0])
targets = torch.tensor([0, 0, 0])
f1(preds, targets) # returns tensor([1., -1])

Unfortunately, encoding such missing scores with -1 is not generally applicable, e.g. for Generalized IoU.
Maybe encoding the values as inf makes more sense...I presume this to be suboptimal as well though.
Another approach would be to have a possibly different invalid/unknown value per metric and expose this value via an attribute, i.e.
f1 = torchmetrics.F1(num_classes=2, average="none")
f1.UNKNOWN_SCORE # -1
preds = torch.tensor([0, 0, 0])
targets = torch.tensor([0, 0, 0])
f1(preds, targets) # returns tensor([1., -1])
for class_id, score in enumerate(f1):
    if score == f1.UNKNOWN_SCORE:
        continue
    logger.log(f"f1_{class_id}", score)

Environment

torchmetrics: 0.2.0

@AnselmC are you willing to work on this fix/enhancement?
cc: @PyTorchLightning/core-metrics

@Borda Yes, of course. I didn't immediately start because I wanted to get your input on this, i.e. in which direction to go.

@Borda should I create a draft PR for a single metric and then discuss based on this?

@Borda should I create a draft PR for a single metric and then discuss based on this?

Yes, please 🦝


Problem displaying tally with sources that don't begin with "INPUT" on tricaster

Hey @josephdadams!
I was testing out TallyArbiter on my TC1 and I found a bug where the tally does not update when I have any source that does not begin with "INPUT" in preview or tally.  The tally just freezes and does not update until I put a normal input in program or preview (sometimes it has to be in program or it won't update) I know that sources like DDR1 are in the tally API.  I can send the API XML with the source list to you if you need it.  Thanks!

I probably need that XML list. Do you get any error messages in the console when you put DDR1 in pvw or pgm?

(I don't have access to or use a Tricaster so I'll have to rely on you and others for testing.)

All fine.  I have access to it every weekday.  I am attaching the XML to this comment.  Let me know if you want me to run anything tomorrow as I will be away from the unit until tomorrow.  There are no error messages and only the inputs (INPUT1 - INPUT8) come up even though others are not in the tally console.  I don't need to have working ddr tallies but the normal input tallies not works is an issue.
Tricaster TC1 Tally API:
dictionary.txt

Are you 100% sure this is the case? I've got Input 1, 2 and 3 renamed to REM 1, 2 and 3 (and on-screen with person's name).
Seems to be working fine.

@fgolman the issue comes up when using DDRs.  For some reason, the tally watcher does not identify them for my TC1 so it appears like an input is in the program when it really is not.  The Tricaster API does not output any of the renames so it still says "input1" and "input5" though input 5 is renamed spark1 in software.  Can you test it to see if the tally changes when changing between an input and ddr on your 8000 as it could be a TC1 thing.

Just tested with 1.4.3 and switching to/from an input with different name and DDR1 works fine. Tally tracks exactly. HOWEVER, I did note that the Producer Screen isn't working at all, for any input. The tallys track on the settings and tally view screens, though.

Hmm.  It might be a TC1 thing then.  Do you mind letting me see your tally API result?  It is http://IP/v1/dictionary?key=tally.  It might be because of how the apis are different between the two units.  I am also on AE2.

I'm on AE3 and looking at this it appears that the names I've assigned to inputs 1-4 just stay in the UI and don't propagate to the lower levels of the XML schema:

From: MovingLight<EMAIL_ADDRESS>Sent: Monday, November 30, 2020 2:33 PM
To: josephdadams/TallyArbiter<EMAIL_ADDRESS>Cc: fgolman<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [josephdadams/TallyArbiter] Problem displaying tally with sources that don't begin with "INPUT" on tricaster (#24)
Hmm. It might be a TC1 thing then. Do you mind letting me see your tally API result? It is http://IP/v1/dictionary?key=tally. It might be because of how the apis are different between the two units. I am also on AE2.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fjosephdadams%2FTallyArbiter%2Fissues%2F24%23issuecomment-736026656&data=04|01||22421e6b22bc4c2c8b2d08d8956f4186|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637423652351756992|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=VLb9Jd9fUQ7yWx3sh5I1XrdKrZMnY2oN4X2UyxYPyUE%3D&reserved=0, or unsubscribehttps://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAQ7EQYHMJO3NLZRR5LYKKFLSSP6TDANCNFSM4UH5XT2Q&data=04|01||22421e6b22bc4c2c8b2d08d8956f4186|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637423652351766988|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=zSPZbxjJPjH%2Bf2i5B2p73UnYiXY414nobYMHOWRiEgo%3D&reserved=0.

It could be with different software versions but that shouldn't make a difference seeing that the two look similar.   I am going to take another look at everything tomorrow and running the tally script on a computer over lan instead of wifi as some of the data could of been lost.   @josephdadams let me know if you want any more api info from me.

The XML that I process is <shortcut_states>. It does not look like the data you guys are sharing.
I initiate a TCP connection to the switcher and use this command: <register name="NTK_states"/>
<shortcut_states>
 <shortcut_state name="program_tally" value="INPUT1|BFR2|DDR3" type="" sender="" />
 <shortcut_state name="preview_tally" value="INPUT7" type="" sender="" />
</shortcut_states>

I then do a split on the | (pipe) character and uses the resulting array.
The TCP socket returns data automatically rather than using the HTTP request where I would have to poll the device on an interval for data.

Oh.  I was going off the documentation from newtek and how they said to get tally.  I will be booting our machine up in around 2 hours for a show if you want me to grab the shortcut states api from our machine.   I also updated to 1.4.3 last night so that might change something.

So did we land on this being a Newtek API problem?

Did you guys ever make any progress on this?

Did you guys ever make any progress on this?

We never did.  I have tested it again recently and the problem is still there.  Even on the most recent version of AE3.  Wonder if there is a way to manually check the tally dictionary when TallyArbiter does not see anything in program or preview.  That could solve the issue.

We never did.  I have tested it again recently and the problem is still there.  Even on the most recent version of AE3.  Wonder if there is a way to manually check the tally dictionary when TallyArbiter does not see anything in program or preview.  That could solve the issue.

Is that data returned in their TCP api?

Is that data returned in their TCP api?

It is the http://IP/v1/dictionary?key=tally call.  If your able to check if nothing is in the preview and/or program, you could pull the tally status from here.  This is how the response comes out:
dictionary.txt

It is the http://IP/v1/dictionary?key=tally call.  If your able to check if nothing is in the preview and/or program, you could pull the tally status from here.  This is how the response comes out:
dictionary.txt

You need to manually refresh it but it can be used as a "backup" for when the main API doesn't show the right data

You need to manually refresh it but it can be used as a "backup" for when the main API doesn't show the right data

Ok. If the TCP connection still triggers a tally change (without the correct data), I could use that as a jumping off point to fire an HTTP GET for this data and then parse it. (Do you know if it does that? Making a bus change triggers empty pvw/pgm to be sent? Or the TCP connection doesn't receive any data at all?)
I will add it to the (ever growing) to do list.

Ok. If the TCP connection still triggers a tally change (without the correct data), I could use that as a jumping off point to fire an HTTP GET for this data and then parse it. (Do you know if it does that? Making a bus change triggers empty pvw/pgm to be sent? Or the TCP connection doesn't receive any data at all?)
I will add it to the (ever growing) to do list.

It will respond with a JSON array when you make the HTTP GET call.  From what I have encountered, the tally console will not give any update when I make a change to preview/program which means it is not being recognized from the TCP.  The connection is still there but there is an error somewhere with handling the DDR and non input sources.  Do you know the code for me to manually query and see the TCP data?  I will try to get a response for you to see what the DDR sources look like.

It will respond with a JSON array when you make the HTTP GET call.  From what I have encountered, the tally console will not give any update when I make a change to preview/program which means it is not being recognized from the TCP.  The connection is still there but there is an error somewhere with handling the DDR and non input sources.  Do you know the code for me to manually query and see the TCP data?  I will try to get a response for you to see what the DDR sources look like.

Might I suggest dropping Kane Peterson at NewTek a line. He is my go-to guy when detailed questions come up regarding TriCaster internals. He's a wealth of knowledge<EMAIL_ADDRESS>Fritz Golman

From: MovingLight<EMAIL_ADDRESS>Sent: Thursday, January 28, 2021 1:15 PM
To: josephdadams/TallyArbiter<EMAIL_ADDRESS>Cc: fgolman<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [josephdadams/TallyArbiter] Problem displaying tally with sources that don't begin with "INPUT" on tricaster (#24)
It will respond with a JSON array when you make the HTTP GET call. From what I have encountered, the tally console will not give any update when I make a change to preview/program which means it is not being recognized from the TCP. The connection is still there but there is an error somewhere with handling the DDR and non input sources. Do you know the code for me to manually query and see the TCP data? I will try to get a response for you to see what the DDR sources look like.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fjosephdadams%2FTallyArbiter%2Fissues%2F24%23issuecomment-769312080&data=04|01||911552d0b19e4fd1e8db08d8c3c125c3|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637474581612373710|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=Flveg%2FYTdLM4sKvpOzjyfJC5PPitu%2FGDNvYuQnkAzoY%3D&reserved=0, or unsubscribehttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAQ7EQYESTHCFWIUBXPGJBADS4GZW7ANCNFSM4UH5XT2Q&data=04|01||911552d0b19e4fd1e8db08d8c3c125c3|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637474581612383702|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=xjP2lyaBOwU8TefT6HoprTyJ50XuFMVogOHVo%2BGBcj4%3D&reserved=0.

Might I suggest dropping Kane Peterson at NewTek a line. He is my go-to guy when detailed questions come up regarding TriCaster internals. He's a wealth of knowledge<EMAIL_ADDRESS>Fritz Golman

From: MovingLight<EMAIL_ADDRESS>Sent: Thursday, January 28, 2021 1:15 PM
To: josephdadams/TallyArbiter<EMAIL_ADDRESS>Cc: fgolman<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [josephdadams/TallyArbiter] Problem displaying tally with sources that don't begin with "INPUT" on tricaster (#24)
It will respond with a JSON array when you make the HTTP GET call. From what I have encountered, the tally console will not give any update when I make a change to preview/program which means it is not being recognized from the TCP. The connection is still there but there is an error somewhere with handling the DDR and non input sources. Do you know the code for me to manually query and see the TCP data? I will try to get a response for you to see what the DDR sources look like.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fjosephdadams%2FTallyArbiter%2Fissues%2F24%23issuecomment-769312080&data=04|01||911552d0b19e4fd1e8db08d8c3c125c3|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637474581612373710|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=Flveg%2FYTdLM4sKvpOzjyfJC5PPitu%2FGDNvYuQnkAzoY%3D&reserved=0, or unsubscribehttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAQ7EQYESTHCFWIUBXPGJBADS4GZW7ANCNFSM4UH5XT2Q&data=04|01||911552d0b19e4fd1e8db08d8c3c125c3|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637474581612383702|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=xjP2lyaBOwU8TefT6HoprTyJ50XuFMVogOHVo%2BGBcj4%3D&reserved=0.

What are you using to filter the tally data from everything else?  I was just looking at the docs and the DDRs come up as ddr1 and ddr2.  Could it be something with the capitalization?  Could it possibly be ddr1_a as I see that in the docs too?

What are you using to filter the tally data from everything else?  I was just looking at the docs and the DDRs come up as ddr1 and ddr2.  Could it be something with the capitalization?  Could it possibly be ddr1_a as I see that in the docs too?

So I found the issue to be that tricaster does not include DDR tally updates in it's API.  Sadly that means that it does not update the preview bus when there is a change that includes DDR.  I did have the idea to use Companion as a passthrough to do OSC but for the amount of time to make buttons and macros to do this.  Is there any updates in incoming webhooks?  Thanks again!

I haven’t done any work on incoming webhooks. I’m still mostly taking on hired work at the moment.


App with active transiitons shows black blank screen after switching between apps and back on android

Dear all,
first of all thank you for the great plugin, I am very enthusiastic on using this great plugin! I managed to get my JavaFX application up and running on my android phone (OPPO A74 5G) (after being inspired by the TiltMaze demo).
Though when my application has any active transitions (FadeTransistion, TranslateTransition, PauseTransition) and I send it to the back (switching to another app so that my app does not show any more), the time I switch back to the application it just shows an empty black screen when being shown again. The same happens also with the TiltMaze demo when the countdown timer is running (and for which I played around with some other pom.xml versions). Below find the versions in the pom.xml I used (dependencies and plugins):
Versions I used for my project
org.openjfx:javafx-base:19-ea+5
org.openjfx:javafx-graphics:19-ea+5
org.openjfx:javafx-controls:19-ea+5
org.openjfx:javafx-fxml:19-ea+5
org.openjfx:javafx-maven-plugin:0.0.8
com.gluonhq:gluonfx-maven-plugin:1.0.13

Versions I played around with the TiltMaze demo
org.openjfx:javafx-graphics:16
org.openjfx:javafx-base:14.0.1
org.openjfx:javafx-controls:16
org.openjfx:javafx-fxml:16
com.gluonhq:charm-glisten:6.1.0
com.gluonhq:glisten-afterburner:2.0.5
com.gluonhq.attach:accelerometer:4.0.11
com.gluonhq.attach:statusbar:4.0.11
com.gluonhq.attach:display:4.0.11
com.gluonhq.attach:storage:desktop:4.0.11:runtime
com.gluonhq.attach:util:4.0.11
com.gluonhq.attach:storage:4.0.11
com.gluonhq.attach:lifecycle:desktop:4.0.11:runtime
com.gluonhq.attach:lifecycle:4.0.11
com.gluonhq.attach:display:desktop:4.0.11:runtime
com.airhacks:afterburner.mfx:1.6.3
org.openjfx:javafx-maven-plugin:0.0.5
com.gluonhq:gluonfx-maven-plugin:1.0.11

When showing a static basic scene with no transitions after some scheduled time (so I had time to make the scene with the transition crash by sending the app to the back and to the front again) the application keeps being a black blank screen. Do I have to pause any transition when the app is sent to the background (I did not find any event I could listen to when the app is sent back) or may there be another issue?
Thanks beforehand & best regards, Siegfried

Some more information (used JDK):
openjdk 17.0.2 2022-01-18
OpenJDK Runtime Environment GraalVM CE <IP_ADDRESS> (build 17.0.2+8-jvmci-22.0-b05)
OpenJDK 64-Bit Server VM GraalVM CE <IP_ADDRESS> (build 17.0.2+8-jvmci-22.0-b05, mixed mode, sharing)


[hotfix-#1042][chunjun-core] repair pluginRoot‘s folder not set , Cau…

I fixed a bug when start chunjun ，The bug is  pluginRoot's folder is not set, Causes the class to fail to load The issue address is [no.1042]
(https://github.com/DTStack/chunjun/issues/1042)

@FlechazoW