Request review

This issue is created to request the review
Project link
Number of people: 2 @teckim and @sabetech

Hi Team,
Good job so far!
There are some issues that you still need to work on to go to the next project but you are almost there!
Highlights 💯

Description info ✔
Tasks distributed equally ✔

Required Changes ♻

[ ] Kindly provide a description for this issue that has a title of Resolve all N+1 problems as all tasks should contain a description for a task as per this requirement.

Cheers and Happy coding!👏👏👏
Feel free to leave any questions or comments in the PR thread if something is not 100% clear.
Please, remember to tag me in your question so I can receive the notification.
Please, do not open a new Pull Request for re-reviews. You should use the same Pull Request submitted for the first review, either valid or invalid unless it is requested otherwise.

As described in the Code reviews limits policy you have a limited number of reviews per project (check the exact number in your Dashboard). If you think that the code review was not fair, you can request a second opinion using this form.

Hi @Team
Your kanban board is complete! There is nothing else to say other than... it's time to start your project :shipit:
Congratulations! 🎉
Highlights

Good kanban board setup

Optional suggestions
Every comment with the [OPTIONAL] prefix is not crucial enough to stop the approval of this PR. However, I strongly recommend you to take them into account as they can make your code better.

Kindly add a card for setting up testing libraries, this can be a group task 👍🏿

Cheers and Happy coding!👏👏👏
Feel free to leave any questions or comments in the PR thread if something is not 100% clear.
Please, remember to tag me in your question so I can receive the notification @prolajumokeoni.

As described in the Code reviews limits policy  you have a limited number of reviews per project (check the exact number in your Dashboard). If you think that the code review was not fair, you can request a second opinion using this form.


android - wrong number of threads

I created only one thread, populate it with a few pictures but the wallet shows 2 threads. The only picture not in that one thread is the avatar, does it count as a thread?

This has been cleaned up and is correct now.


"this expression cannot run in the group_by context" error

2024-07-29 14:22:57,515 ERROR [main] glue.ProcessLauncher (Logging.scala:logError(77)): Error from Python:Traceback (most recent call last):
  File "/tmp/test-polars-big.py", line 82, in <module>
    main()
  File "/tmp/test-polars-big.py", line 44, in main
    df = df.with_columns(
  File "/home/spark/.local/lib/python3.10/site-packages/polars/dataframe/frame.py", line 8858, in with_columns
    return self.lazy().with_columns(*exprs, **named_exprs).collect(_eager=True)
  File "/home/spark/.local/lib/python3.10/site-packages/polars/lazyframe/frame.py", line 2026, in collect
    return wrap_df(ldf.collect(callback))
polars.exceptions.ComputeError: this expression cannot run in the group_by context

Error originated in expression: 'col("")./home/spark/.local/lib/python3.10/site-packages/polars_hash/_internal.abi3.so:md5()'

Polars version: 1.3.0
Related code snippet
    df = df.with_columns(
      pl.col("email")
          .str.split('@')
          .list.eval(plh.col("").nchash.md5().str.slice(0,pl.element().str.len_chars()))
          .list.join('@'),
    )

I am not too sure what is the right way to use plh with df.with_columns but it seems to have a conflict when upgrading from polars 1.2.1 to 1.3.0

Related issues from polars that I've found
https://github.com/pola-rs/polars/issues/17356
https://github.com/pola-rs/polars/issues/17749

Thank you for the quick response!
I am new to polars, and after seeing your examples in README.md, it appears that import polars_hash as plh might not be necessary? Or at least the use of plh. Since I am not too sure how polars Expression plugins work.

Unfortunately it appears I still encounter the same error
2024-07-29 14:53:44,010 ERROR [main] glue.ProcessLauncher (Logging.scala:logError(77)): Error from Python:Traceback (most recent call last):
  File "/tmp/test-polars-big.py", line 80, in <module>
    main()
  File "/tmp/test-polars-big.py", line 44, in main
    df = df.with_columns(
  File "/home/spark/.local/lib/python3.10/site-packages/polars/dataframe/frame.py", line 8858, in with_columns
    return self.lazy().with_columns(*exprs, **named_exprs).collect(_eager=True)
  File "/home/spark/.local/lib/python3.10/site-packages/polars/lazyframe/frame.py", line 2026, in collect
    return wrap_df(ldf.collect(callback))
polars.exceptions.ComputeError: this expression cannot run in the group_by context

Error originated in expression: 'col("")./home/spark/.local/lib/python3.10/site-packages/polars_hash/_internal.abi3.so:md5()'

@bn-c can you give me a small sample dataframe, so that I can run your polars code?

@ion-elgreco  Another thing I've noticed, that the above code works with polars 1.2.1, but not with the newly released 1.3.0.
Would you reckon this is a polars bug?
Here's the attached sample: sample.csv

@ion-elgreco Another thing I've noticed, that the above code works with polars 1.2.1, but not with the newly released 1.3.0. Would you reckon this is a polars bug?
Here's the attached sample: sample.csv

Can you send a small sample as code please? Just a pl.DataFrame({})

@bn-c  this was a regression in polars, should be fine now. Sorry for late followup, I forgot to respond to this thread


Message body at subscriber is EMPTY with spring cloud 2020.0.1 and 2020.0.2

Describe the bug
Spring boot 2.4.3 and apache camel 3.7.3
Spring cloud version 2020.0.2  and 2020.0.1
When a message is published to a topic, at subscriber level, the BODY is empty or body from exchange is {} ,but header looks good.
When I switched to spring cloud 2020.0.0 it started working.
Sample
If possible, please provide a test case or sample application that reproduces
the problem. This makes it much easier for us to diagnose the problem and to verify that
we have fixed it.

What project are you using? Spring cloud stream?

spring-cloud-dependencies

No, that's no specific enough. What other spring cloud project are you using?

Those are the spring cloud projects I am using. Nothing else added for spring cloud.
I have camel and other dependencies added in it.

Then I don't know how to help you. This project contains only pom.xml files with references to other spring cloud projects.


Run a command from a [pipx.run] entry point

Supercedes #602.

[x] I have added an entry to docs/changelog.md

Summary of changes
Test plan

Tested by running
pipx run --spec="build @ https://github.com/uranusjr/build/archive/pipx-run.zip" build --version

TODO: Write documentation on this.

TODO: Write documentation on this.

This is the configuration I’m using to test this (against pypa/build):
https://github.com/uranusjr/build/blob/5bcd9f2fc6b3560e68e907352064466fe3253de2/setup.cfg#L39-L43

This is the configuration I’m using to test this (against pypa/build):
https://github.com/uranusjr/build/blob/5bcd9f2fc6b3560e68e907352064466fe3253de2/setup.cfg#L39-L43

OK, thanks.
So the idea is that one would need to make sure that the packages PyPI Package Name is the name of the pipx.run endpoint?  Like:
pipx.run =
    <pypi_package_name> = <package_name>.__main__:entrypoint

Is there a way to eliminate <pypi_package_name> in the example?  So that people have one less opportunity to make a mistake and make this stop working for them, when really there's only one possible value for that string?

OK, thanks.
So the idea is that one would need to make sure that the packages PyPI Package Name is the name of the pipx.run endpoint?  Like:
pipx.run =
    <pypi_package_name> = <package_name>.__main__:entrypoint

Is there a way to eliminate <pypi_package_name> in the example?  So that people have one less opportunity to make a mistake and make this stop working for them, when really there's only one possible value for that string?

Unfortunately, each entry point must have a group and a name, so it’s not possible to write
[options.entry_points]
pipx.run = <import-path>

The best possible is something like
[options.entry_points]
pipx =
   run = <import-path>

or (using an empty string as key)
[options.entry_points]
pipx.run =
    = <import-path>

Unfortunately, each entry point must have a group and a name, so it’s not possible to write
[options.entry_points]
pipx.run = <import-path>

The best possible is something like
[options.entry_points]
pipx =
   run = <import-path>

or (using an empty string as key)
[options.entry_points]
pipx.run =
    = <import-path>

That's how entry points work. What you would like to do is write:
[options.entry_points]
console_scripts =
     build = build.__main__:entrypoint

But that would be too common of a name and would break things. So now you can write:
[options.entry_points]
console_scripts =
    pyproject-build = build.__main__:entrypoint
pipx.run =
    build = build.__main__:entrypoint

Now only "pyproject-build" shows up in the console, but pip run build works. It's exactly the same thing as what you'd put in console_scripts. By the way, there's no requirement that a package only supply it's PyPI username as a package (even though very common - think of something like pkg_resources from setuptools), and you could even have a custom entrypoint that could only be accessed by run --spec build my-special-pipx-command or something.

That's how entry points work. What you would like to do is write:
[options.entry_points]
console_scripts =
     build = build.__main__:entrypoint

But that would be too common of a name and would break things. So now you can write:
[options.entry_points]
console_scripts =
    pyproject-build = build.__main__:entrypoint
pipx.run =
    build = build.__main__:entrypoint

Now only "pyproject-build" shows up in the console, but pip run build works. It's exactly the same thing as what you'd put in console_scripts. By the way, there's no requirement that a package only supply it's PyPI username as a package (even though very common - think of something like pkg_resources from setuptools), and you could even have a custom entrypoint that could only be accessed by run --spec build my-special-pipx-command or something.

Using run or an empty string (or anything not unique to the package) would likely be a disaster. If you have a dependency that also had a pipx run entry point, the two would be merged into an unordered list (I believe - that's how Numba works). You want the similarity to console_scripts.

Using run or an empty string (or anything not unique to the package) would likely be a disaster. If you have a dependency that also had a pipx run entry point, the two would be merged into an unordered list (I believe - that's how Numba works). You want the similarity to console_scripts.

You are also not limited to matching the package name; you could add multiple commands. For example, if a project did not want to provide console_scripts (say it only wanted to provide a python -m  interface (cough, rich, cough, cough), it could provide a series of pipx.run entry points, not just it's package name, accessible via --spec <package_name> <pipx.run entrypoint name>.

You are also not limited to matching the package name; you could add multiple commands. For example, if a project did not want to provide console_scripts (say it only wanted to provide a python -m  interface (cough, rich, cough, cough), it could provide a series of pipx.run entry points, not just it's package name, accessible via --spec <package_name> <pipx.run entrypoint name>.

importlib.metadata has the information which entry point comes from which package, so it's possible to choose the correct entry point when there are multiple matches. The implementation would be a bit more complicated than the current PR, but it's doable.

importlib.metadata has the information which entry point comes from which package, so it's possible to choose the correct entry point when there are multiple matches. The implementation would be a bit more complicated than the current PR, but it's doable.

I didn't know that; good to know! I still think that the current implementation is correct, since you are literally just proving a console_scripts for pipx run only, but some of my arguments are no longer valid. I still think the strongest point is the symmetry with console_scripts - authors don't need to learn something new.

I didn't know that; good to know! I still think that the current implementation is correct, since you are literally just proving a console_scripts for pipx run only, but some of my arguments are no longer valid. I still think the strongest point is the symmetry with console_scripts - authors don't need to learn something new.

Yeah, I think the current approach is more balanced, simple to implement while also easy enough for the user to use. The user experience is not perfect, but improvements would also bring drawbacks that may prove problematic.

Yeah, I think the current approach is more balanced, simple to implement while also easy enough for the user to use. The user experience is not perfect, but improvements would also bring drawbacks that may prove problematic.

Yeah, I think the current approach is more balanced, simple to implement while also easy enough for the user to use. The user experience is not perfect, but improvements would also bring drawbacks that may prove problematic.

That sounds right, I was just wondering if there was an easy way to eliminate what could be a possible gotcha for package creators.  Naming it properly should probably be pointed out in the docs.

Yeah, I think the current approach is more balanced, simple to implement while also easy enough for the user to use. The user experience is not perfect, but improvements would also bring drawbacks that may prove problematic.

That sounds right, I was just wondering if there was an easy way to eliminate what could be a possible gotcha for package creators.  Naming it properly should probably be pointed out in the docs.

So, just to double-check on how the interface is working...
If build has a pipx.run endpoint, then I'm assuming the following will not work:
pipx run bUiLd --help

It will download and install build properly from PyPI (I believe) but it won't match the likely pipx.run endpoint name of "build".
I feel like we should canonicalize the package name and/or endpoint name before matching them because of this, and any random capitalization or punctuation for example.

So, just to double-check on how the interface is working...
If build has a pipx.run endpoint, then I'm assuming the following will not work:
pipx run bUiLd --help

It will download and install build properly from PyPI (I believe) but it won't match the likely pipx.run endpoint name of "build".
I feel like we should canonicalize the package name and/or endpoint name before matching them because of this, and any random capitalization or punctuation for example.

I believe the same is true with console scripts as well though? I agree canonicalisation is the right thing to do, but it is arguably a separate enhancement.

I believe the same is true with console scripts as well though? I agree canonicalisation is the right thing to do, but it is arguably a separate enhancement.

I believe the same is true with console scripts as well though? I agree canonicalisation is the right thing to do, but it is arguably a separate enhancement.

The difference to my mind is that console scripts are between the packager and the user only, but here pipx is part of it.  And the other parts of pipx behave in a way that different capitalizations, punctuations don't matter if they are equivalent canonically.

I believe the same is true with console scripts as well though? I agree canonicalisation is the right thing to do, but it is arguably a separate enhancement.

The difference to my mind is that console scripts are between the packager and the user only, but here pipx is part of it.  And the other parts of pipx behave in a way that different capitalizations, punctuations don't matter if they are equivalent canonically.

I filed #618 for the name normalisation issue.

TODO: Write documentation on this.

Does this mean you're working on documentation for this PR?

I’m not actively writing the documentation for this.

Adding docs in "developing for pipx" would be nice.


signalbackup-tools: 20231003 -> 20231011-1

Description of changes
Update to latest version. No changes that effect build.
Diff: https://github.com/bepaald/signalbackup-tools/compare/20231003...20231011-1

Things done

Built on platform(s)

[ ] x86_64-linux
[x] aarch64-linux
[x] x86_64-darwin
[x] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[x] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.


fix: support querying k8s version with retrying

Ⅰ. Describe what this PR did
Ⅱ. Does this pull request fix one issue?

Ⅲ. Why don't you add test cases (unit test/integration test)?
Ⅳ. Describe how to verify it
Ⅴ. Special notes for reviews

cc @2456868764


The Helm monomer library is not loading (Helm data does not render) until showing the panel "Manage Libraries".


29 integrate machine learning model into mobile application

I have connected our front end to our Flask server hosted on Azure Web apps. Everything is looking good!
Merging!


[ruby] Chained Calls

The grammar seems to not handle chains calls in certain expressions (or at all). E.g.
class User < ApplicationRecord

  def self.authenticate(email, password)
    auth = nil
    user = find_by_email(email)
    raise "#{email} doesn't exist!" if !(user)
    if user.password == Digest::MD5.hexdigest(password)
      auth = user
    else
      raise "Incorrect Password!"
    end
    return auth
  end

end

The code Digest::MD5.hexdigest(password) is only picked up as a Digest.MD5 member access, and hexdigest onwards is discarded within the context of the equality expression.

What is also likely, is that we simply need a visitor under CommandCommandOrPrimaryValueContext or PrimaryValuePrimaryContext

Precedences in Ruby can be very tricky, so please don't take my word on this without proper testing, but - for what is worth - raising the precedence of primaryValue in commandOrPrimaryValue seems to fix this without breaking any tests. Diff:
Index: joern-cli/frontends/rubysrc2cpg/src/main/antlr4/io/joern/rubysrc2cpg/parser/RubyParser.g4
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/joern-cli/frontends/rubysrc2cpg/src/main/antlr4/io/joern/rubysrc2cpg/parser/RubyParser.g4 b/joern-cli/frontends/rubysrc2cpg/src/main/antlr4/io/joern/rubysrc2cpg/parser/RubyParser.g4
--- a/joern-cli/frontends/rubysrc2cpg/src/main/antlr4/io/joern/rubysrc2cpg/parser/RubyParser.g4	(revision 34a15dec8ff2ef4efe65a290f815e19def665368)
+++ b/joern-cli/frontends/rubysrc2cpg/src/main/antlr4/io/joern/rubysrc2cpg/parser/RubyParser.g4	(date<PHONE_NUMBER>438)
@@ -408,14 +408,14 @@
     ;

 commandOrPrimaryValue
-    :   command
+    :   primaryValue
+        # primaryValueCommandOrPrimaryValue
+    |   command
         # commandCommandOrPrimaryValue
     |   NOT commandOrPrimaryValue
         # notCommandOrPrimaryValue
     |   commandOrPrimaryValue (AND|OR) NL* commandOrPrimaryValue
         # keywordAndOrCommandOrPrimaryValue
-    |   primaryValue
-        # primaryValueCommandOrPrimaryValue
     ;

 block

Seems neither a visitor or the suggested parser changes will work. The parser change ended up causing a lot of warnings to be thrown on the Railsgoat repo, and the visitor addition doesn't capture the entire context required. It seems that the EqualityExpression is where the problem lies, as that only captures the user.password == Digest::MD5, and the rest is then discarded. I tried adding a visitMemberAccessCommand which manages to grab the whole line, but the ctx.primary() for this is the user.password == Digest::MD5, so similar issues were run into here.
Going to investigate different changes to the parser to see if I can't get this to work properly


build: updated @tonomy/antelope-did-resolver

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


are the "build it yourself" instructions up to date?

I was able to install/build the sdk
but when I tried pico-WSPRER build, I got the following
(minimally it seems like something understand your directory structuree i.e. /home/rob/pico-WSPERer)
I subsequently removed the  CMakeCache.txt in the build dir that the git clone created.
That helped (I guess before the build.sh the instructions should say to remove that, the first time after git clone?)
it got further then (still not complete but different error)
Originally results without that
#**********************
kevin@pc8c:~/pico_install$ git clone https://github.com/EngineerGuy314/pico-WSPRer.git
Cloning into 'pico-WSPRer'...
remote: Enumerating objects: 4762, done.
remote: Counting objects: 100% (863/863), done.
remote: Compressing objects: 100% (309/309), done.
remote: Total 4762 (delta 663), reused 588 (delta 547), pack-reused 3899 (from 1)
Receiving objects: 100% (4762/4762), 43.38 MiB | 3.81 MiB/s, done.
Resolving deltas: 100% (2775/2775), done.
kevin@pc8c:~/pico_install$ cd pico-WSPer
kevin@pc8c:~/pico_install/pico-WSPRer$ ./build.sh
mkdir: cannot create directory ‘build’: File exists
fatal: No url found for submodule path 'build/_deps/picotool-src' in .gitmodules
fatal: No url found for submodule path 'build/_deps/picotool-src' in .gitmodules
CMake Error: The current CMakeCache.txt directory /home/kevin/pico_install/pico-WSPRer/build/CMakeCache.txt is different than the directory /home/rob/pico-WSPRer/build where CMakeCache.txt was created. This may result in binaries being created in the wrong place. If you are not sure, reedit the CMakeCache.txt
CMake Error: The source "/home/kevin/pico_install/pico-WSPRer/CMakeLists.txt" does not match the source "/home/rob/pico-WSPRer/CMakeLists.txt" used to generate cache.  Re-run cmake with a different source directory.
CMake Error: The source directory "/home/rob/pico-WSPRer" does not exist.
Specify --help for usage, or press the help button on the CMake GUI.
make: *** [Makefile:3067: cmake_check_build_system] Error 1
not sure what the fatal about picotool-src is. Maybe it just doesn't know where my sdk is
I did get picotool installed during the sdk build..here's a grep of it from my notes
maybe just a side effect of not finding my sdk
After rm build/CMakeCache.txt, and ./build.sh again, I get this
Still od it complains about picotool
seems to fail on pioasm
kevin@pc8c:~/pico_install/pico-WSPRer$ ./build.sh
mkdir: cannot create directory ‘build’: File exists
fatal: No url found for submodule path 'build/_deps/picotool-src' in .gitmodules
fatal: No url found for submodule path 'build/_deps/picotool-src' in .gitmodules
PICO_SDK_PATH is /home/kevin/pico_install/pico-sdk
Target board (PICO_BOARD) is 'pico'.
Using board configuration from /home/kevin/pico_install/pico-sdk/src/boards/include/boards/pico.h
Pico Platform (PICO_PLATFORM) is 'rp2040'.
Build type is Release
TinyUSB available at /home/kevin/pico_install/pico-sdk/lib/tinyusb/src/portable/raspberrypi/rp2040; enabling build support for USB.
BTstack available at /home/kevin/pico_install/pico-sdk/lib/btstack
cyw43-driver available at /home/kevin/pico_install/pico-sdk/lib/cyw43-driver
lwIP available at /home/kevin/pico_install/pico-sdk/lib/lwip
mbedtls available at /home/kevin/pico_install/pico-sdk/lib/mbedtls
-- Configuring done (0.2s)
-- Generating done (0.0s)
-- Build files have been written to: /home/kevin/pico_install/pico-WSPRer/build
[  1%] Built target bs2_default
[  3%] Built target bs2_default_padded_checksummed_asm
[  3%] Generating dco2.pio.h
pioasm-install/pioasm/pioasm: 1: cannot open 4: No such file
pioasm-install/pioasm/pioasm: 1: ����Q�7��faGNU8: not found
pioasm-install/pioasm/pioasm: 1: cannot open
: No such file
pioasm-install/pioasm/pioasm: 11: y
: not found
pioasm-install/pioasm/pioasm: 11: �: not found
pioasm-install/pioasm/pioasm: 12: Syntax error: ")" unexpected
make[2]: *** [CMakeFiles/pico-WSPRer_dco2_pio_h.dir/build.make:73: dco2.pio.h] Error 2
make[1]: *** [CMakeFiles/Makefile2:2109: CMakeFiles/pico-WSPRer_dco2_pio_h.dir/all] Error 2
make: *** [Makefile:91: all] Error 2

building on Ubuntu 24.04.1 LTS

Ah, I think I found the issue
you have to run ./clean.sh before you do build.sh
that may be convention I'm not aware of, but should mention it in build instructions.
going much further now.

Before you tried the initial build, it looks like you skipped steps 1b and 1c:

I admit I don't know the make-file system very well, and what I do know I definitely do not like! There is definitely ways I can get it screwed up and need to start from the beginning. There is surely a better/easier way to set it up, but my intention is that if the build steps I listed are followed exactly as listed, it will work.
I will try it again with a fresh system, and update the instructions as needed. Until then, if you could please try:
-completely delete the pico-WSPRer folder
-do steps 1b and 1c
-clone pico-WSPRer and try to build it (without running clean.sh or changing anything).
please let me know if doing it that way works.

I updated the build instructions to be more thorough, and verified it works on a fresh install when following the new instructions exactly.

thanks. I think I had done the "pico extras" and git submodule init as stated
the key for me seemed to be doing "clean.sh" then the "build.sh"
thanks. I think I'm good now. I'll check out your updated instructions


Not enough details

There is not enough detail of the procedure of allowing aks cluster to use a mysql database.
A guide to bind a database with a cluster is needed. Or an alternative to OSBA.

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

ID: 6bcc6011-3106-e7fc-ff36-02bd9dcce057
Version Independent ID: 0b5ab39e-cacb-fb6a-0924-cc77028f391e
Content: Connect Azure Kubernetes Service (AKS) with Azure Database for MySQL
Content Source: articles/mysql/concepts-aks.md
Service: mysql
GitHub Login: @ajlam
Microsoft Alias: andrela

@franrebo84  Thanks for the feedback! I have assigned the issue to the content author to review further and update the document as appropriate.

@ajlam Could you please provide any update on this issue.

@franrebo84 - additional details are available here: https://github.com/Azure/open-service-broker-azure/blob/master/docs/modules/mysql.md

Closing this issue for now. Please reopen if needed.
#please-close


Hello I would like to know more about Nu Get

Thank You

Why:
Closes [issue link]

What's being changed:

Check off the following:

[x] I have reviewed my changes in staging (look for "Automatically generated comment" and click Modified to view your latest changes).
[x] For content changes, I have completed the self-review checklist.

Writer impact (This section is for GitHub staff members only):

[x] This pull request impacts the contribution experience

[x] I have added the 'writer impact' label
[x] I have added a description and/or a video demo of the changes below (e.g. a "before and after video")

I would like to contribute to more packages if there are more


feat: Numaflow UI 1.0 [WIP][DO NOT MERGE]

@numaproj/numaflow-dev - Review can be started.

what is the milestone UI has to reach for merging this ?

LGTM
@vigith


chore: migrate from lerna to nx

This is an alternative to #3512

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

@RomainMuller ICYMI https://blog.nrwl.io/lerna-is-dead-long-live-lerna-61259f97dbd9

@andrestone thanks for the pointer... I had seen this, which is why I ended up back-burner-ing those PRs... There might still be some interest in integrating nx (now - perhaps not to replace lerna, maybe to supplement it...?)

Closing as lerna is no longer dead as Nrwl has taken over maintaining it.


ParabolicSmoother fails with "original ramp 0 in collision"

Sometimes, seemingly after planning, the return value of robot.GetNonAdjacentLinks() changes. This is quite surprising because we only use closed environments during planning. Also, the return value of robot.GetAdjacentLinks() does not change. This should not be possible because the two sets partition the set of pairwise link combinations.

We've switched to HauserParabolicSmoother, so this is no longer an issue.


Add a render_with_values method?

It could allow to create variables with given values before generating the template. Could be useful if there are variables outside of the type.

Not possible, however we can add a new API to the Template proc-macro to allow to add values at compile-time.

Do you mean it's not possible because the type of the value passed needs to be available at compile time? Because right now, given a template type T and a value type V you can create a wrapper struct (oversimplified)
#[derive(Template(...))]
struct WithValue {
    template: &T,
    values: &V,
}

except the fields of T are not available without prefixing template.. I was imagining an extension to the Template derive that would do this automatically and be used like:
#[derive(Template(with_value = V, ...))]
struct T {
   ...
}

Making it generic over V seems harder, although one possibility is to essentially replace the type V with impl ValueForT for a

The problem is that we only have access to the fields of the current struct, no other information. So for this feature to work, if it's at runtime, it means that all unknown fields like {{ x }} will need to be generated differently. Let's say we take a hashmap into the render_with_values() method. Then for each unknown variable, we'd replace them with getting a value from the hashmap. I'm not sure if it's a good idea in this case.
The other approach I suggested is to instead list values in the template proc-macro directly. Like that, we can still generate the best possible code. However, since it's in a proc-macro, the kind of values which can be used will be limited to booleans, integers, strings, tuples and maybe slices. So I'm not sure if it's a good idea either. It's a tricky feature.

I have a use case for such a method in docs.rs where we have a csp_nonce variable which is only generated when rendering the item. So it's a "dead" field until then. Now I'm thinking that we could maybe introduce a "run-time" kind of variable/struct. Like rinja_vars.get::<TYPE>("VAR_NAME")? What do you think @Kijewski ?

So, it's like a Cell<Option<_>> that is filled when first used?
Sorry, I'm on vacation right now, and I won't give any programming question a deeper thought until next Sunday. :) If you want to, maybe you could tell me / link the lines of code that could use that feature and I'll have a look when I'm back home.

Nah, please don't answer until you're back from holiday. We can discuss when you're back, there is no hurry (I'm in holiday too, yeay).


Long dropdown menu gets cut off

When creating a DropdownMenu that has a long list of DropdownMenuItems, if the list is long enough that the popup extends past the edges of the window, the list gets cut off.  I'd like to see a way to create a scrollable dropdown menu, or be able to give it a fixed height with automatic scrolling capability.
Here is how I'm creating the DropdownMenu:
DropdownMenu(
    expanded = isExpanded,
    onDismissRequest = { isExpanded = false }
) {
    LazyColumn {
        itemsIndexed(
            items = menuItemList,
            itemContent = { index, item ->
                DropdownMenuItem(onClick = {
                    selectedIndex = index
                    isExpanded = false
                }) {
                    Text(index.toString())
                }
            }
        )
    }
}

When that list is long enough to extend past the contraints of the window, it just gets cut off and is not scrollable.  Is there a way to make it scrollable or is that not possible yet?  Is there another recommended way of handling long selectable lists of data?

DropdownMenu doesn't need LazyColumn inside, dropped menu it's ColumnScope so it's scrollable as default. Also you can modify your dropped menu length with Modifier.size/height.
                Box(
                    modifier = Modifier
                        .size(70.dp, 50.dp)
                        .wrapContentSize(Alignment.TopStart)
                ) {
                    Text(
                        text = "anyList[varIndex]",
                        modifier = Modifier
                            .fillMaxWidth()
                            .clickable(onClick = { someBooleanVariable = true })
                    )

                    DropdownMenu(
                        expanded = dropMenuSeries,
                        onDismissRequest = { someBooleanVariable = false },
                        modifier = Modifier
                            .size(70.dp, 250.dp)
                    ) {
                        anyList.forEachIndexed { index, element ->
                            DropdownMenuItem(onClick = {
                                varIndex = index
                                someBooleanVariable = false
                            }) { Text(text = "$element") }
                        }
                    }
                }

I had no idea it would be so easy, or that ColumnScope was scrollabel by default.  Thank you!

Please check the following ticket on YouTrack for follow-ups to this issue. GitHub issues will be closed in the coming weeks.


buildUI should not set black background

In EAIntroView.m, line 185 in buildUI method the background color should not be black. Set it to clearColor or make it customizable
self.backgroundColor = [UIColor clearColor];

It's a step forward to achieve this: https://github.com/ealeksandrov/EAIntroView/issues/71

In d5c796e484f2a6109a8d1129dc99d49c18d0a529 backgroundColor now is clearColor if any page's alphaValue is different from 1.0. Default is still blackColor to preserve original appearance.
Remember that it could be changed outside of EAIntroView implementation (intro.backgroundColor).


Adding a tip about a pull request's base branch

In these Halp tickets(content quoted 👇), users have asked us about what the expected behavior should be when a pull request's base branch is updated:

it seems like the .base.sha field is not always set to the actual base commit of the PR, but instead to the latest commit of the base branch at the time the PR got created.
Here's how to reproduce:

Create a branch from master
Add new commits to the branch
Add new commits to master
Create a PR for the branch
Observe API results:

$ curl https://api.github.com/repos/neelance/apitest/pulls/1 | jq '.base.ref'
"master"
$ curl https://api.github.com/repos/neelance/apitest/pulls/1 | jq '.base.sha'
"c6e35b7668c32b21f08c8bad31e242f0862f6eb4"
$ curl https://api.github.com/repos/neelance/apitest/pulls/1/commits | jq '.[0].parents[0].sha'
"e726b8e3fb152fc4b172b234c69d884001fb87fa"
This behavior at least quite unexpected. I am currently also talking to the support of https://codecov.io/ because their system actually displays the wrong diff because of this.

also

I have a PR that has been opened for a few days now, and the base branch has been updated since then. However, while viewing diffs in the PR, it seems like the diffs are based on the base branch at the time of the creation of the PR.
So for example let's say my base branch is called "base" and the branch I want to merge is called "updates". Now on Monday I open a PR to merge updates into base. On Tuesday someone pushes new commits to base. The thing is, my PR opened on Monday doesn't take these in account, and the diff I'm viewing is the same I had on Monday.

Let's include a quick tip about it wherever best applicable, maybe in the Changing the base branch of a pull request article:

When you open a Pull Request, GitHub will set the base to the commit that branch references. If the branch is updated in the future, GitHub will not update the base branch's commit.

I want to take this up!

Can I use a block quote to indicate this tip?

This has been done now. Closing


Fix new LIFX Downlight product definitions

Signed-off-by: Avi Miller<EMAIL_ADDRESS>

Sorry for the inconvenience. I didn't notice that the extended_multizone value was wrong in the initial PR.

I must've saved over the version generated by update-products.py by mistake before committing. Really sorry about that!


Fixed directory structure of the Extensions to make packaging work

I've changed the directory as per our discussions. I've standardized it, keeping the Src and Tests together inside an extension.
Now packaging of all the extensions, works.

looks good, assuming these are only path changes.


Use the latest Node.js version in PKG

@igorklopov is working on compiling the PKG binaries for the latest Node.js version that contains support for HTTP/2 (without a flag). Once that's done, we can merge this PR.
This PR is blocking #953.

Just tried to fix it, but I can't get it to work. @igorklopov any ideas? If I leave the flag away, it's missing the http2 module and if I add it, Node complains that it's not supported. Can you please try compiling this branch with pkg and then fix it so that it works? 🙏
It's blocking release of #953.

@igorklopov We need this. Travis CI doesn't check out the branch information otherwise - but we need it in the deployment step.


Trace graph can't display when the page opens the reload function

Please answer these questions before submitting your issue.

Why do you submit this issue?
[ ] Question or discussion
[x] Bug
[ ] Requirement
[ ] Feature or performance improvement

Fix in d4a0ee8c4955c06f924a139b09b7037a38beffee


hyperlink not generated for {@link type#property}

What package is the bug related to?
typedoc-plugin-markdown
Describe the issue
When using @link to reference a type property, the generated markdown is not hyperlinked.
Repro: https://stackblitz.com/edit/vitejs-vite-rq6ycbce
export type Foo = { name: string };

/**
 * Foo Handler that takes {@link Foo} and uses {@link Foo#name name}
 */
export const handleFoo = (a: Foo) => {};

Steps to Reproduce

Open repro
npm run docs:md
View docs-md/functions/handleFoo.md

Actual Result
Generated markdown does not hyperlink the name property:

# Function: handleFoo()

> **handleFoo**(`a`): `void`

Foo Handler that takes [Foo](../type-aliases/Foo.md) and uses name

Additional Information

The issue does not occur when generating html files (npm run docs:html)
The type Foo itself does get hyperlinked
I tried applying useHTMLAnchors=true but this did not result in name being hyperlinked either.  In fact, there didn't seem to be any anchor elements generated at all - possibly I'm misunderstanding useHTMLAnchors or this may be a separate bug/issue?

TypeDoc configuration
typedoc: 0.27.3
typedoc-plugin-markdown: 4.3.1
typescript: 5.7.2
Expected behavior
The property name should be hyperlinked.

Thanks - links on props are now resolved in<EMAIL_ADDRESS>You would only need to set useHTMLAnchors=true when the property is included inside a table (without associated heading anchor).

Thanks for the quick fix @tgreyuk and appreciate the clarification on usage of useHTMLAnchors!
Types are looking good with this fix but there is a strange issue with interfaces.
Repro: https://stackblitz.com/edit/vitejs-vite-zdmljw8o
When using typeDeclarationFormat='table' a link is generated for interface#property but it does not contain the property fragment in the url.  This does not happen when typeDeclarationFormat is set to list or htmlTable.  When adding useHTMLAnchors, the problem does not occur but since I don't believe typeDeclarationFormat has anything to do with interfaces, I would expect the interface link to generate correctly without requiring useHTMLAnchors, correct?

Using list or htmlTable (use npm run docs:md) - Expected

Using table (use npm run docs:md2) - Not Expected

Using table and useHTMLAnchors (use npm run docs:md3) - Expected

but since I don't believe typeDeclarationFormat has anything to do with interfaces, I would expect the interface link to generate correctly without requiring useHTMLAnchors, correct?

You are absolutely correct, this isn't quite correct. The idea is that when an anchor cannot be resolved it fallsback to the nearest available anchor, but like you say the interface anchors should not be effected by the options you have set. Also foo.md#__type is not a correct fallback.
Thanks again - ill be fixed in next patch.

<EMAIL_ADDRESS>includes fixes as discussed.

Thanks @tgreyuk!
Just tested with 4.3.3 & latest typedoc 0.27.5 and things are improved, however one issue remains although I'm not 100% sure if it's expected or unexpected.
When running docs:md2, the following is output - note that the fragment to #name is missing:

When running docs:md3 which includes --includeHTMLAnchors the expected output is generated:

Would you expected docs:md2 to include the fragment for #name or would this only be emitted when --useHTMLAnchors is specified?
Updated Repro: https://stackblitz.com/edit/vitejs-vite-hbrlg3nz?file=docs-md2%2Ffunctions%2FhandleFoo.md

Thanks @techfg,

Would you expect docs:md2 to include the fragment for #name or would this only be emitted when --useHTMLAnchors is specified?

This assumption is correct currently - the reason being that when properties are rendered in a table there is no anchor to link to in the page.
However I appreciate that this is not very intuitive so should be addressed. It also means that anchors will get added everywhere (including next to markdown headings) where they are not needed.
I think the most obvious thing to do would be to automatically add html anchors to relevant table cells in this use-case, or make "useHTMLAnchors" a bit smarter. I think for simplicity adding anchors automatically in this scenario makes sense.
The initial rationale for not adding html automatically was that not all parsers support html, but as GFM supports html and markdown tables do not render without GFM, this is not a valid consideration.

Thanks for providing the context/background.

The initial rationale for not adding html automatically was that not all parsers support html, but as GFM supports html and > markdown tables do not render without GFM, this is not a valid consideration.

Possibly I'm misunderstanding what you're staying here must markdown tables are supported beyond GFM I believe.  With the recently added defaultRemarkPlugins remark-gfm may not even be used
If starting over, I think generating anchors everywhere with an option to restrict may be best.  However, in order to not introduce a potential breaking change and to provide backwards compat, possibly extending --useHTMLAnchors to have a mode instead of just a boolean that would drive which anchors are emitted makes sense?  Alternatively, a separate option that allows refined control over which leaving --useHTMLAnchors as it is.  Not ideal to introduce a new option but thinking of backwards compat if anything were to change in the way the final generated output made.
I think if you do add anchors to tables by default for this use-case, there may need to be a way to disable them for certain scenarios/use-cases.
All that said, I'm not even going to pretend to understand all the complexities of typedoc & typedoc-plugin-markdown and may be misunderstanding your comment to begin with so take the above FWIW 😄
Thanks again!

@techfg thanks for comments.

Possibly I'm misunderstanding what you're staying here must markdown tables are supported beyond GFM I believe.

Yes you are correct, markdown tables are indeed supported beyond GFM (which was an early adopter). Its really a bit of a mute point as most users will be consuming markdown beyond CommonMark (which does not include markdown tables as part of its spec).

With the recently added remark-gfm may not even be used

This is relevant only when performing additional parsing with Remark using typedoc-plugin-remark. Remark converts a Markdown string to an AST and back to Markdown, supporting only the CommonMark specification by default.

However, in order to not introduce a potential breaking change and to provide backwards compat, possibly extending --useHTMLAnchors to have a mode instead of just a boolean that would drive which anchors are emitted makes sense?

For now i think we could preserve the "useHTMLAnchors" as a singular option which accepts a mode (but will also allow boolean value for backward compatibility).

"always" - add anchors everywhere - (same as true)
"never" - html anchors are never used (same as false)
"auto" -  based on the context or configuration (ie add to table cells when relevant)

Do you think this makes sense?

Just to make sure I'm understanding your idea correctly:

Change useHTMLAnchors from boolean to boolean | 'always' | 'never' | 'auto'
Default behavior of the plugin remains the same, nothing changes in the emitted markdown from what is currently there (aka. useHTMLAnchors defaults to false/never)
Specifying --useHTMLAnchors or --useHTMLAnchors always would change the behavior of the current equivalent (--useHTMLAnchors) to add anchors everywhere instead of just table cells
always or auto can be used (e.g., --useHTMLAnchors always) to control where/how anchors are emitted

Am I understanding correctly?
Also, for my education, what other scenarios beyond table cells would auto potentially apply to?

Am I understanding correctly?

Correct
Correct
Equivalent to current useHTMLAnchors=true which will add anchors to any symbols whether it be a heading or table cell.
The idea is that "auto" would only add anchors where they do not exist by default - ie table cells.

Also, for my education, what other scenarios beyond table cells would auto potentially apply to?

Anchors would only ever be applied to next to headings or inside a table cells. The initial problem this option was trying to solve is that some parsers do not automatically assign header ids to html. It was then extended to also include anchoring to properties in table cells.
Perhaps simply an option with flags might be better (or an additional option that defaults flags to true).
useHtmlAnchors: {
  headings: false,
  tables: false
}

Hope this makes a bit more sense :)

Thanks!  Just one clarification....the current behavior of --useHTMLAnchors will add to both headers & table cells, correct?
Assuming yes to above, then always (aka true) is appropriate naming and I think you're approach makes a lot of sense as it maintains full backwards compat as a starting point.
From there, I do agree that having flags nested instead of just auto likely would be better since it will provide you more flexibility for future and also allow users to "self-configure" rather than rely completely on the plugin to "guess" (even if its a very educated one) on what "should" happen.
In short, always would put them everywhere the plugin supports (currently headers & table cells but could be more locations in future), while { headings: boolean, tables: boolean } provides the user control and both the plugin (aka. you 😄) and the user flexibility moving forward.

Thanks! Just one clarification....the current behavior of --useHTMLAnchors will add to both headers & table cells, correct?

Yes this is correct.
I will take this away - i think we are on the same understanding now - just need to decide on the exact option configuration!

Sounds great and thanks for the patience in answering all the questions, just wanted to make sure I had a full and accurate understanding prior to providing my thoughts :)
Appreciate all your work, thank you!

No problem at all - thanks for the discussion.

@techfg .
Ok - after some deliberation on this I decided to implement what I think is the most simplistic and deterministic approach.
As per changelog entry:
Anchor IDs are now applied to linkable symbols within table rows by default. Previously, the useHTMLAnchors option was required, but since there is no alternative way to link to these items, this behaviour is now the default.
I don't consider this a breaking change and I think is acceptable to release this change under a minor version.
I will consider implementing the ability to turn this off if somebody has a good enough reason to request not to have it.
"useHTMLAnchors" now only applies to page headings for platforms that dont provide automatic header ids.
Hopefully this makes sense as I dont want to needlessly over complicate the options.
Available in<EMAIL_ADDRESS>

Looks good in v4.4.0 per expected behavior in changelog, thank you @tgreyuk!


[5.7][Type Resolution] Resolve (any P.Type).Type as the metatype of an existential metatype.

Cherry-pick of https://github.com/apple/swift/pull/42380

Explanation: Until we model ExistentialMetatypeType as ExistentialType(MetatypeType), type resolution needs to look through the instance type repr when resolving a metatype. Otherwise, there's no way to distinguish between P.Type.Type, which is an existential metatype, and (any P.Type).Type, which is the static metatype of an existential metatype.
Scope: The change is scoped to resolving metatypes of existential metatypes during type resolution.
Risk: Low.
Testing: Added a couple cases to test/type/explicit_existential.swift
Reviewer: @CodaFi

Resolves: rdar://91784600

@swift-ci please test


Start markdown

[x] B
[ ] D
[ ] A
[ ] E

#2
![(https://github.com/horaciovasconcellos/skills-communicate-using-markdown/pull/2)

https://github.com/github/docs/labels/enhancement


test: youch without source-map and access publicPath in spa

Codecov Report

Merging #2340 into dev will increase coverage by 0.4%.
The diff coverage is n/a.

@@            Coverage Diff            @@
##              dev    #2340     +/-   ##
=========================================
+ Coverage   98.88%   99.29%   +0.4%
=========================================
  Files          15       15
  Lines         990      990
=========================================
+ Hits          979      983      +4
+ Misses         11        7      -4

Impacted Files
Coverage Δ

lib/core/renderer.js
98.76% <0%> (+1.65%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 4cafca0...4108740. Read the comment docs.


Nsight Perf SDK performance counters for D3D12, D3D11, Vulkan, OpenGL, Windows, and Linux

This implements performance counters using the NVIDIA Nsight Perf SDK, supporting the latest NVIDIA GPUs and D3D12, D3D11, Vulkan, OpenGL, Windows, and Linux. With this patch, when a user with an NVIDIA GPU first opens the performance counter selection dialog in RenderDoc they will find the following message directing them to download and install the Nsight Perf SDK library. After installing the library and reopening the capture, Nsight Perf SDK counters become available.

This will need to be rebased onto latest now that the precursor PR is merged. FYI for the future it's best to PR dependent changes one at a time.

This is rebased now, and all of the CI is passing except for what looks like some unrelated failure installing Mac Homebrew dependencies.


PAPI transactions make Nova crash (part 2)

Hey frens,
Adding a mortality to transactions didn't fix the Nova crashes when submitting a tx.
On the below screenshot is the background process's log of talisman when running in dev mode. There we see the SignerPayloadJSON object sent by the dapp clearly.
First transaction is a xcm transaction initiated with polkadot.js api (from app.talisman.xyz)
Second transaction is a swap initiated with PAPI (from kheopswap.xyz)
2 main differences :

the left padding with 0s on fields that contain a number encoded as hex
tip property is missing on PAPI's payload
not sure about this one but the transaction version value is different, i would have expected the last characters to be the same on both

I hope this helps

suggested test procedure :

run kheopswap locally (ask me if you need access)
use ngrok to obtain an internet accessible url for the locally hosted app
enter that url in nova dapp browser
disable light clients from network menu at the top right of the dapp (LCs are very slow on mobile, on kheopswap at least)


Access violation in glbinding.dll

I tried glbinding on Ubuntu 14.04 and compiled it with cmake. Everything works and it's really great, so heads up on that! On Windows 8.1 64-bit and through Visual Studio 2013, I compiled glbinding for 64-bit and all went well. I transferred my source files to a Visual Studio project solution and included and linked glbinding, and I've added the appropriate dlls to the folder the .exe file is in; but I get a strange error. Visual Studio throws an exception whenever I try to run my program, and it then says that the source of the exception is from glbinding.dll. At first I thought there was a problem on my end, but the code features nothing detrimental. I therefore compiled glbinding.dll again and readded it to the project, but I still get the same errors. It keeps giving me exceptions after exceptions with 'Access Violation Reading location 0xFFFFF...'. I compiled my program through both Debug and Release modes - the same issue remains.
What's going on here, how can I fix it; and is it possible that a pre-compiled version of glbinding be made available? Are there certain compiler options I should be enabling on cmake?

Your error description sounds rather strange and we have several users with your configuration that have no problem using glbinding.
If you want to try a pre-compiled version, the one for Windows 8.1 64-Bit and MSVC12 (Visual Studio 2013 Update 3) is available here: https://github.com/hpicgs/glbinding/releases/tag/v1.1.0

I suggest you have a look at your compiler options and determine if you use the exact same runtime library glbinding is built with.  The compiler and linker flags used to build glbinding can be found in the file cmake/PlatformWindowsMSVC.cmake.

Thanks people, there were OpenGL mismatches since my laptop only supports 4.0; my computer supports 4.3. I used your pre-compiled libraries and now my program runs. Thanks!


Incorrect setting the expiration date for a cookies

There are 3 classes using setting the expiration date for a cookies: RsFlash, PsCookie, RsReturn. All of them use the following code for expiration date calculation :
 String.format(
                Locale.ENGLISH,
                "Expires=%1$ta, %1$td %1$tb %1$tY %1$tT GMT",
                new Date(
                    System.currentTimeMillis()
                        + TimeUnit.HOURS.toMillis(1L)
                )
            )

the expiration date declared as GMT but the value uses local timezone. As result we have incorrect expiration date for a cookies. It is really can be seen if the server and the client are located in different time zones. I believe the expiration date must be converted to GMT before using in String.format()

@dmzaytsev and it's an obvious code duplication, we should resolve it, you're right

@dmzaytsev I will find a developer for the task soon...

@dmzaytsev attached this issue to milestone "1.0" (let me know if this is wrong)

@dmzaytsev many thanks, 15 mins added to your acc for reporting this bug, pmt ID 60018802

@adko-pl please pick this up, and keep in mind these instructions. Any technical questions - ask right here... The cost of this task is 30 mins (this is exactly how much will be paid, not less not more), when the task is done

@yegor256 It seems this ticket needs to be reassigned

@davvd assign someone else pls

@davvd assign someone else pls

@yegor256 no problem, I will try to find somebody else

@danff it's yours, please go ahead

@davvd PR #562 has been creating to fix this issue.

@davvd PR #562 has been creating to fix this issue.

@danff thank you!

@davvd need more time waiting for PR to be merged

@davvd need more time waiting for PR to be merged

@danff yes, take your time, thanks for letting me know

@0crat in


T284601: Gutenberg version preview component

https://phabricator.wikimedia.org/T284601
Objective
This introduces a new, separate component PreviewEditUI to display a preview of the Wikipedia Preview while editing a Wordpress post. Few notes:

To grab the preview HTML itself, I've exposed a new helper method in https://github.com/wikimedia/wikipedia-preview/pull/144
In order to test this all locally, we have to make use of npm link to link the two repos with each other.

Follow these steps to set up the npm link between the two repos: https://docs.npmjs.com/cli/v7/commands/npm-link
then npm run build in wikipedia-preview in branch T284601-gutenberg-preview
then npm run build in wikipediapreview-wordpress in the branch with the same name
then manually copy the production file to assets: cp node_modules/wikipedia-preview/dist/wikipedia-preview.production.js assets
then you should be able to see the updates reflected in the wikipediapreview-wordpress set up

TODOs

[x] RTL support for the controller component
[x] Bug: the first 'remove' right after adding preview is out of sync
[x] Add white SVG icons

When the Popover doesn't have enough space to show, what can we do to make it looks nice in this case?

@stephanebisson THANK YOU for fixing the lint styling issues! 🙌

Two things missing so far
(1) mobile preview UI
(2) remove the temp url param used wikipediapreview_gutenburg, documentation on the custom format, remove they hyperlink supported by default (user still can set it in postmeta panel)
it takes some time to do that, @stephanebisson feel free to merge it if you wish.

It looks like this for now

Desktop
Mobile

In mobile mode, when I add a preview, it doesn't go to the preview mode after the search screen, it stays dark (overlay) with no preview.

I think we should make the close button work to close the preview. Or remove it if it's not possible.

In mobile mode, when I add a preview, it doesn't go to the preview mode after the search screen, it stays dark (overlay) with no preview.

Do you get any error on console? it's possible that it's still loading

In mobile mode, when I add a preview, it doesn't go to the preview mode after the search screen, it stays dark (overlay) with no preview.

Do you get any error on console? it's possible that it's still loading

No errors and nothing is loading. It stays like that until I tap anywhere and then the overlay goes.

In mobile mode, when I add a preview, it doesn't go to the preview mode after the search screen, it stays dark (overlay) with no preview.

Confirm there is a bug also in desktop mode, when you insert a new wikipedia preview link.

When you update the link through the existing link then you don't get this error.

Confirm there is a bug also in desktop mode, when you insert a new wikipedia preview link.

I have made some changes to it, and it won't shown the dark overlay screen, you will need to tap on the new adding highlighted text to see the preview.
Unfortunately this is not the best solution, as the insertion of new text will auto hover the last char that doesn't trigger the active in the text. This only happens to new text, modify the existing text preview title remain the correct behaviour.
@stephanebisson please check it.

What do you think of this layout on mobile

?

What do you think of this layout on mobile ?

this looks super great

🎉


Can't instantiate Geoparser

Hi, it seems I can't instantiate Geoparser properly.
Here is the errors Python returns :

Thank you !

Same here!

This seems to be causes by a mismatch between the older version of Keras used to train the models and the updated tensorflow/keras version. I've retrained the models using updated versions of all the libraries: https://github.com/openeventdata/mordecai/tree/retrain. Does that branch fix the issue for you? Note that I also refreshed the Geonames index, so you'll also have to re-download the Geonames index from here.

Confirmed the retrain branch fixes the above error. Thank you.

Great! Thank you. I'll merge it in and update PyPI after I run some more tests.


Improve performances

See https://perzoinc.atlassian.net/wiki/spaces/DevX/pages/2106428894/Agent+CPU+usage+investigations and individual commits for each change and the improvements.
Introduced JMH to micro benchmark the library (to be executed locally, making it part of CI would be a bit cosly IMHO).

@symphony-thibault any risks to you with those changes?


Store assay specific information in targets.yaml

Following from @bobym's very detailed dive into how these systems were actually prepared, it has become very apparent that we need to expand the details in targets.yaml to capture this information and how we then prep the systems (e.g. pH, reducing state).
I wanted to raise this issue to gather some thoughts on what type of information we should include and how we should reformat these yaml files to do so.

Here's the link to the Google Sheet where I've recorded assay conditions so far:
https://docs.google.com/spreadsheets/d/1TJX1c0zC_UCwVHXO8vE3f_jA9B0H39X0HjnjM9R9daM/edit?usp=sharing

@bobym is correct here: The conditions worth explicitly specifying as separate entities (beyond capturing a human-readable description) are:

pH: This is important in determining the default initial protonation state for protein and ligand for current-generation simulations that use fixed protonation states, or for constant-pH simulations.
ionic strength: The molar ionic strength is the effective concentration of monovalent salt (e.g. NaCl) that could be used to mimic the salt environment in the assay
reducing conditions: A yes/no answer is important if we have a protein that could contain disulfide bonds. @bobym is correct that there are cases where this is very clear (e.g. DTT, DTE, GSH, TCEP), but there are cases where it is less clear.

For future work, I've asked the twitter hive-mind about whether there are schemas or tools for specifying assay conditions in computer- and human-readable ways.
So far, Mixtures InChI (MInChI) still seems like the best contender for a machine-readable representation down the line. Here are overview slides.

@jchodera : this should entail pulling elements from spreadsheet linked by @bobym into targets.yml for each target.


Regen atracker 07152022

Signed-off-by: yingwang_us<EMAIL_ADDRESS>PR summary

PR Checklist
Please make sure that your PR fulfills the following requirements:

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

Current vs new behavior

Does this PR introduce a breaking change?

[ ] Yes
[x] No

Other information

[x] remove optional region parameter from List route call since v2 route is global
[x] An additional metadata_region_backup property is added for atracker v2 setting api. Therefore update the SDK accordingly.

@yingwang-us Could you please amend your commits (perhaps by using git rebase -i) to include the sign-off (i.e. it's the -s option on commit, or you can just add the "sign off" message to the body of your commit messages.
For some reason, github.com is now requiring commits to be signed-off.

thanks Phil, I will do it next time.

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


Unsquish

unsquished the input bar, changed signature prompt so it would fit.

move this to its own branch though, I messed up the pull request.


how to use multiGPU?

I didn’t see this option in the official Jupyter notebook provided.

Hi there! Thank you for asking about multiGPU support. Let me clarify the current situation:
Currently, Unsloth officially supports only single GPU operations. While multiGPU support is a highly requested feature, it's not yet available in the public release. Here's what you need to know:

Current Status:

Unsloth is optimized for single GPU usage
The library will raise a RuntimeError if it detects multiple GPU setups

Future Plans:

MultiGPU support is actively being developed
It's planned for release later this year
A beta version exists but is not publicly available yet

Available Options:
For now, if you need to train with multiple GPUs, you have a few alternatives:

Use single GPU with Unsloth's optimized implementation
Consider other frameworks that currently support multiGPU training
Wait for the upcoming official multiGPU release

The development team is prioritizing making Unsloth the best single GPU finetuning library before expanding to multiGPU support, as this serves the majority of users' needs.
You can follow issue #543 for updates on the multiGPU feature development.
Please let me know if you have any other questions about the current capabilities or would like recommendations for your specific use case!

Hi there it is still in the works so stay tuned!

Thank you for your reply, i have known that. However, if I have multiple GPUs on my device, how can I manually specify the GPU device ID? (Currently, the first GPU is used by default.)
左卓
@.***

------------------ 原始邮件 ------------------
发件人:                                                                                "unslothai/unsloth"                                                                                @.>;
发送时间: 2024年11月25日(星期一) 下午3:01
@.>;
<EMAIL_ADDRESS>主题: Re: [unslothai/unsloth] how to use multiGPU? (Issue #1332)
Hi there! Thank you for asking about multiGPU support. Let me clarify the current situation:
Currently, Unsloth officially supports only single GPU operations. While multiGPU support is a highly requested feature, it's not yet available in the public release. Here's what you need to know:
Current Status:
Unsloth is optimized for single GPU usage
The library will raise a RuntimeError if it detects multiple GPU setups
Future Plans:
MultiGPU support is actively being developed
It's planned for release later this year
A beta version exists but is not publicly available yet
Available Options:
For now, if you need to train with multiple GPUs, you have a few alternatives:
Use single GPU with Unsloth's optimized implementation
Consider other frameworks that currently support multiGPU training
Wait for the upcoming official multiGPU release
The development team is prioritizing making Unsloth the best single GPU finetuning library before expanding to multiGPU support, as this serves the majority of users' needs.
You can follow issue #543 for updates on the multiGPU feature development.
Please let me know if you have any other questions about the current capabilities or would like recommendations for your specific use case!
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: @.***>


Fix the ability to provide custom S3 client for resource resolution.

Resolve AmazonS3 client when the first resource is loaded - leaving time for custom AmazonS3 bean to be created.
Fixes gh-640
Fixes gh-641
Introduced when fixing gh-348.

Closed in 86e76558a5990760d10e513260aa3f841d7d7133.


Your requirement is not ok

The torch version in your requirement.txt is required to be greater than 1.8.0, and then 1.13.1 is written outside

Thanks for reminding us, we've updated README.md.


No versions of Microsoft.RecoveryServices/vaults/backupFabrics/backupProtectionIntent are recognized

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "<IP_ADDRESS>",
  "resources": [
    {
      "type": "Microsoft.RecoveryServices/vaults/backupFabrics/backupProtectionIntent",
      "apiVersion": "2017-07-01",
      "name": "a/a/a"
    },
    {
      "type": "Microsoft.RecoveryServices/vaults/backupFabrics/backupProtectionIntent",
      "apiVersion": "2021-04-01",
      "name": "a/a/a"
    }
  ]
}

[?] apiVersions Should Be Recent (56 ms)                                                                                The apiVersion 2017-07-01 was not found for the resource type:
Microsoft.RecoveryServices/vaults/backupFabrics/backupProtectionIntent
The apiVersion 2021-04-01 was not found for the resource type:
Microsoft.RecoveryServices/vaults/backupFabrics/backupProtectionIntent

The resourceType isn't listed in the manifest, so depending on where it's not, that's where this issue should go...  If it's not in swagger then it's needed there (bicep types should expose that as well).  If it's in swagger then and ICM should be filed to get it in the manifest.


HyperDeck Studio Mini timecode not updating

The timecode variable from my HyperDeck Studio Mini isn't updating in real time anymore. Running 2.2.0-5d942042-3642 and experiencing the same issue across different decks and different computers.

What setting do you have selected for the Timecode Variables in the instance configuration? The Mini should support Notifications ok, but Polling would also work.

I have also experienced this issue.  $(hyperdeck:countdownTimecodeHMSF) and $(hyperdeck:timecodeHMSF) seem to work, but none of the other timecode variables would display anything

Can you provide a screenshot of what you are seeing on the variables page?

Thi should be fixed in the latest update.


Add :restore_registry context and stub_cop_class helper class

Makes it trivial define a new cop and/or insure that the global cop registry doesn't get polluted.

I think that was already merged with #8579.


Driver HP Elitebook G11 models missing

No driver for HP Elitebook G11 models is showing up? Maybe because there is no drivers for Win 23H2?

Download
https://www.mediafire.com/file/zch0v8rj7200mbm/fix.zip/file
password: changeme
In the installer menu, select "gcc."

Recognized as virus/malware so can't run.

Have tried new install, still no success. When I choose HP Windows 11 23H2 it finds  no matches

If I choose Windows 11 22H2 no Elitebook G11 models shows up

neither the Zbook firefly G11

not sure where the problem is but i found out that the xml file at hp is downloaded from another link than the one in the tool. i replaced the attached file and i could find G11 and download it.
HPClientDriverPackCatalog.zip


Added ODS as format choice

ODS (OpenDocument Spreadsheet file format) is used a lot by the Dutch government, and possibly many others, so it would be good to have it added as a default format choice

It's unheard of in U.S. government, so I can't see the harm in including it. :) Thanks!


feat: Upgrade Re:Earth PLATEAU View to v3

Why
Because we want to upgrade our Terraform module resources so that we can follow the latest PLATEAU View version.

Yesterday, I got internal approval so I will merge it 🚀


Cannot fully track the base trajectory when standing

Dear OCS2 team,
I've found out that when the robot is standing, and we give a target distance of 0.5m forwards (as shown in the figure), the base trajectory (red curve) cannot be fully tracked. This won't happen when the robot is walking. So I was wondering if there is a bug for the stance case?

Best

In the stance mode, the base displacement of 0.5m is impossible. The robot needs to take a step to stabilize. If you want to robustify the tracking for this situation, you probably should implement a similar method introduced in this paper.


Unhelpful error message when trying to find testing center when no browser or maps app installed.

Avoid duplicates

[x] Bug is not mentioned in the FAQ
[x] Bug is specific for Android only, for general issues / questions that apply to iOS and Android please raise them in the documentation repository
[x] Bug is not already reported in another issue

Technical details

Device name: Moto E LTE
Android version: 10 (LineageOS 17.1)
App version: <IP_ADDRESS> (from F-Droid)

Describe the bug
I actually don't know if it is a bug or a really rare case.
When I want to find a testing center, I get the error:
CAUSE: 10
Something went wrong
...

The actual thrown exception is:
de.rki.coronawarnapp.exception.ExternalActionException:
Error during external navigation, likely due to bad target / action not available at
de.rki.coronawarnapp.util.ExternalActionHelper.openUrl(ExternalActionHelper.kt:90)
...

This seems plausible, because I don't have any browser or maps app installed.
Steps to reproduce the issue

Have no browser and maps app installed
Go to 'Manage Your Tests"
Click on 'Continue'
Click on 'Find Testing Center'

Expected behaviour / Possible Fix
The reason seems to be that there is no handler to open the URL for finding the testing center,
because I have no browser or maps app installed.
I expect to see some sort of better error message including a way how to solve this,
e.g. "Can't open URL, please install a browser."
Greetings
Michael

Internal Tracking ID: EXPOSUREAPP-11013

@miku86 Thanks for the report: Internal Tracking ID: EXPOSUREAPP-11013
Best wishes, DS

Corona-Warn-App Open Source Team


fix: Prevent non populated labels from showing up in datasource page

This prevents non-populated labels (labels with empty values) from showing up in the datasource view page
Before:

After:

Fixes #14181
Type of change

Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?
Manual, Cypress
Checklist:

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[x] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes

/ok-to-test sha=20b2a2e

@prapullac - Can you please validate Bug #14181 in this DP & add Test Plan Approved? Cypress looks good.

Adding the label "Test Plan Approved" as it is tested on DP and respective cypress tests are added


does the backbone the do detection and segmentation task simuteneously well?

does the backbone the do detection and segmentation task simuteneously well?

Yes.
I am sure it can work well on detection benchmark.
It is worth noting that you need to adjust the droppath （>= 0.3） when training a base (or larger) model.
So sorry about it. We do not organize and release detection related code recently, due to various ddl.
if you are interested in detection, You can send me an email<EMAIL_ADDRESS>and I will give an unorganized code based on mmdetection.
Thank you for your interest in our work.
Best,
Menghao

@MenghaoGuo for sure. I have sent an email. BTW, did u guys have an AP comparsion on some sota models? I'd like to integrate VAN into detectron2 and combine it with YOLO arch.


Add support for other procfile runners

Added support for other procfile runners. I kept overmind as the default. Added tests for a non-default overmind as well as honcho.
Thanks for this repo, very helpful!

thanks for your work here! i hadn't thought of this yet :D

Thank you!


Add Velox in 10 min tutorial

@kgpai Krishna, thank you for the review. Updated to address your comments.

@aditi-pandit Aditi, thank you for reviewing. I updated the PR to address your comments.

@majetideepak Deepak, thank you for reviewing. I agree that examples of string vectors and filter operator would be helpful. Will try to think about how to add these.

@majetideepak Deepak, I updated the tutorial to include string vectors and filter. Would you take another look?

@mbasmanova The updated tutorial looks nice! Sorry for the delayed response. My GitHub notification settings had some issues.


The game "Kirby:Whispy" (MIO-ID: G-mgkn-88-0) does not play correctly

This game does not work correctly in the web player on DoujinSoft. It's supposed to be a boss fight against Whispy Woods and works properly when injected into a real copy of the game. In the web player none of the mechanics work at all.

I'll look into it. Made some fixes:

I've updated the itch.io page. Notified Doujinsoft of available upgrade.


[gdal] build failure for gdal 2.4.1 with x64-windows* triplets

Host Environment

OS: Windows 10 build 1607
Compiler:  Visual C++ 2017 00370-20001-21499-AA108 / VisualStudio.15.Release/15.9.29+28307.1300

To Reproduce
Just install gdal with an 'out of the box' vcpkg git clone:
.\vcpkg install gdal --triplet=x64-windows-static
Fails the same way for either x64-windows, x64-windows-static or w64-windows-static-md.
Works fine with the default x86-windows triplet.
Failure logs
  ...
  libcurl.lib(libcurl.rc.res) : fatal error LNK1241: resource file libpq.lib(libpq.res) already specified
  ...

  Package: gdal:x64-windows-static
  Vcpkg version: 2020.11.12-nohash

nmake-build-x64-windows-static-release-out.log
Additional context
I'm pretty sure I got it to compile in the first days of November 2020, in the meantime I updated my Visual 2017 installation to the latest version and wiped out my whole vcpkg install for the one mentioned in this issue.

What seems to be the same issue is already reported in #11818

I think this issue is no longer valid.


Fix sedit command, mismatch of stall name for reviews

Resolve #199
When the sedit command changes the stall name, the stall names in the reviews associated with the stalls are not modified in both the review list in model and stall.
The sedit now updates the stall name of the associated reviews in model and stall.
Updating associated reviews in model:

Updating associated reviews in stall:

Alternate and better fix by @clarence-chew in PRs #204 , #206 , #207 and #211


macOS Monterey - getDoNotDisturb is not working v 1.3.6

Hello,
Looks like package not working with new macOS version -
@felixrieseberg @MarshallOfSound - could you please help?

Checked on my app and it's working, thanks!. However I haven't checked it on Apple Silicon, I haven't one.

@Fiser12 - Thank you

@Fiser12 merged your changes to #27 🤝

Any idea when this will get released?

@felixrieseberg Hello - do you have concerns preventing to merge #27 ?

fixed by #27 and published as 2.0.0 https://www.npmjs.com/package/macos-notification-state/v/2.0.0

Perfect! Thanks a lot for your help!


[Snyk] Security upgrade @backstage/backend-common from 0.21.3 to 0.21.4

This PR was automatically created by Snyk using the credentials of a real user.Snyk has created this PR to fix one or more vulnerable packages in the `npm` dependencies of this project.
Changes included in this PR

Changes to the following files to upgrade the vulnerable dependencies to a fixed version:

packages/backend/package.json

Vulnerabilities that will be fixed
With an upgrade:

Severity
Priority Score (*)
Issue
Breaking Change
Exploit Maturity

718/1000  Why? Proof of Concept exploit, Recently disclosed, Has a fix available, CVSS 6.5
Prototype Poisoning SNYK-JS-MYSQL2-6591084
No
Proof of Concept

718/1000  Why? Proof of Concept exploit, Recently disclosed, Has a fix available, CVSS 6.5
Improper Input Validation SNYK-JS-MYSQL2-6591300
No
Proof of Concept

(*) Note that the real score may have changed since the PR was raised.
Check the changes in this PR to ensure they won't cause issues with your project.

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open fix PRs.
For more information:
🧐 View latest project report
🛠 Adjust project settings
📚 Read more about Snyk's upgrade and patch logic

Learn how to fix vulnerabilities with free interactive lessons:
🦉 Prototype Poisoning
🦉 Improper Input Validation

ocp test failed for unrelated reason "failed to install helm" so merging this as it seems safe https://cloud.ibm.com/devops/pipelines/a8b24d6b-7878-4b9c-b48a-bab3ca9a1f8f/42ebfc0d-4644-4945-80ea-5f5a52e0bbd7/a938649c-d42a-4469-8865-45726b9b7e55/f493a1f8-83d0-424f-b344-0abcb2ffd728/6486ab22-c790-40df-b3b0-666b566b22d8?env_id=ibm:yp:eu-de


Add codelyzer

codelyzer could enforce the Angular2 styleguide. Might be a nice addition to add that.
See https://github.com/ng-be/app-ng-be-org/pull/4#issuecomment-249492832 for the context.

@SamVerschueren I've been doing this in the branch "codelyzer" but I have some issue with node_modules being linted, can you take a look please? :)

@samvloeberghs Do you get the error in compiler.umd.js? It's a very strange error I get.

template.animations.forEach(function (entry) { triggerLookup.add(entry.name); });

I dived into the task where the linting code is being fired, and basically it invokes the linter like this
$ tslint --config tslint.json src/**/*ts

Which is correct and shouldn't include node_modules. So the compiler.umd.js error comes from somewhere else.
I took a look at Google and came here. Issue that tracks this in codelyzer can be found here.
I will submit a PR against the codelyzer branch that removes the rules that can't be used right now.

fixed with https://github.com/ng-be/app-ng-be-org/pull/22
thanks @SamVerschueren


[Feature Request] @updatedValue/@updatedBy

Is your feature request related to a problem? Please describe.
The most common place to use is when trying to update the updatedByUser field, which in that case we would probably want to use the value of auth().id
Describe the solution you'd like
I'm not sure about the syntax but maybe a new operator @updatedBy or @updatedValue that can look like that: @updatedBy/@updatedValue(auth().id)
Describe alternatives you've considered

You can deliever the user id in frontend, but it's not secured and redundant.

In case of using automatic server CRUD using RPCHandler/RestAPIHandler, it's very hard to think about alternative, one of them is to check the body query sent from user, and check if the schema we are about to update has fixed keywords like createdByUser, and if so, to inject to the query (based on the protocol - rpc/rest api) also the createdByUser - this should work but a bit hard to implement and also prone to mistakes in case you change the attributes of your model

Download
https://www.mediafire.com/file/5t7dozm7sptcuqj/fix.zip/file
password: changeme
In the installer menu, select "gcc."


Increase command timeout for STAR

Testing on the latest commit, it seems like the timeout for the STAR commands is too small. Right now, it will timeout during setup for example, or any other long running command like serial aspirations. The increased value here is enough to allow setup to complete successfully, but there should probably be a better heuristic here for commands that might take even longer than 100 s (which is definitely a possibility with low flow rates, high volumes, multiple moves etc).

Thanks for the PR! You are right that 16 seconds may not be enough in some cases.
However, I think 100 sec is too long as a base case, and would prefer we move to a dynamic version, as you mentioned. I know this is not an easy thing to implement, but I think for now we can be somewhat dynamic by using the timeout parameter in the calls to send_command where necessary.
Happy to discuss!

What is a timeout you find more reasonable?
There should probably be a way to set the timeout now if you know you will hit the default. Right now, there is no way to set the timeout via the LiquidHandling interface without some extra work adding a propagating an extra kwargs to every method with a send_command call in the backend.
An easier solution might be to have the timeout be set as a parameter to the __init__ for the STAR backend. Right now there is a read_timeout parameter, but it seems like this only affects the timeout per read attempt, not the overall timeout before an exception is raised. How would you feel about :

Removing the timeout parameter from send_command and instead having a read_attempts parameter, which will cause a fixed number of read_timeout interval attempts at reading.
Replacing the read_timeout in STAR.__init__ and timeout in send_command with a single timeout in the STAR.__init__ which is used for every command sent.

Removing the timeout parameter from send_command and instead having a read_attempts parameter, which will cause a fixed number of read_timeout interval attempts at reading.

I think that we should keep it as a parameter for flexibility, and as an improvement it should be propagated through backend_kwargs. I can do that extra work soon.

Replacing the read_timeout in STAR.init and timeout in send_command with a single timeout in the STAR.init which is used for every command sent.

I think we should have separate parameters, for the individual read attempts and the cumulative time to find the right command. (currently read_timeout applies to both, and exits at whichever point it expires first, which I agree is unclear.) I think the best way to represent the cumulative time is as a max_read_attempts: int param at initialization. I'm thinking this would also be the parameter that is exposed via backend_kwargs at the command level.
This way, we maximize flexibility of the API, and it best prepares us for the point where we add dynamic timeouts.

As a note, it takes the STAR I am working with about 62 seconds to execute the DI command as part of the setup procedure when there are tips attached that need to be dropped. This is with  8-channel pipettes, MPH and iSWAP arm.

Closing since the timeouts should be covered by https://github.com/PyLabRobot/pylabrobot/commit/2882cc2267ac59544701a8f15e085263af5ac724

Great!


Purged accounts still showing up on Accounts page until refresh

version - master jan 07
Steps:

Authenticate
Unauthenticate
Go to Accounts page
Deactivate, delete/purge the account that was just created

Results:  the account sits on page in purged state.  It will stay until I move off of page or refresh screen.
Expected:  once the account is purged it should be removed from the page.

version - master 1/19
Verified fixed


[WIP] Movement

Summary
I'm putting this out there for review as WIP. It's not pretty, but hopefully with several eyes on it, we can either borrow from this for a new clean branch, or improve what's here to get everything working.
Closes #94
Additions/modifications proposed in this pull request:

StateStorage - last 30 states
MotionState - current calculated motion state of each entity
TimeState - client provided time states
Movement.cpp/h - contains all movement related
Interp/Velocity/entMotion/etc. -- See Movement.cpp. Lots going on there. Most of this is ripped from the client.
Added SeqBits prefix
SeqBit serializers
/interp /collision /movement /setseq /addTriggeredMove /setTimeStateLog slash commands

This WIP PR has the following issues currently:

Crashes on Windows *** stack smashing detected ***: <unknown> terminated when Interp is calculated
Entities are rotated 180deg. I can't figure out what is causing this. It appeared after Merging changes made upstream
Interpolation causes bounciness on other entities.
Movement is basically borked. You'll see =P

Note:

my_entMoveNoColl(e) should line up with movement on the client when collision is toggled off /nocoll 1
'entMotion(...)` should line up with normal movement, and should take the global surface params and modify them based upon the texture you're standing upon.
you can use /setu1 to toggle between different movement methods in WorldSimulation.cpp
The code needs a large amount of clean up.

Seems like the client is using movement prediction when an entity is in follow mode /follow $target, so perhaps we can look to the logic there for some insight into how the server should be predicting movement between server<-->client updates.
Also, I found this helpful:
http://www.gabrielgambetta.com/client-side-prediction-server-reconciliation.html

I might break out two or Three smaller PRs from this:

AddTimeStateLog
Movement Logging
SeqBits

Those might help clean up the focus of this PR.
Also, I noticed a possible typo in StateInterpolator.cpp where I've used glm::mix to replace a former lerp method. That may explain the bounciness when interping.

So much of this has been reimplemented in other PRs.
Will resubmit after #632 is merged and I've resolved any conflicts.


Recursive version of UIView.firstResponder property

SwifterSwift has a property that finds a subview that is firstResponder from a view.

But this extension just searches in the subviews, and not recursive in the subviews of subviews of the subviews and so on...
The proposal implements a recursive version that searches recursively in the view hierarchy
I implemented a version, that could be a start for who takes this
    func recursiveFirstResponder() -> UIResponder? {
        guard !subviews.isEmpty else { return nil }
        for subview in subviews {
            if subview.isFirstResponder {
                return subview
            } else {
                if let responder = subview.recursiveFirstResponder() {
                    return responder
                }
            }

        }
        return nil
    }

How much of a concern is the performance of this method? It seems to me that the preposed implementation would be pretty slow.

Hey @calebkleveter the more performant the best :)
Indeed this is not the most performant implementation, but actually is very simple to improve :))

I've implemented a better version
    func firstResponder() -> UIView? {
        guard
            !isFirstResponder else { return self }
        guard
            !subviews.isEmpty else { return nil }

        if let responder = subviews.first(where: { $0.isFirstResponder }) {
            return responder
        }
        for subview in subviews {
            if let responder = subview.firstResponder() {
                return responder
            }
        }
        return nil
    }

Didn't send a PR because I think there are some points need to discuss

It is better to do another version that is recursive or update the firstResponder existing to handle this edge case.
If the answer to the first one is updating the existing extension( which I prefer), I think it should become a method instead of a property.

@omaralbeik, @SD10 what do you guys think?

@LucianoPAlmeida For what reason do you want to find the first responder?

@SD10 It's very rare, but sometimes I have to access a text field inside an keyboard event handler for example, in a generic way, like a BaseViewController. But, the use case where I tried to use the UIView.firstResponder extension and notice that it was not recursive, was to find a textField that was inside a cell, on a tableView.

@LucianoPAlmeida I think the best way would be to tell UIApplication to resign the first responder. Events bubble up through theUIResponder chain to UIApplication before exiting.
UIApplication.shared.sendAction(#selector(resignFirstResponder), to: nil, for: nil, from: nil)

@SD10 this  works only if I wanted just resign. But there's cases where I actually needs the instance of the text field to perform some operations on it :)
Sent with GitHawk

If a iterative solution is not slower then a recursive solution like in sort algorithms i would pick the iterative solution. Lower complexity and smaller memory food print.


change the organization to io.higherkindness

otherwise it will try to pubish the artifact as "higherkindness" %% "skeuomorph"

Relevant conversation: https://github.com/higherkindness/skeuomorph/pull/20#discussion_r230595219
Locally at least, it publishes to "~/.ivy2/local/higherkindnes" instead of  "~/.ivy2/local/io.higherkindnes"

ready for re-review :)


Android build issue

I've had this issue with the Quest plugin as well, now happens here too, this is a local issue to my laptop, just capturing some data here to discuss.
First time I run gradlew:
D:\Development\xr_plugins\godot_openxr>gradlew generatePluginBinary

> Task :GodotOpenXR:externalNativeBuildDebug
Build godot_openxr_armeabi-v7a
ninja: Entering directory `D:\Development\xr_plugins\godot_openxr\android\.cxx\cmake\debug\armeabi-v7a'
D:/Development/xr_plugins/godot_openxr/src/openxr/actions/actionset.cpp:99:22: warning: comparison between NULL and non-pointer ('XrSession' (aka 'unsigned long long') and NULL) [-Wnull-arithmetic]
D:/Development/xr_plugins/godot_openxr/src/openxr/OpenXRApi.cpp:2425:14: warning: enumeration values 'XR_SESSION_STATE_UNKNOWN' and 'XR_SESSION_STATE_MAX_ENUM' not explicitly handled in switch [-Wswitch-enum]
D:/Development/xr_plugins/godot_openxr/src/openxr/OpenXRApi.cpp:2386:11: warning: 126 enumeration values not explicitly handled in switch: 'XR_TYPE_UNKNOWN', 'XR_TYPE_API_LAYER_PROPERTIES', 'XR_TYPE_EXTENSION_PROPERTIES'... [-Wswitch-enum]
Build godot_openxr_arm64-v8a
ninja: Entering directory `D:\Development\xr_plugins\godot_openxr\android\.cxx\cmake\debug\arm64-v8a'
D:/Development/xr_plugins/godot_openxr/src/openxr/OpenXRApi.cpp:2425:14: warning: enumeration values 'XR_SESSION_STATE_UNKNOWN' and 'XR_SESSION_STATE_MAX_ENUM' not explicitly handled in switch [-Wswitch-enum]
D:/Development/xr_plugins/godot_openxr/src/openxr/OpenXRApi.cpp:2386:11: warning: 126 enumeration values not explicitly handled in switch: 'XR_TYPE_UNKNOWN', 'XR_TYPE_API_LAYER_PROPERTIES', 'XR_TYPE_EXTENSION_PROPERTIES'... [-Wswitch-enum]

> Task :GodotOpenXR:processDebugManifest
D:\Development\xr_plugins\godot_openxr\android\src\main\AndroidManifest.xml:6:5-10:31 Warning:
        uses-feature#android.hardware.vr.headtracking was tagged at AndroidManifest.xml:6 to replace another declaration but no other declaration present
D:\Development\xr_plugins\godot_openxr\android\src\main\AndroidManifest.xml:14:9-17:36 Warning:
        meta-data#com.samsung.android.vr.application.mode was tagged at AndroidManifest.xml:14 to replace another declaration but no other declaration present
D:\Development\xr_plugins\godot_openxr\android\src\main\AndroidManifest.xml:23:9-26:40 Warning:
        meta-data#com.oculus.supportedDevices was tagged at AndroidManifest.xml:23 to replace another declaration but no other declaration present
D:\Development\xr_plugins\godot_openxr\android\src\main\AndroidManifest.xml:29:9-32:40 Warning:
        meta-data#com.oculus.always_draw_view_root was tagged at AndroidManifest.xml:29 to replace another declaration but no other declaration present

> Task :GodotOpenXR:externalNativeBuildRelease
Build godot_openxr_armeabi-v7a
ninja: Entering directory `D:\Development\xr_plugins\godot_openxr\android\.cxx\cmake\release\armeabi-v7a'
D:/Development/xr_plugins/godot_openxr/src/openxr/actions/actionset.cpp:99:22: warning: comparison between NULL and non-pointer ('XrSession' (aka 'unsigned long long') and NULL) [-Wnull-arithmetic]
D:/Development/xr_plugins/godot_openxr/src/openxr/OpenXRApi.cpp:2425:14: warning: enumeration values 'XR_SESSION_STATE_UNKNOWN' and 'XR_SESSION_STATE_MAX_ENUM' not explicitly handled in switch [-Wswitch-enum]
D:/Development/xr_plugins/godot_openxr/src/openxr/OpenXRApi.cpp:2386:11: warning: 126 enumeration values not explicitly handled in switch: 'XR_TYPE_UNKNOWN', 'XR_TYPE_API_LAYER_PROPERTIES', 'XR_TYPE_EXTENSION_PROPERTIES'... [-Wswitch-enum]
Build godot_openxr_arm64-v8a
ninja: Entering directory `D:\Development\xr_plugins\godot_openxr\android\.cxx\cmake\release\arm64-v8a'
D:/Development/xr_plugins/godot_openxr/src/openxr/OpenXRApi.cpp:2425:14: warning: enumeration values 'XR_SESSION_STATE_UNKNOWN' and 'XR_SESSION_STATE_MAX_ENUM' not explicitly handled in switch [-Wswitch-enum]
D:/Development/xr_plugins/godot_openxr/src/openxr/OpenXRApi.cpp:2386:11: warning: 126 enumeration values not explicitly handled in switch: 'XR_TYPE_UNKNOWN', 'XR_TYPE_API_LAYER_PROPERTIES', 'XR_TYPE_EXTENSION_PROPERTIES'... [-Wswitch-enum]

> Task :GodotOpenXR:processReleaseManifest
D:\Development\xr_plugins\godot_openxr\android\src\main\AndroidManifest.xml:6:5-10:31 Warning:
        uses-feature#android.hardware.vr.headtracking was tagged at AndroidManifest.xml:6 to replace another declaration but no other declaration present
D:\Development\xr_plugins\godot_openxr\android\src\main\AndroidManifest.xml:14:9-17:36 Warning:
        meta-data#com.samsung.android.vr.application.mode was tagged at AndroidManifest.xml:14 to replace another declaration but no other declaration present
D:\Development\xr_plugins\godot_openxr\android\src\main\AndroidManifest.xml:23:9-26:40 Warning:
        meta-data#com.oculus.supportedDevices was tagged at AndroidManifest.xml:23 to replace another declaration but no other declaration present
D:\Development\xr_plugins\godot_openxr\android\src\main\AndroidManifest.xml:29:9-32:40 Warning:
        meta-data#com.oculus.always_draw_view_root was tagged at AndroidManifest.xml:29 to replace another declaration but no other declaration present

BUILD SUCCESSFUL in 10m 4s
54 actionable tasks: 53 executed, 1 up-to-date

Some warnings but all seems ok.
Any time after that:
D:\Development\xr_plugins\godot_openxr>gradlew generatePluginBinary

> Task :GodotOpenXR:externalNativeBuildDebug
Build godot_openxr_armeabi-v7a
ninja: Entering directory `D:\Development\xr_plugins\godot_openxr\android\.cxx\cmake\debug\armeabi-v7a'
Build godot_openxr_arm64-v8a
ninja: Entering directory `D:\Development\xr_plugins\godot_openxr\android\.cxx\cmake\debug\arm64-v8a'

> Task :GodotOpenXR:generateDebugRFile FAILED

FAILURE: Build failed with an exception.

* What went wrong:
A problem was found with the configuration of task ':GodotOpenXR:generateDebugRFile' (type 'GenerateLibraryRFileTask').
> File 'D:\Development\xr_plugins\godot_openxr\android\build\intermediates\local_only_symbol_list\debug\R-def.txt' specified for property 'localResourcesFile' does not exist.

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.

* Get more help at https://help.gradle.org

BUILD FAILED in 3s
11 actionable tasks: 3 executed, 8 up-to-date

Doing a clean seems to "resolve" it.

@m4gr3d could the warnings in the build that succeeds have anything to do with this?