Execution log

While discussing #2706 we figured there is a few new timestamps we would like to add to execution record to improve user's understanding of the flow and make it easier to debug indeterminate set of problems (primarily performance related I would guess).
Problem is, there is quite a few execution states already and there's going to be even more if we are to focus on the problem seriously. Storing timestamps related to this state changes as a properties of the execution itself will quickly bloat the execution object beyond reason.
An obvious solution to the problem is to create another data structure that would hold this expanding set of data in a linear fashion.
The idea is, for every execution state mutation, we creating a log entry with the state execution transitions to and the timestamp when it happened. For some time, this this structure may exist in parallel to our current state, start_timestamp and end_timestamp to ensure backward compatibility and while providing additional context for new executions.
For now, user would have to access api directly or use st2client debug mode to get to this data, but as soon as we happy with it, we can easily add a command for it to cli and a view in web.

Lets say I just want to get a discussion going and not really expect we merge it soon. Still, to me it seems like a better way to solve #2706 than adding another property.
Question is, do you see any particular problems with that approach... well, besides the fact we haven't really discussed and designed it as a team before implementing. Tests and docs are coming as soon as I hear anything on the substance of the change.

I don't see the value of having this property on liveaction. Having on ActionExecution is fine.

I've reworked the PR by removing log from LiveAction and instead trying to figure out if status have changed during execution update. Doing so, I've substantially shortened window of opportunity for race condition. Using atomic updates would require me to use mongo specific api and then manually publish updates and dispatch triggers. Doesn't seem necessary to me, though, I might be missing something. How big of a change we get race condition between this lines and how different the situation of log getting a race versus any other field?

It's also worth nothing that re-using existing model could mean potential negative performance overhead, but that really depends on the way MongoDB does locking and handles atomic operations.
Some of the locking granularity has been improved in MongoDB 3.x (which we don't require yet, but we should) so we should research how it handles it in such scenarios. This attribute doesn't change a lot, but it would still be terrible and have bad impact if MongoDB acquired a collection-wide lock when modifying a single document.

I've reworked the PR by removing log from LiveAction and instead trying to figure out if status have changed during execution update. Doing so, I've substantially shortened window of opportunity for race condition.

Whenever we identify that a race could it is best to eliminate the race by proper code design.

Using atomic updates would require me to use mongo specific api and then manually publish updates and dispatch triggers.

Yes and we hide those behind service classes as the DB specific abstraction. Using mongo specific features is ok if we can somehow localize the code.

So @enykeev, we have two people insisting that the atomicity issue needs to be addressed. Can you add a commit and then we can merge this feature?

Besides a couple of comments, LGTM, :+1:

Please also update changelog and corresponding documentation.

Please also update changelog and corresponding documentation.

As far as I can tell we don't really have any documentation on debugging state changes (mostly a performance topic I guess). We can add an article to Troubleshooting section, although I'd prefer to dark ship this function until we create proper way to access that information through cli or ui.

@enykeev Don't worry about my comments or don't let them block your current work. If you feel confident in what you have do merge the change. I hope I have at least conveyed why the distinction exists.


Using addImage with tableToSlides() does not work

Discussed in https://github.com/gitbrent/PptxGenJS/discussions/1098

Originally posted by Strawberry0215 April 11, 2022
This function is not working for me, can you please help me here
pptx.tableToSlides("TableKanban", {
addImage: { path: "https://upload.wikimedia.org/wikipedia/en/a/a9/Example.jpg", x: 10, y: 0.5, w: 1.2, h: 0.75 }
});

The error says:
the error says:  pptxgen.min.js:2 ERROR: addImage() requires either 'data' or 'path' parameter!

The addImage method in tableToSlides() was still using the legacy url property, thus causing this issue.


Erroneously dropping variables owing to inexact variable name match

Per comment: https://github.com/JMSLab/xtevent/issues/203#issuecomment-2111173670
Check the following example
use example31, clear
xtevent y eta, panelvar(i) timevar(t) pol(z) impute(stag) window(3) savek(aa)
rename aa_evtime aa_evtime_myvar
xtevent y eta, panelvar(i) timevar(t) pol(z) impute(stag) window(3) savek(aa, replace)

the variable aa_evtime_myvar was erroneously dropped.
In general, we should check all the inexact variable matches done with unab.

@jorpppp
in https://github.com/JMSLab/xtevent/commit/359645066af4c4598785006f88066e2fa7c5d074 I implemented an exact check of the event-time dummies, event-time variable, trend variable, and interaction variables, so if required, the program drops only the variables that exactly match specific names.
in https://github.com/JMSLab/xtevent/commit/9d5bb89445dd541ee11d8c693b8c4e0839681117 I uploaded a do-file with examples to test the implementation. I also ran the test file without inconvenience.

Looks good, thanks @Constantino-Carreto-Romero. I'll start a PR.

Summary: In this issue we fixed a bug where some variables were being dropped due to inexact variable name matches.
Thread continues in


MIPI_DISPLAY_INVERT setting has no effect

Currently the MIPI_DISPLAY_INVERT has no effect because it is always defined and code checks only #ifdef and not the value.
See https://github.com/tuupola/pico_effects/issues/10

Just in case you didn't know, turns out someone has already made a PR trying to fix the issue.
https://github.com/tuupola/hagl_pico_mipi/pull/53

Fixed via https://github.com/tuupola/hagl_pico_mipi/pull/53


Missing possibility to exchange serializer and deserializer

Hello,
I would like to use your libs but a this moment missing possibility to exchange serializer and deserializer block me. Would you like to add this in future?

By exchange do you mean swap ZeroFormatter for another library?

Supported in v3.


segmentation fault in pplacer on Debian system

Bug Description
The upstream SEPP package ships a pre-compiled binary of pplacer. This binary throws a segmentation fault in my Debian server - even when calling without any arguments. The stacktrace of the dumped core let me think this must be some incompatibilities with libc or other system libraries and therefore near to impossible to get resolved, as we don't have a mechanism to re-compile pplacer from its sources
(qiime2-amplicon-2024.5) cli x86_64 ~>gdb pplacer core
GNU gdb (Debian 13.1-3) 13.1
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from pplacer...
[New LWP 930800]
Core was generated by `pplacer --help'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0xffffffffff600000 in ?? ()
(gdb) bt
#0  0xffffffffff600000 in ?? ()
#1  0x00000000006fe57d in gettimeofday ()
#2  0x00000000006c9093 in caml_sys_random_seed ()
#3  0x00000000006ce9f0 in caml_c_call ()
#4  0x0000000000ae71d0 in camlFilename__12 ()
#5  0x0000000000ae71b0 in camlFilename__10 ()
#6  0x0000000000000068 in ?? ()
#7  0x000000000056803a in camlFilename__entry ()
#8  0x0000000000ae71d0 in camlFilename__12 ()
#9  0x0000000000ae71c0 in camlFilename__11 ()
#10 0x0000000000ae71b0 in camlFilename__10 ()
#11 0x0000000000ae7040 in camlFilename__19 ()
#12 0x00007f864df07318 in ?? ()
#13 0x0000000000ae7028 in camlFilename__18 ()
#14 0x00007f864df07338 in ?? ()
#15 0x0000000000ae7008 in camlFilename__15 ()
#16 0x0000000000ae7240 in camlFilename__24 ()
#17 0x00007f864df07420 in ?? ()
#18 0x00007f864df07150 in ?? ()
#19 0x00000000004006d9 in caml_program ()
#20 0x0000000000673eeb in cblas_csyr2k ()
#21 0x00007ffc28ee7e48 in ?? ()
#22 0x0000000000a1c7f0 in caml_globals_map ()
#23 0x0000000000a1c7f8 in caml_data_segments ()
#24 0x00007ffc28eea05c in ?? ()
#25 0x00000000006be335 in caml_main ()
#26 0x00000000006be374 in main ()
(gdb)

Steps to reproduce the behavior
just call pplacer on an affected system. Mine is
(base) cli x86_64 ~>lsb_release -a
No LSB modules are available.
Distributor ID:	Debian
Description:	Debian GNU/Linux 12 (bookworm)
Release:	12
Codename:	bookworm

My proposed solution would be migrating to a slightly newer pplacer version - which I just made available to bioconda for OSX. Changes will be necessary on @smirarab s SEPP repository - which I already suggested via https://github.com/smirarab/sepp/pull/138 and an updated bioconda SEPP package, see https://github.com/bioconda/bioconda-recipes/pull/52398 - but prior to merge into bioconda, I'd rather prefer @smirarab to check and merge my PR to SEPP.

Thanks for the heads up @sjanssen2, let us know if we can do anything at the moment. Otherwise we'll keep an eye on this and update our env once it's sorted.


Tools image doesn't work on macOS

FYI: @triceam @csantanapr @timroster
Related project: https://github.com/cloud-native-toolkit/image-cli-tools
Problems:
When executing following command inside the tools image I get several problems
sh apply.sh

Problem 1: I need to redefine already defined variable values
Define in the custom-bom.yaml
        - name: gitops_repo_repo
          value: "iascable-gitops"

Request for input:
> Provide a value for 'gitops_repo_repo':
  The short name of the repository (i.e. the part after the org/group name)
> iascable-gitops

Maybe related to that issue: https://github.com/cloud-native-toolkit/terraform-ibm-vpc-subnets/issues/66
Problem 2: The token can't be inserted:
Provide a value for 'gitops_repo_token':
  The personal access token used to access the repository
>

Workaround: I edit the variables.yaml.tmp manually on the local computer and insert the needed value.
Maybe related to the issue: https://github.com/cloud-native-toolkit/terraform-ibm-vpc-subnets/issues/66
  - name: gitops_repo_token
    value: ghp_XXXX

Problem 3: Terraform init is not invoked
There are some problems with the CLI configuration:
╷
│ Error: The specified plugin cache dir /home/devops/.terraform.d/plugin-cache cannot be opened: stat /home/devops/.terraform.d/plugin-cache: no such file or directory
│
╵

As a result of the above problems, Terraform may not behave as intended.

Usage: terraform [global options] init [options]

  Initialize a new or existing Terraform working directory by creating
  initial files, loading any remote state, downloading modules, etc.

  This is the first command that should be run for any new or existing
  Terraform configuration per machine. This sets up all the local data
  necessary to run Terraform that is typically not committed to version
  control.

  This command is always safe to run multiple times. Though subsequent runs
  may give errors, this command will never delete your configuration or
  state. Even so, if you have important information, please back it up prior
  to running this command, just in case.

Options:

  -backend=false          Disable backend or Terraform Cloud initialization for
                          this configuration and use what what was previously
                          initialized instead.

                          aliases: -cloud=false

  -backend-config=path    Configuration to be merged with what is in the
                          configuration file's 'backend' block. This can be
                          either a path to an HCL file with key/value
                          assignments (same format as terraform.tfvars) or a
                          'key=value' format, and can be specified multiple
                          times. The backend type must be in the configuration
                          itself.

  -force-copy             Suppress prompts about copying state data when
                          initializating a new state backend. This is
                          equivalent to providing a "yes" to all confirmation
                          prompts.

  -from-module=SOURCE     Copy the contents of the given module into the target
                          directory before initialization.

  -get=false              Disable downloading modules for this configuration.

  -input=false            Disable interactive prompts. Note that some actions may
                          require interactive prompts and will error if input is
                          disabled.

  -lock=false             Don't hold a state lock during backend migration.
                          This is dangerous if others might concurrently run
                          commands against the same workspace.

  -lock-timeout=0s        Duration to retry a state lock.

  -no-color               If specified, output won't contain any color.

  -plugin-dir             Directory containing plugin binaries. This overrides all
                          default search paths for plugins, and prevents the
                          automatic installation of plugins. This flag can be used
                          multiple times.

  -reconfigure            Reconfigure a backend, ignoring any saved
                          configuration.

  -migrate-state          Reconfigure a backend, and attempt to migrate any
                          existing state.

  -upgrade                Install the latest module and provider versions
                          allowed within configured constraints, overriding the
                          default behavior of selecting exactly the version
                          recorded in the dependency lockfile.

  -lockfile=MODE          Set a dependency lockfile mode.
                          Currently only "readonly" is valid.

  -ignore-remote-version  A rare option used for Terraform Cloud and the remote backend
                          only. Set this to ignore checking that the local and remote
                          Terraform versions use compatible state representations, making
                          an operation proceed even when there is a potential mismatch.
                          See the documentation on configuring Terraform with
                          Terraform Cloud for more information.
There are some problems with the CLI configuration:
╷
│ Error: The specified plugin cache dir /home/devops/.terraform.d/plugin-cache cannot be opened: stat /home/devops/.terraform.d/plugin-cache: no such file or directory
│
╵

As a result of the above problems, Terraform may not behave as intended.

╷
│ Error: Module not installed
│
│   on main.tf line 1:
│    1: module "argocd-bootstrap" {
│
│ This module is not yet installed. Run "terraform init" to install all modules required by this configuration.
╵
╷
│ Error: Module not installed
│
│   on main.tf line 18:
│   18: module "cluster" {
│
│ This module is not yet installed. Run "terraform init" to install all modules required by this configuration.
╵
╷
│ Error: Module not installed
│
│   on main.tf line 46:
│   46: module "cos" {
│
│ This module is not yet installed. Run "terraform init" to install all modules required by this configuration.
╵
╷
│ Error: Module not installed
│
│   on main.tf line 58:
│   58: module "gitops_repo" {
│
│ This module is not yet installed. Run "terraform init" to install all modules required by this configuration.
╵
╷
│ Error: Module not installed
│
│   on main.tf line 79:
│   79: module "ibm-vpc" {
│
│ This module is not yet installed. Run "terraform init" to install all modules required by this configuration.
╵
╷
│ Error: Module not installed
│
│   on main.tf line 94:
│   94: module "ibm-vpc-gateways" {
│
│ This module is not yet installed. Run "terraform init" to install all modules required by this configuration.
╵
╷
│ Error: Module not installed
│
│   on main.tf line 104:
│  104: module "ibm-vpc-subnets" {
│
│ This module is not yet installed. Run "terraform init" to install all modules required by this configuration.
╵
╷
│ Error: Module not installed
│
│   on main.tf line 121:
│  121: module "olm" {
│
│ This module is not yet installed. Run "terraform init" to install all modules required by this configuration.
╵
╷
│ Error: Module not installed
│
│   on main.tf line 128:
│  128: module "resource_group" {
│
│ This module is not yet installed. Run "terraform init" to install all modules required by this configuration.
╵
╷
│ Error: Module not installed
│
│   on main.tf line 137:
│  137: module "sealed-secret-cert" {
│
│ This module is not yet installed. Run "terraform init" to install all modules required by this configuration.

Workaround doesn't work:
When I execute the apply only on my local computer I get another error: You can find her https://github.com/cloud-native-toolkit/iascable/issues/162
Steps to reproduce:
Step 1: BOM definition
apiVersion: cloudnativetoolkit.dev/v1alpha1
kind: BillOfMaterial
metadata:
  name: my-ibm-vpc-roks-argocd
spec:
  modules:
    # Virtual Private Cloud - related
    - name: ibm-vpc
      variables:
      - name: ibm-vpc_name
        value: "tsued-gitops-sample"
    - name: ibm-vpc-subnets
      variables:
      - name: ibm-vpc-subnets_label
        value: "tsued-gitops-sample"
      - name: ibm-vpc-subnets__count
        value: 1
    - name: ibm-vpc-gateways
    # ROKS - related
    - name: ibm-ocp-vpc
      variables:
        - name: cluster_name
          value: "tsued-gitops-sample"
        - name: worker_count
          value: 2
        - name: region
          value: "eu-de"
    # Install OpenShift GitOps and Bootstrap GitOps (aka. ArgoCD) - related
    - name: argocd-bootstrap
      variables:
        - name: gitops_repo_username
          value: "thomassuedbroecker"
        - name: gitops_repo_org
          value: "thomassuedbroecker"
        - name: gitops_repo_token
        - name: gitops_repo_type
          value: "GIT"
        - name: gitops_repo_host
          value: "github.com"
        - name: gitops_repo_repo
          value: "iascable-gitops"
        - name: gitops_repo_server_name
          value: "tsued-gitops-sample"

Step 2: Install colima container engine
On macOS
brew install docker colima
colima start

Step 3: Build the project based on Bill of Material BOM file
iascable build -i my-vpc-roks-argocd-bom.yaml

Step 4: Start the tools container provided by the IasCable
cd output
sh launch

Step 5: In the running container verify the mapped resources
~/src $ ls
launch.sh               my-ibm-vpc-roks-argocd

Step 6: Use output/my-ibm-vpc-roks-argocd/apply.sh to configure the terraform variables.
cd my-ibm-vpc-roks-argocd
sh apply.sh

The first 2 issues you posted are not bugs.  You have an invalid BOM yaml file.  Two things I noticed:

You are adding the name prefix to the variable within the bom.  If you want to set a default value, you would just need to add a repo variable in the variables block that is associated with the module, not gitops_repo_repo.   When iascable generates, it automatically prefixes the module name to the variable name (to avoid collisions), unless you declare it with global scope. So that gitops_repo_ prefix comes from a module with id or alias gitops_repo.

The gitops_repo_token error is b/c your variable names don't match.  See the next bullet point...

Your variables don't match the inputs of the module.  In your yaml you have variables listed that are not input variables of the argocd-bootstrap module.  If you look at the argo-bootstrap module here: https://github.com/cloud-native-toolkit/terraform-tools-argocd-bootstrap/blob/main/variables.tf you can see there is no gitops_repo_username", gitops_repo_org, gitops_repo_tokenorgitops_repo_typevariables.  However, there are variables of those names on the (minus the prefix) on thegitops` module at https://github.com/cloud-native-toolkit/terraform-tools-gitops/blob/main/variables.tf.   It looks like those modules may have gotten mixed up.
For example:

For the terraform init problem, are you trying to execute in the volume that was mapped to the container?   IE: in your steps to reproduce, you are executing in ~/src.   Is that src directory a volume that is mapped directly to the local file system?   If so, you can't write to it b/c of OS permission issues between the container engine and host file system.   That is why all of our solutions have a setup-workspace.sh script that copies the necessary files to a different directory, so that there are no permission issues.
For example:

https://github.com/IBM/automation-maximo-app-suite/blob/main/setup-workspace.sh
https://github.com/IBM/automation-data-foundation/blob/main/setup-workspace.sh
https://github.ibm.com/gsi-labs/ibmcloud-reference-architectures/blob/main/setup-workspace.sh

@thomassuedbroecker - a question about Problem 3. Are you using podman and rootful containers? If so can you check the environment in the shell to see if TF_CLI_ARGS is set?
I found that when trying to test various rootless/rootful conatiners in podman with the quay.io/ibmgaragecloud/cli-tools:v1.1 derived images that this environment variable was set which was breaking both terraform init and even terraform version

for Problem 3 - if you run set do you have a TF_CLI_ARGS variable vs TF_CLI_ARGS_apply? This commit: https://github.com/cloud-native-toolkit/image-cli-tools/commit/c9e799a7fb6c2616a468b6f60199be1bd8f7e196 fixed this issue introduced by https://github.com/cloud-native-toolkit/image-cli-tools/pull/62

If he is using the latest image, that shouldn't be an issue.   I suspect he's running into a permission issue between root/non-root user.  I think @seansund  was looking into that earlier today.

Confirmed.  The change that @timroster mentioned above somehow didn't make it into the v1.1 image.  I'm working on getting that updated, but the github action to publish is failing for unrelated reasons.   I'm working that out now...  In the meantime, @thomassuedbroecker you can update the launch script to use the v1.2 image, and it should work fine.

The Terraform init is not invoked issue should be resolved now.  You may need to purge the old image from your local machine in order for the new one to be downloaded correctly.
To purge all images in colima, run:
colima stop && colima delete && colima start

I have confirmed, it is working now using [quay.io/ibmgaragecloud/cli-tools:v1.1](http://quay.io/ibmgaragecloud/cli-tools:v1.1):

colima stop && colima delete && colima start

FYI @triceam
INFO[0000] stopping colima
INFO[0000] not running                                   context=vm
INFO[0000] done
are you sure you want to delete colima and all settings? [y/N] yes
INFO[0007] deleting colima
INFO[0007] done
INFO[0000] starting colima
INFO[0000] runtime: docker
INFO[0000] preparing network ...                         context=vm
INFO[0000] creating and starting ...                     context=vm
> Terminal is not available, proceeding without opening an editor
INFO[0031] provisioning ...                              context=docker
INFO[0031] starting ...                                  context=docker
INFO[0037] done

For the terraform init problem, are you trying to execute in the volume that was mapped to the container? IE: in your steps to reproduce, you are executing in ~/src. Is that src directory a volume that is mapped directly to the local file system?

@triceam

are you trying to execute in the volume that was mapped to the container?
-> yes

IE: in your steps to reproduce, you are executing in ~/src. Is that src directory a volume that is mapped directly to the local file system?
-> yes

Trying following:

Local machine

iascable build -i my-vpc-roks-argocd-bom.yaml
cd output
sh launch.sh

Inside the container

Copy the folder and execute apply.sh

~/src $ ls
launch.sh               my-ibm-vpc-roks-argocd
~/src $ cp -R ./my-ibm-vpc-roks-argocd ../
~/src $ cd ..
~ $ ls
etc                     my-ibm-vpc-roks-argocd  terraform
~ $ cd my-ibm-vpc-roks-argocd/
~/my-ibm-vpc-roks-argocd $ ls
apply.sh          dependencies.dot  terraform
bom.yaml          destroy.sh
~ $ sh apply.sh
...
Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: no

Stop the execution to edit the variables file to insert the missing gitops-repo_token

vi variables.yaml
cat  variables.yaml

Run apply.sh again

~ $ sh apply.sh
...
Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

@timroster Thanks, for pointing to the issue https://github.com/cloud-native-toolkit/automation-solutions/issues/181
I already did working with iascable  on the local machine and https://github.com/cloud-native-toolkit/iascable#readme as you maybe have seen in my blog posts different blog posts I made. (https://suedbroecker.net/2022/07/06/get-started-with-an-installable-component-infrastructure-by-selecting-components-from-a-catalog-of-available-modules-with-iascable/) The reason why I using tools container is that I had an issue  on the local macOS https://github.com/cloud-native-toolkit/iascable/issues/162 , because the a bin can't be executed.


Twitch accounts integration in order to utilize Twitch API

I was developing a simple plugin in order to cross reference all current on-screen characters Runescape Names with Twitch channel names - if a Twitch account exists for any of these RSN's the client would visually indicate whether their stream was live.
Such a feature would need to use Twitch's 'Kraken' API. Twitch no longer has any unauthenticated public API's - all API's require either a user auth token - or an application client token.
It is not suitable for a non Runelite admin (such as myself) to register for a Twitch Application Client Token on behalf of Runelite - additionally, this token would then need to be hardcoded somewhere. Therefore the best option is to allow the client to utilize Twitch OAuth in order to gain a user access token for making Twitch API calls.
Furthermore - using user access tokens over a client access token increases the limit of API calls per minute from 30 to 100.
Lastly, beyond my simple plug-ins idea, adding Twitch Auth to the Runelite client would open up a world of possibility for streamers to seamlessly control their streams from the client.

How would this match RSN to twitch name?

How would this match RSN to twitch name?

On PlayerSpawnEvent, get the name of the player spawned - and then use Twitch API to search for a channel name with the RSN of the spawned player.
Of course, storing the results and using the stored result for any repeat requests to reduce the amount of unnecessary API calls.

This doesn't strike me as something which would work too well since it depends on player names matching their twitch names?

This doesn't strike me as something which would work too well since it depends on player names matching their twitch names?

Yes, I certainly understand that.
The complexity of having an additional service to store a mapping of RSN's to Twitch accounts isn't something I intend on developing - nor is it something that is fitting for a plug-in.
I am unsure if the developers of Runelite would support the escalation of this plug-in into a Runelite Service capable of storing, maintaining and querying the aforementioned mapping (perhaps using Elasticsearch or some form of Cloud Database) - however I'm more than happy to contribute to the development if it's deemed as a valuable service.
However, that isn't what I necessarily envisaged for this plug-in.
The use case I am targeting is much more simple - If the RSN matches a Twitch channel (which is live)  Show an icon above their head, and give the ability to 'Right click -> Watch' to launch a browser directly to the stream.
Sure, it's slightly naive and won't detect people playing on accounts that don't match names - But I think it has a chance of identifying ~50% of small-time streamers, which I think provides great entertainment value for the user, and increased stream traffic for the small-time streamers.
Personally, I've always wondered if someone in proximity is streaming, and I would love to be able to drop into their stream and see what they're doing, how many people they're streaming for, what the goals of their accounts are etc.

I don't think implementing this is realistic because we would need to store mapping between rs name and twitch name and share it to all clients, what is just bad idea. And just relying on rs name matching channel name makes no sense because that will almost never be the case.

Hi! Thanks for replying, and sorry for my late response - work kept me unable to check-in for the past few days.

I don't think implementing this is realistic because we would need to store mapping between rs name and twitch name and share it to all clients, what is just bad idea. And just relying on rs name matching channel name makes no sense because that will almost never be the case.

For what it's worth - a few nights this past week I've observed the ongoing streams for OSRS on Twitch. From a small sample it seems about ~30% of users are streaming gameplay of a character with the RSN matching the Twitch username. I wouldn't be too quick to dismiss it's value (traffic for streamers/entertainment for players) just because of the seemingly low % of cases in which it would work.
Regarding the implementation of a mapping between Twitch names and RSN's for distribution to clients (and that being a bad idea) - I instead developed an alternative proof of concept, which you can find at this fork.
Essentially, the Runelite client keeps a local storage of players who are within the vicinity of the user - Each player within vicinity will be cross-referenced with Twitch's Helix API. Therefore the checks are happening in realtime - per user.
The proof of concept I have provided is working well, I encourage you to check it out if you have time. You will need to create a test application on Twitch with the redirect URI pointing to http://localhost, and use the provided Auth token.
However, I have hit a slight wall with development and wouldn't mind a few extra brains to help get me around this issue.
The problem I face is that the client must use an access token to query Twitch's API - For testing purposes I have been using an 'Application' based Access token - however this cannot be distributed to users.
The queries need to happen per user - as such I have been meddling with using Twitch's OAuth2, such that a user can sign into Runelite via Twitch (If they have the plug-in enabled) which gives them an access token to allow Runelite to freely query the Twitch API identified per user - however I cannot seem to workout a way to allow Runelite to get the response from Twitch (containing the Access token) after they have provided authentication.
I have attempted to implement small libraries such as Glitchlib and Twitch4J, but these don't seem to provide a solution to getting the access token after authentication - only querying the API after the user is already authenticated.
Any suggestions/ideas would be welcome.


How to use the migrate CLI tool?

The docs refer to running migrations with CLI. What's the command to run the migrate from CLI?

Hi thanks for checking out the library - I believe this is a docs issue. The (definitely recommended, definitely easiest, maybe only) way to do migrations is with the Migrator.run() from within a script.

Hi All,
I am facing the below error when I am trying to run migrations on a remote redis server.  Here is the error, please help me out.
ERROR:    Traceback (most recent call last):
File "/usr/local/lib/python3.10/site-packages/starlette/routing.py", line 645, in lifespan
async with self.lifespan_context(app):
File "/usr/local/lib/python3.10/site-packages/starlette/routing.py", line 540, in aenter
await self._router.startup()
File "/usr/local/lib/python3.10/site-packages/starlette/routing.py", line 622, in startup
await handler()
File "/usr/share/pyscripts/ServerApi/./serverapi.py", line 48, in startup_event
Migrator(redis).run()
File "/usr/local/lib/python3.10/site-packages/redis_om/model/migrations/migrator.py", line 163, in run
self.detect_migrations()
File "/usr/local/lib/python3.10/site-packages/redis_om/model/migrations/migrator.py", line 101, in detect_migrations
import_submodules(self.module)
File "/usr/local/lib/python3.10/site-packages/redis_om/model/migrations/migrator.py", line 25, in import_submodules
root_module = importlib.import_module(root_module_name)
File "/usr/local/lib/python3.10/importlib/init.py", line 117, in import_module
if name.startswith('.'):
AttributeError: 'Redis' object has no attribute 'startswith'

@chakri622 without more info I can't give a concrete answer, but two things that stand out.

you generally shouldn't need (Redis) for the Migrator, it should likely be run with empty parens Migrator().run()
you've somewhere defined your variable name as a Redis object, and it's therefore not a string, and you can't do string operations on it

@sav-norem What about when you have more than one redis instance? DB + Cache
Does Migrator know which one to index?
There isn't any concrete documentation on Migrator tool. Its very much a black box.


Clean up duplicate rows in DatasetArtifact table

Motivation
The database should give an accurate, clean representation of the corpus, and its constituent entities should not violate rules for how the product is intended to operate. Duplicate rows should not exist where they do not have functional meaning for their associated Dataset or Collection.
Definition of Done
No duplicate rows should exist in DatasetArtifact (where a "duplicate row" is determined by the combination of all non-id columns).
Tasks

Find the duplicate rows
Delete them AND remove / delete affected values elsewhere. In this case, it means removing the DatasetArtifact.id of any to-be-deleted row from the DatasetVersion.artifacts array that may contain it.

#5147 should be completed first so as to ensure no additional duplicate rows will be inserted into the database; we only want to do the db cleanup one time...


[WIP] Use Xenial image on Travis

Just testing again if we can figure out why tests run slower on Travis when using Xenial image.
Problem with using Precise is that it runs ancient versions of software such as OpenSSL, RabbitMQ, etc. and we can't upgrade and as such, we can't run some tests such as RabbitMQ SSL ones, etc.

Closing, for now.
Will re-open when it becomes relevant again (aka when we are forced to switch to Xenial from Precise).


Add mousemove event transferring in game systems

Issue
For some levels we need track mousemove event.
Fix
If world's parameter trackMouseMove is true then we send all mousemove events to realtTimeInputEvents which is processed in Systems.UI

@AndrewJakubowicz added a comment line

Are there any performance concerns in general with the large amount of events we are adding @realTimeInputEvents?

Are there any performance concerns in general with the large amount of events we are adding @realTimeInputEvents?

I haven't found serious concerns, however I've added world.trackMoveMouse (false by default) parameter to be sure and exclude ot from levels where it's not required.


Configurable Space between Text and the Right of the LT

Is your feature request related to a problem? Please describe.
Nop. Only a New Feature.
Describe the solution you'd like
Hello, I would like to be able to modify the width of LT to make a Banner that occupies 100% of the screen.
Like this.

At the moment I put a div in browser-source.html and styled it with width in px to the exact size that I will like.

I like to modify the width of LT or be able to put this div and be able to modify in the panel control.
Describe alternatives you've considered
The First idea i had is put a div into the text, and put style with width in px to exactly size i will like it. But dont like it.

Great Job. Thank for this solution.

Hi @Yonhir,
Thanks for your idea. I still don't know if I would have to make a new 100% width style. Just because not all styles can have this setting. I will think about how to add this functionality in the best way. ;)
Thanks again for your collaboration!


CNV-32392: Fix error in catalog drawer for All Projects namespace

📝 Description
This PR fixes a bug where an error alert was displayed in the catalog drawer.
Cause: Using the All Projects namespace session key in a k8sCreate call.
Issue: https://issues.redhat.com/browse/CNV-32392
🎥 Screenshots
Before

After

/lgtm

/hold

/hold cancel

@hstastna Thank you for pointing that out. I was thinking of useActiveNamespace not useParams.


Shared data: add metadata.category to labware defs; use in PD

All of Python API, Run App, and PD need to know if a given labware is a tiprack. Right now they're inferring it from labware type (to the effect of is_tiprack = 'tiprack' in 'tiprack-200ul')
This is hacky. Instead, we should have a flag in labware definitions that tells us if a labware is a tiprack or not.
Also, PD would benefit from a general categories metadata field in order to sort labware by category. If we don't put this field in the definitions, PD will have to keep its own external labware type: category data to display labware by category.
It seems like a nice metadata to have for any consumers of our labware definitions to have.
Backwards Compatibility Concerns
After making this change, users may still have the previous labware definitions (with no "category": "tiprack") persisted on their robots.
Thus in Python Server, the existing behavior where tiprack category is inferred by labware type string will need to be preserved as a fallback, for any labware with no defined category field in metadata. (Hopefully users haven't created a custom non-tiprack labware with "tiprack" in the name! In this very unlikely case, they'll have to change their labware name.)
Run App
The Python Server running on the user's robot, not Run App, is the single source of truth about labware. Run App is currently only using shared-definitions for pipette data & not for labware. Therefore to avoid inferring isTiprack from the type string in Run App, the Python Server needs to tell Run App isTiprack. So it's all on Python Server, no backwards compatibility issues for Run App.
PD
Protocol Designer is built with labware definitions data as part of the build, so it do not need to be backwards compatible; PD can rely entirely on something like const isTiprack = myLabwareDef.metadata.category === 'tiprack. If category field is missing as in previous labware definitions, PD can safely assume it's not a tiprack.
Acceptance criteria
Labware Definitions

category field in shared-data labware definitions, for all labware that can be added to the deck in PD (TBD, see Pantea's spreadsheet of categories)
Update JSON schema with optional category field, and restrict category values to a set of string enums (TBD, also see Pantea's spreadsheet for final list of categories)

{
  metadata: {
    name: string, // eg "tiprack-200ul" -- this is the existing name field we have
    category?: "tiprack" | "well plate" | "tube rack" | "trough" | etc
  }
}

Protocol Designer
PD should look in shared-data/definitions and check metadata.category === 'tiprack' to determine tiprack or not.

Tiprack inference in protocol-designer/src/file-data/selectors/commands.js  - getInitialRobotState reducer. This is to populate the initial tip state of all tiprack labware for tip tracking.
Tiprack inference in protocol-designer/src/labware-ingred/reducers/index.js - labwareOptions reducer. This is to remove tipracks from the Labware selection dropdowns.

TODO: split this out into its own ticket
TBD: What is the best way to have Python API communicate isTiprack to Run App?
Python API

Python API uses tiprack flag in api/opentrons/robot/robot.py - calibrate_container_with_instrument fn (if 'tiprack' in container.get_type():)
backwards compatibility: existing behavior should be preserved when no category field exists in metadata (see writeup above)
Python API should supply some kind of isTiprack boolean to Run App for all labware during calibration.

Run App

Tiprack inference in app/src/robot/api-client/client.js - apiContainerToContainer fn. Used to map API labware objects to Run App labware objects.
Run App should NOT look in shared-data to determine the isTiprack boolean. It should get isTiprack from the Python server.

Run App should NOT look in shared-data to determine the isTiprack boolean. It should get isTiprack from the Python server.

I agree that API should tend to be the source of truth for these sorts of things, but given that the app already leans heavily on shared-data for pipettes, until the API is the source of all truth about pipettes, I'm fine to use shared-data for labware, too.

Will we be versioning our individual labware defs?
App doesn't need isTiprack; catagory === tiprack is better

Other categories that could be useful: plate, trough, tuberack

For Python protocols, app can look in shared-data. It already does so for pipettes
For JSON protocols, app can get labware category from the protocol

@mcous I talked to @btmorr about this late Friday & he's planning to stop keeping user's shared-data in the CD card & instead put it in the wheel so it's tied to each version. So Run App could safely use shared-data as long as it's the same version as the app.
(Related: we don't need separate JSON files for custom labware because instead they can be defined in either the .py's or the .json protocols, which aids reproducibility.)

For JSON protocols, app can get labware category from the protocol

Right now the labware "type" eg trough-12row is all that is supplied in JSON protocols (along with nickname & slot), so presently JSON protocols rely on their interpreter having synchronized labware definitions. Makes sense to include other data too, though, as you suggest. Maybe all of it?

@IanLondon this ticket looks to be closed based on its acceptance criteria. Please re-open if I'm mistaken!