Event delegation for addToCart buttons + SCSS variables overriding mechanism

Hi there, Your library is excellent, thank you!
I modified a few things to improve theme compatibility:

Event delegation for click detection on addToCart targets (making your library adaptable to dynamically generated product listings, e.g. with https://apps.shopify.com/product-filter-search?locale=en)
SCSS variables can be overridden before importing your SCSS file (similar to Bootstrap's SCSS)
Get addToCart button's closest form instead of assuming the parentNode is the form

Sorry for the compiled assets included in the PR :-(

Strings are now translatable

@nsorosac Thanks from the whole team!


Update grpcio to 1.53

Did some research on grpcio, tried versions as recent as 1.56.2.
Without the condition added by Marcin, grpcio seems to retry connection to unavailable unix socket and occupy grpc thread.
Here's a fragment of GRPC trace:
I0809 10:20:47.309468319 1277687 subchannel.cc:707]                    subchannel 0x55d9d6b7acb0 {address=unix:/proc/1/root/run/crio/crio.sock,
grpc.primary_user_agent=grpc-python/1.56.2, grpc.resource_quota=0x55d9d6a85910, grpc.server_uri=unix:///proc/1/root/run/crio/crio.sock}}:
connect failed (UNKNOWN:No such file or directory {created_time:"2023-08-09T10:20:47.309356824+00:00",
errno:2, os_error:"No such file or directory", syscall:"connect", target_address:"unix:/proc/1/root/run/crio/crio.sock"}),
backing off for 1000 ms

The issue will only surface if we actually attempt to send a grpc Version request in method _is_cri_available().
Playing with grpc options found the following to help with some cases, but not eliminate the problem of hanging-processes completely:
self._channel = grpc.insecure_channel(path, options=[
    ('grpc.initial_reconnect_backoff_ms', 100,),
    ('grpc.min_reconnect_backoff_ms', 100,),
    ('grpc.max_reconnect_backoff_ms', 100,),
])

Closing in favor of https://github.com/Granulate/granulate-utils/pull/139


feat(adc): spike for ADC reads using DMA w/ circular buffer

This implements continuous ADC reads of multiple channels using DMA and a circular buffer. Values should be able to be read directly from the buffer from any context, not just interrupts.
This is unsafe, but it's working and so gives a jumping off point for improvements. I'm not actually sure if the use-case is even possible in safe Rust.
Seeking ideas to improve:

Needing to pass in an array of u8s instead of an array of pins.
Having to read_volatile because the transfer has &mut ownership over the buffer.  There would also need to be an API to access this buffer from outside an interrupt context, where we might not have access to the transfer.
DmaConfig needs to be setup correctly (e.g. circular_buffer(true)), otherwise it won't work.
Anything else! I'm relatively new to embedded, and I'm sure there are tons of spots where this approach and code can be improved.

Closing as no interest.

This would have been extremely useful to me.
I see that it's currently supported in the stm32f4xx-hal crate but not here


Should we use a more generic transport for _detect_gce_environment()

The current source uses the core httplib / http.client machinery to get the info.

The original reason we used the low-level library is because the timeout in httplib2 was taking too long. This may no longer be an issue, i.e. if the GCE check is the last one
It should probably use oauth2client.contrib._metadata utils

I'm filing this because after #586 all requests (except for this one) are "guaranteed" to pass through the transport.request method

Yes. Let's.


[PROJECT PROPOSAL]

Project Request
T20 - Cricket score predictor.

Field
Description

About
The model will be able to predict the cricket score on the basis of the available dataset, and various input fields like the batting and bowling teams, the wickets taken, the city, the overs left,etc.

Github
Shreyg-27

Email
<EMAIL_ADDRESS>

Label
GSSoC'23

https://github.com/Shreyg-27
Define You

[X] GSSOC Participant
[X] Contributor

Project Name
Cricket Score Predictor
Description
The aim of this project is to work on the prediction of T20 Cricket scores.
Scope
So, the input would select the batting team, bowling team, the current city, the score, overs left, wickets were taken, and runs scored in the recent overs.  Accordingly, output would be created. An application would be created using Streamlit, that would help in predicting the score.
Timeline
Till 1 August.
Video Links or Support Links

Hi @adithya-s-k! I have raised this issue! Can you please assign this to me under the GSSoC'23 ?

Hi, @Shreyg-27 , kindly fix the heading [Project Proporsal], write your topic there, I would then assign the same to you

Hi, @Shreyg-27 , kindly fix the heading [Project Proporsal], write your topic there, I would then assign the same to you

@miraj0507 I have made the change.


Several issues with os.fork() in Spyder

Issue Report Checklist

[ ] Searched the issues page for similar reports
[ ] Read the relevant sections of the Spyder Troubleshooting Guide and followed its advice
[ ] Reproduced the issue after updating with conda update spyder (or pip, if not using Anaconda)
[ ] Could not reproduce inside jupyter qtconsole (if console-related)
[ ] Tried basic troubleshooting (if a bug/error)

[ ] Restarted Spyder
[ ] Reset preferences with spyder --reset
[ ] Reinstalled the latest version of Anaconda
[ ] Tried the other applicable steps from the Troubleshooting Guide

[ ] Completed the Problem Description, Steps to Reproduce and Version sections below

Problem Description
There are several problems using os.fork() in Spyder if one tries to spawn any additional process from the forked process. This is on macOS M1; I am sure things may vary on other platforms.
I have tested these in qtconsole and these bugs do not happen there. I thought some of this may be related to qtconsole being a tty emulator, but apparently not. It's something related to Spyder.
Things are broken in a lot of very subtle ways and I am not quite sure how to list them all. Here are a few:
import os
import subprocess
import time

pid = os.fork()
if pid == 0:
    print("calling Popen")
    p = subprocess.Popen(["python", "testchild.py"]) # hangs here
    print("after Popen call")
    time.sleep(10000)
else:
    time.sleep(10000)

It hangs on Popen; the line after never prints. Another one:
import os
import subprocess
import time

pid1 = os.fork()
if pid1 == 0:
    print("child 1")
    pid2 = os.fork() # seems to hang here
    print("child 1 post-second-fork")
    if pid2 == 0:
        print("child 2")
        os.execlp("python", "python", "testchild.py")
    else:
        time.sleep(1000)
else:
    time.sleep(10000)

Again, the second os.fork() command completely hangs.
There are quite a few similar situations above, most of which involves running another subprocess in some form from the forked process.
There are about a dozen other quirks like this, including one particularly subtle one involving a pty which threw me off for hours earlier this week. I am not sure to what extent these are "different" bugs or manifestations of the same bug. Is there some big picture to this?
 You said:

I have tested these in qtconsole and these bugs do not happen there

That's not true for me on Linux with your first example:

And I found the solution here after googling for jupyter problems os.fork:

I guess the solution should work similarly with your second example, so please try it and let us know.

Not here - still stuck. It doesn't get past the Popen call. Here it is in Spyder:

And it does work in qtconsole:

Ok, this could be an issue that only happens on Mac. But I guess you're aware you can also use the %run magic in Spyder to run your files (I mean, in the same way your screenshot shows that you're using it in Qtconsole). So, I'd suggest you do that if you want to work with os.fork.
@mrclary, are you seeing the same results with @battaglia01's first example on Mac?

TL;DR
Okay, there are two issues and they are not related to Spyder.

time.sleep takes argument in seconds, not milliseconds: waiting for 2h46m may appear to be a hang but isn't.
When a child process is spawned using os.fork, it seems that it is not closed when execution is completed; use os._exit to close child processes.

More Detail
Regarding the first, I don't think you intended to wait 2 hours and 46 minutes. This could give the appearance of hanging when it is not. Changing to a more reasonable value fixes this issue. When processes are forked, it is arbitrary which lines of which processes are executed first, so print statements may not appear as expected.
Regarding the second, if the script is run from a non-interactive interpreter, e.g. $ python mwe_1.py, then the child process is destroyed when the parent Python process exits. However, when run from an interactive interpreter, e.g. an IPython console or Spyder's console or a Qtconsole, then the parent process does not exit and the child process is not destroyed closed. I observed this by viewing the Activity Monitor, but this can also be seen with $ ps -e | grep python. I don't know whether this is a bug or a feature of os.fork, but I observed this in both in IPython consoles started from the terminal and Qtconsoles. The solution is to use os._exit(0) to exit the child process at an appropriate point.
Interestingly, correcting the time.sleep in your first example, but not using os._exit(0), I encountered the following error regarding a bad file descriptor if using the magic %run command in an IPython console, but not in a Spyder console or Qtconsole:
In [1]: %run mwe_1.py
calling Popen
after Popen call
subprocess id: 57772
subprocess parent id: 57771

In [2]: Traceback (most recent call last):
  File "/Users/rclary/opt/mambaforge/envs/spy-dev/bin/ipython", line 10, in <module>
    sys.exit(start_ipython())
  File "/Users/rclary/opt/mambaforge/envs/spy-dev/lib/python3.10/site-packages/IPython/__init__.py", line 124, in start_ipython
    return launch_new_instance(argv=argv, **kwargs)
  File "/Users/rclary/opt/mambaforge/envs/spy-dev/lib/python3.10/site-packages/traitlets/config/application.py", line 1043, in launch_instance
    app.start()
  File "/Users/rclary/opt/mambaforge/envs/spy-dev/lib/python3.10/site-packages/IPython/terminal/ipapp.py", line 318, in start
    self.shell.mainloop()
  File "/Users/rclary/opt/mambaforge/envs/spy-dev/lib/python3.10/site-packages/IPython/terminal/interactiveshell.py", line 887, in mainloop
    self.interact()
  File "/Users/rclary/opt/mambaforge/envs/spy-dev/lib/python3.10/site-packages/IPython/terminal/interactiveshell.py", line 872, in interact
    code = self.prompt_for_code()
  File "/Users/rclary/opt/mambaforge/envs/spy-dev/lib/python3.10/site-packages/IPython/terminal/interactiveshell.py", line 811, in prompt_for_code
    text = self.pt_app.prompt(
  File "/Users/rclary/opt/mambaforge/envs/spy-dev/lib/python3.10/site-packages/prompt_toolkit/shortcuts/prompt.py", line 1035, in prompt
    return self.app.run(
  File "/Users/rclary/opt/mambaforge/envs/spy-dev/lib/python3.10/site-packages/prompt_toolkit/application/application.py", line 961, in run
    return loop.run_until_complete(coro)
  File "/Users/rclary/opt/mambaforge/envs/spy-dev/lib/python3.10/asyncio/base_events.py", line 636, in run_until_complete
    self.run_forever()
  File "/Users/rclary/opt/mambaforge/envs/spy-dev/lib/python3.10/asyncio/base_events.py", line 603, in run_forever
    self._run_once()
  File "/Users/rclary/opt/mambaforge/envs/spy-dev/lib/python3.10/asyncio/base_events.py", line 1868, in _run_once
    event_list = self._selector.select(timeout)
  File "/Users/rclary/opt/mambaforge/envs/spy-dev/lib/python3.10/selectors.py", line 562, in select
    kev_list = self._selector.control(None, max_ev, timeout)
OSError: [Errno 9] Bad file descriptor

If you suspect this is an IPython 8.11.0 bug, please report it at:
    https://github.com/ipython/ipython/issues
or send an email to the mailing list at<EMAIL_ADDRESS>
You can print a more detailed traceback right now with "%tb", or use "%debug"
to interactively debug it.

Extra-detailed tracebacks for bug-reporting purposes can be enabled via:
    %config Application.verbose_crash=True

In [2]:

This same error occurs if you execute os.fork() on a single line in an interactive interpreter.
Conclusion
So, the following is what I recommend for your first example script, which works using both F5 in Spyder, copy-and-paste into the console, as well as %run mwe_1_fixed.py.
# mwe_1_fixed.py
import os
import subprocess as sp
import time

pid = os.fork()
if pid == 0:
    print("calling Popen")
    p = sp.Popen(["python", "testchild.py"]) # Does not hang here
    print("after Popen call")
    time.sleep(1)  # 1 second, not 2h46m
    os._exit(0)  # Be sure to exit child if parent is interactive interpreter
else:
    time.sleep(1)  # 1 second, not 2h46m

However, I prefer the following examples scripts that identify everything.
# mwe_1_works.py
import os
import subprocess as sp

pid = os.fork()
if pid == 0:
    try:
        print("I'm child with ID:", os.getpid())
        print("My parent's ID:", os.getppid())
        p = sp.Popen(["python", "testchild.py"], stdout=sp.PIPE, stderr=sp.PIPE)  # Does not hang
        print(p.communicate()[0].decode())  # Print the subprocess output
    finally:
        # Be sure to exit child process if running in interactive interpreter,
        # even when there is an error.
        os._exit(0)
else:
    print("I'm parent with ID:", os.getpid())
    print("My child's ID:", pid)

# testchild.py
import os

print('subprocess id:', os.getpid())
print('subprocess parent id:', os.getppid())

And similarly for your second example:
# mwe_2_works.py
import os
import time

pid1 = os.fork()
if pid1 == 0:
    print("child 1:", os.getpid())
    print("parent of ch1:", os.getppid())
    pid2 = os.fork()  # Does not hang
    print("child 1 post-second-fork")  # prints twice: pid1 and pid2
    if pid2 == 0:
        try:
            print("child 2:", os.getpid())
            os.execlp("python", "python", "testchild.py")  # replaces child 2 process
        finally:
            # The subprocess closes fine; since it replaced the child 2 process,
            # there is no need to close child 2 here, but is still good practice
            os._exit(0)
    else:
        time.sleep(1)
        os._exit(0)  # close child 1
else:
    time.sleep(2)
    print("parent:", os.getpid())

Yes, I'm aware that 10000 seconds is a long time; I did that on purpose to keep the parent process alive. No, that isn't the cause of the problem. For starters, the code snippet you provided also does not work:
# mwe_1_fixed.py
import os
import subprocess as sp
import time

pid = os.fork()
if pid == 0:
    print("calling Popen")
    p = sp.Popen(["python", "testchild.py"]) # Does not hang here
    print("after Popen call")
    time.sleep(1)  # 1 second, not 2h46m
    os._exit(0)  # Be sure to exit child if parent is interactive interpreter
else:
    time.sleep(1)  # 1 second, not 2h46m

You've written a very long post to respond to but it doesn't seem the premise of it is correct; there are other statements you make which are also not true on my system. I will again reiterate that, on M1, this only happens within Spyder and not in qtconsole, IPython, CPython or anything else.
Before we continue, have you tried to actually run this on an M1 Mac?

@battaglia01, I performed all my tests with macOS 13.2.1 with an M1 chip and macOS 12.6.3 with Intel chip; both with identical results.

Spyder version: 5.4.2 93124668
Python version: 3.9.15 64-bit
Qt version: 5.15.6
PyQt5 version: 5.15.7
Operating System: Darwin 22.3.0

My terminal environment uses Python 3.10.9 and IPython 8.11.0. So I've tested a few different versions.
The obvious next question is what is the content of your testchild.py?

there are other statements you make which are also not true on my system.

Please elaborate.

FWIW, my testchild.py is just a simple script:
testchild.py just prints something every second and writes to a logfile:
import sys, time, os
from datetime import datetime

def write_both(s, end="\n", flush=True, prefix=None):
    print(s, end=end, flush=flush)
    if prefix is None:
        prefix = str(datetime.now())
    with open("/tmp/testlog", "a+") as f:
        f.write(prefix + " " + s + end)

write_both("From child process: I have PID = %d" % os.getpid())
while True:
    try:
        write_both("Printing from child process! PID = %d" % os.getpid())
        time.sleep(1)
    except KeyboardInterrupt:
        write_both("Ctrl-C pressed in child process! PID = %d" % os.getpid())
        write_both("IT WORKED!")
        sys.exit(0)

But again, as we do not seem to agree on the basics of how fork and sleep work, I'd rather focus on the above first.

@battaglia01, I agree that the parent process sleep should not affect the child process. I was referring to the one in the child process. I was not aware of what was in your testchild.py, so it was not clear exactly how you distinguished between hanging and the egregious sleep time. So we do not have any disagreement on how sleep and fork work.
Nevertheless, I test your testchild.py and I'll test it.
Are you using the "Same as Spyder" interpreter or are you using a different external environment?

Okay, I see that there is a problem on M1. I still don't know exactly what the problem is, but I can reproduce the issue only on M1. The interesting thing is that the MWE works just fine on M1 for the Spyder environment installed by our experimental installer, but not for any other environment. This is also independent of the Spyder launch mechanism. I will investigate further. It will either be a package version problem or a conda M1 build problem; hopefully the former.

The interesting thing is that the MWE works just fine on M1 for the Spyder environment installed by our experimental installer, but not for any other environment.

Ok, this is very important and it seems @battaglia01 omitted to mention it before. Its significance is that we use a shell script to activate other external environments, which could be causing issues with os.fork (although I still can't reproduce the problem on Linux, even for external envs).

I have Spyder installed in its own conda environment; I didn't use the Mac
installer from the website. I get the problem with any interpreter,
including the one in the spyder-env environment. I also get the problem if
preferences are reset. I haven't tried the version from the Mac installer.
On Sun, Mar 5, 2023 at 2:33 PM Carlos Cordoba @.***>
wrote:

The interesting thing is that the MWE works just fine on M1 for the Spyder
environment installed by our experimental installer, but not for any other
environment.
Ok, this is very important and it seems @battaglia01
https://github.com/battaglia01 omitted to mention it before. Its
significance is that we use a shell script to activate other external
environments, which could be causing issues with os.fork (although I
still can't reproduce the problem on Linux, even for external envs).
—
Reply to this email directly, view it on GitHub
https://github.com/spyder-ide/spyder/issues/20629#issuecomment-1455182475,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAHZFMWF3ZO2URRHKPQJE2TW2TTBZANCNFSM6AAAAAAVPCO3IE
.
You are receiving this because you were mentioned.Message ID:
@.***>

@ccordoba12, I want to be sure to clarify.

I cannot reproduce this issue in any way on macOS 12.6.3 with Intel. I think it only occurs on M1 chip machines.
Any launch mechanism for Spyder (standalone, conda, experimental) will work on M1 if they use the experimental conda-based environment for the interpreter. Any other environment exhibits the OP behavior.

While I still need to investigate further, the above suggests a package version issue and/or conda M1 package build issue. But I will also investigate the shell script for launching the external environments.

What "experimental" environment are you referring to?
On Sun, Mar 5, 2023 at 3:56 PM Ryan Clary @.***> wrote:

@ccordoba12 https://github.com/ccordoba12, I want to be sure to clarify.

I cannot reproduce this issue in any way on macOS 12.6.3 with
Intel. I think it only occurs on M1 chip machines.
Any launch mechanism for Spyder (standalone, conda, experimental)
will work on M1 if they use the experimental conda-based environment for
the interpreter. Any other environment exhibits the OP behavior.

While I still need to investigate further, the above suggests a package
version issue and/or conda M1 package build issue. But I will also
investigate the shell script for launching the external environments.
—
Reply to this email directly, view it on GitHub
https://github.com/spyder-ide/spyder/issues/20629#issuecomment-1455203067,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAHZFMVFV6FZX6A4QGQSMHTW2T4WBANCNFSM6AAAAAAVPCO3IE
.
You are receiving this because you were mentioned.Message ID:
@.***>

What "experimental" environment are you referring to?

We have an experimental installer (https://github.com/spyder-ide/spyder/releases/download/v5.4.2/EXPERIMENTAL-Spyder-5.4.2-macOS-x86_64.pkg) which installs an independent conda environment from which to run Spyder and creates a Spyder.app shortcut to launch Spyder. This is the environment to which I'm referring.

Okay, I've got some new information.
Creating any environment with x86_64 architecture will result in correct behavior on M1, while creating any environment with arm64 architecture will manifest the OP.
You can test this by creating an environment as follows:
$ CONDA_SUBDIR=osx-64 conda create -n test-x86 spyder-kernels

Using this environment for your Python interpreter in Spyder, regardless of the nature of your Spyder installation will result in correct behavior.
However, as @battaglia01 has reported, the OP only manifests in Spyder. An arm64 environment will behave correctly when running the script in IPython or Qtconsole interpreters via %run.
@ccordoba12, I have no idea why this would be the case. Any ideas?

Creating any environment with x86_64 architecture will result in correct behavior on M1, while creating any environment with arm64 architecture will manifest the OP.

Thanks for digging deep into this issue @mrclary! I have no idea it was so architecture dependent.

I have no idea why this would be the case. Any ideas?

Nop, I'm also clueless about this. Perhaps @impact27 has more insights about this.

@impact27, since spyder-kernels is noarch, I think this issue may not be a direct result of spyder-kernels itself. Furthermore, since %run for an arm64 environment is successful in IPython and Qtconsole from a Terminal, I don't think this issue is a direct result of ipython or qtconsole builds, either. So I suspect that there may be something about the way spyder-kernels interacts with qtconsole; perhaps a spyder-kernels dependency has a faulty M1 build?

Running:
import os
import subprocess as sp

pid = os.fork()
if pid == 0:
    try:
        print("child")
        p = sp.run(["echo", "subprocess"]) # Hangs on my system
    finally:
        # Be sure to exit child process if running in interactive interpreter,
        # even when there is an error.
        os._exit(0)
else:
    print("parent")

I get a crash that informs me that:
Exception Type:        EXC_BREAKPOINT (SIGTRAP)
Exception Codes:       0x0000000000000001, 0x00000001af96a0e0

Termination Reason:    Namespace SIGNAL, Code 5 Trace/BPT trap: 5
Terminating Process:   exc handler [68684]

Application Specific Information:
*** multi-threaded process forked ***
BUG IN CLIENT OF LIBPLATFORM: os_unfair_lock is corrupt
Abort Cause 258
crashed on child side of fork pre-exec

Thread 0 Crashed::  Dispatch queue: com.apple.main-thread
0   libsystem_platform.dylib      	       0x1af96a0e0 _os_unfair_lock_corruption_abort + 88
1   libsystem_platform.dylib      	       0x1af965024 _os_unfair_lock_lock_slow + 328
2   libtcl8.6.dylib               	       0x13213df24 AtForkPrepare + 44
3   libsystem_pthread.dylib       	       0x1af938744 _pthread_atfork_prepare_handlers + 96
4   libSystem.B.dylib             	       0x1bafd151c libSystem_atfork_prepare + 32
5   libsystem_c.dylib             	       0x1af81fa28 fork + 36
6   _posixsubprocess.cpython-310-darwin.so	       0x1016cae28 do_fork_exec + 68
7   _posixsubprocess.cpython-310-darwin.so	       0x1016ca944 subprocess_fork_exec + 796
8   Python                        	       0x101206498 cfunction_call + 96

I can reproduce in python:
save in a file test.py:
import turtle
import os
import subprocess as sp

pid = os.fork()
if pid == 0:
    try:
        print("child")
        p = sp.run(["pwd"]) # Hangs on my system
    finally:
        # Be sure to exit child process if running in interactive interpreter,
        # even when there is an error.
        os._exit(0)
else:
    print("parent")

run with python3 test.py
so turtle is the culprit ??????????

This is a python bug (https://github.com/python/cpython/issues/102525), so I am unsure what we should do. @ccordoba12 should we remove turtle from spydercustomize?

Same here! Good figuring this out. I ran a slightly modified version
import turtle
import os
import subprocess as sp

pid = os.fork()
if pid == 0:
    try:
        print("child")
        p = sp.Popen(["pwd"]) # Hangs on my system
        print("post pwd")
    finally:
        # Be sure to exit child process if running in interactive interpreter,
        # even when there is an error.
        os._exit(0)
else:
    print("parent")

Same thing; this crashes CPython. So yeah, looks like importing turtle somehow does this...?

@battaglia01 @impact27, I corroborate your latest observations. Additionally, I find that Spyder's IPython console reports the wrong processor:
In  [1]: import platform
In  [2]: platform.processor()
Out [2]: 'i386'

Where a Qtconsole initiated from the same environment reports 'arm'.

@impact27 @ccordoba12, I can also confirm that in the arm environment, If I comment out the turtle section in spyder_kernels.customize.spydercustomize.py, the OP is remediated. However, even if turtle is removed, I assume that this issue would reemerge if users ever import tkinter in the environment (see https://github.com/python/cpython/issues/102525#issuecomment-1460848609)

Also, there would be a regression of #6278 and #11967.
However, I find issues with running turtle even in an IPython console independent of Spyder. IMHO, turtle is just not designed to be run in an interactive console, let alone multiple times in the same interactive console, so I don't think it should be the responsibility of Spyder developers to monkey-patch turtle.

Also, there would be a regression of https://github.com/spyder-ide/spyder/issues/6278 and https://github.com/spyder-ide/spyder/issues/11967.

True.

However, I find issues with running turtle even in an IPython console independent of Spyder.

What issues? (Please open a new issue about it to not derail the discussion here).

IMHO, turtle is just not designed to be run in an interactive console

Well, we had to patch turtle to make it work in Spyder because many people complained about it. So, the solution is to keep that patch, fix the issues you found, and provide a way to disable it using an option in the Preferences section of the IPython console.


Allow titleCase to be configured for CHANGELOG items

The commit messages from many different stakeholders feed into cloud.google.com/release-notes, this can lead to variations in the usage of title case (vs., lower case commit messages), see:

It would be nice to be able to turn on title casing as a config option, for consistency.

In offline discussions, we determined this is going to be infeasibly difficult due to edge cases.


Null safety feedback: how to learn from the py3 hard lesson, and make it much easier to migrate

Hi,
After playing a a bit with null safety, I think that the current migration plan will cause the migration to null safety to be much more difficult than it could be. I'm copying what I wrote on reddit with some additions:
The move from python 2 to python 3 was horrible, and I think we can learn from it how to make a large change and how not to, and it seems to me that Dart's current null-safety plans are more like the "how not to" side.
With the current beta, once I upgrade the Dart SDK requirement, all the code in my package becomes broken. This makes upgrading a large project a daunting task, since it all has to be done at once.
I think that the migration to null-safety can be done using deprecation warnings. This means that in the next SDK version, current code will continue to work, but produce deprecation warnings. Those warnings could be solved one by one, until you get code that doesn't produce deprecation warnings. Then, the code without the deprecation warnings would be compatible with the second-next SDK version. Code that produces deprecation warnings could be incompatible with the second-next SDK version.
One thing that the Python community learned the hard way, is that the best way to migrate a large codebase from python 2 to python 3 is by using six, a package that allows you to write code that is compatible with both. I think that that's another good lesson - make to possible to write code that is compatible with both versions of the language.
So, I would suggest something like this:
In Dart 2.12, existing code will continue to work, with int meaning a nullable int?. You could add a comment (say, // @nullsafe) at the beginning of files, so int would be non-nullable. It would be possible to use int? and int! everywhere, so it will be possible to write code that will be compatible both with // @nullsafe and without. (This is the equivalent of code using six in Python).
When non-null-safe code puts a nullable value in a non-nullable type, a runtime check will be made, which will cause an exception just like what currently happens when you add an int which is null. However, the compiler will issue a deprecation warning, to let you know of the implicit runtime check. With this warning, you will be able to check if the type really should be nullable. If it shouldn't be nullable, you could make the type non-nullable (by replacing int with int!), which will in turn produce other warnings that you could handle one-by-one. In null-safe code, the compiler would require you to use a non-nullable type.
It would even make sense to show a warning for implicit type declarations in non-null-safe code, so you could either add ? or ! to the type to get rid of the warning.
So, the change to null-safety can be this non-breaking change:

Add the possibility for non-nullable types, by using int!.
Allow to explicitly specify nullable types, by using int?.
Warn on implicit conversions from nullable to non-nullable types
Warn on implicit nullable types (int).

Then, code without warnings will actually be null safe!
In addition, you would be able to declare files as non-nullable by default (for example, by adding // @nullsafe at the beginning). This is similar to Python's from __future__ import statements. Files with this declaration would behave exactly like the current Dart 2.12. You could add this comment to dart files that don't cause warnings, and they would continue to work exactly the same. There could be a tool that would automatically remove all the unneeded ! from types afterwards. Actually, I would show a warning on dart files without the comment that don't have any null warnings, suggesting to run the tool. The tool would add the comment and remove the unneeded exclamation marks.
This would mean that instead of needing to migrate your entire code base at once, you would be able to handle one warning at a time, keeping the code base functional all the time. When you took care of all the warnings, you would have null-safe code!
This would also make it much easier to migrate packages with dependencies. With the current Dart 2.12, I can't migrate my package into sound null-safety until all of its dependencies have migrated. This means that it would be much harder to migrate packages. With my suggestion, I could use the dependency package as is, with adding ! operators when converting a nullable return type to a non-nullable type. This would also make null-safety adoption much faster.
What do you think?
Noam

once I upgrade the Dart SDK requirement, all the code in my package
becomes broken. This makes upgrading a large project a daunting task, since
it all has to be done at once.

If you do not touch the lower bound on the sdk: setting in your pubspec.yaml there will not be any breakage, so, as you mention, you do have to take action to enable null safety at all.
However, when you enable null safety for your package by updating the sdk: lower bound, you can hold back each library of your package by adding a // @dart = 2.9 comment at the top of the library (several language versions will work, but 2.9 has typically been used so far). This means that said library will stay at the language version 2.9, which doesn't include null safety.
As you make progress and migrate each of the libraries, you'll remove those // @dart = 2.9 comments. This means that you will end up with a package which is fully migrated, and there are no special markers left in your code. (The alternative would be to add a special comment in each library in order to enable null safety; but that's not so convenient, because you would then have a lot of "enable null safety in this library" markers in your package at the end, and then you'd need to take yet another step in order to make it smoothly and invisibly null safe).

It would be possible to use int? and int! everywhere

This approach would of course also be possible, but it would require the migration process to include an intermediate step which would then call for a lot of clean-up work when @nullsafe is added. This is because you'd surely want to rely on non-null-by-default types after the migration has completed, in order to avoid having source code where every single type has a marker, either ! or ?.
So I think you'll find that the requirement to mark the legacy code as such with // @dart = 2.9 is more practical: Your package won't need any further adjustments in migrated code.

@eernstg Thank you very much for your thorough reply! After the replies on reddit from @munificent , I understand the situation much better. I think that indeed the migration won't be like the py2-py3 migration, but I think that two changes would be really important in helping people understand that indeed their old packages aren't broken. I'll copy what I wrote in the comment:

Instead of requiring a special comment on legacy files, require a special comment on migrated files. (This is equivalent to Python's from __future__ import statements).
Instead of requiring the --no-sound-null-safety flag if there are legacy files, issue a warning if there are legacy files.

This way, existing working code will continue to work with the new version, without any modifications. This would make everyone realize that the change is indeed not breaking stuff. (Indeed, it wouldn't. With the current plan, it would, even if the fix is not very difficult.)
I think that it's very important to stick to the path of doing updates using deprecation warnings: If a code works without warnings in version N, if means it will do the exact same thing in version N+1, but may produce deprecation warnings. This gives you a "continuous integration" path, where code always works: if you have warnings, fix them (keeping the code working all the time), and then you can be confident to update to the new version.
Now that I understand the soundness issue much better, it seems to me that there is still a path that would allow you to migrate one variable at a time, instead of one file at a time. My understanding is in the new Dart version there are actually three types of types: nullable, non-nullable, and legacy. Let's call them int?, int! and int* respectively. Legacy types are converted automatically to the migrated types. In legacy files, int means int*, and in migrated files, int means int!. What if you were allowed to use int! and int? in legacy files? Then, you could convert legacy variables one at a time. Once there are no more legacy types in a file, Dart could issue a warning that this file could be converted to a migrated file, and a script could adjust the header and remove the unneeded ! characters.
This would allow you to migrate one variable at a time. Currently, you have to migrate all the variables in a file at once, and if you want to follow all the places a type defined in one file is used, it could mean that you would have to change all the files in your package at once. I think that the path of migrating types one by one, in all the files in which they appear, would allow for much easier migrations, composed of small changes that keep the code working after each change.
To summarize, I think that it's very important that existing code will continue to work in the new version without any changes, and this means the two suggestions I wrote above. I also think that allowing legacy files to use non-legacy types could allow for a significantly easier migration, that won't require large overarching changes that would be a merge nightmare.

Note that even with keeping the principle that code that doesn't cause warnings in version N will continue to work in version N+1, in the second-next Dart version, you could reach a state where you'll need a special comment only for legacy files. In Dart 2.12, show a deprecation warning on files without a "legacy comment", saying that you should add it. Then, in the version after that, you could make the "migrated comment" optional, so a file with no comment will be treated as null-safe.

@leafpetersen, what do you think about adding information to https://dart.dev/null-safety/migration-guide about the use of language version comments like // @dart = 2.9 and dart migrate --files=lib/just.dart,lib/some.dart,lib/libraries.dart to enable migrations where only some libraries are migrated? That page seems to take it for granted that a migration covers a complete package in one step.
@noamraph wrote:

[it's confusing that] "library" means a single file

Ah, I almost forgot that this isn't the case in all languages. A library is actually one or more files: it includes the library file (which is the one that importers and exporters will refer to) plus possibly a number of part files. Those files will be compiled as a single unit, which is also the reason why they have a shared namespace (so code in a part file can depend on code in other part files and in the library file, and vice versa, even private declarations).
I think we should rely on documents like the Language Tour to give this kind of information.

need to add --no-sound-null-safety as a command-line flag

That should not be necessary: With a mixed version program main.dart (that is, a program that includes both legacy libraries and libraries with null safety), dart main.dart must run the program with unsound null checking (it's not supported to execute a mixed program with sound null checking), and it will do so both with and without the option --no-sound-null-safety. You can specify --sound-null-checking explicitly in order to force execution with sound null checking, and in that case it is an error to try to run a mixed version program.

Regarding migrating in order, from what I understand it seems to me that it should be really fine to migrate not in order, with the only drawback of sometimes having to do extra work after the dependency migrated. This extra work should only involve changing the nullability of some types until the program compiles, and not cause runtime problems.
I think saying that you should wait until all your dependencies have migrated will make null-safety adoption much slower, since large applications will almost certainly have one dependency that won't migrate. If I am correct, I think that it's better to explain the actual cost of migrating before your dependencies, so people could make better decisions and perhaps migrate sooner.
I think I will close this discussion, since I'm investing too much time in it. I want to link to my discussion with @munificent on reddit, and copy this:

I think that a bit more patience would paradoxically get you to a sound null-safety world sooner. I think that you have made a tremendous effort to allow backwards compatibility, and small trivial decisions could make the transition much harder, mostly because of the psychology of your actual users.

I hope I'm wrong. But I think you will realize that many packages remain without null safety because of this impatience, of not wanting null-safe libraries to need an extra line in one SDK version. This will make migrating harder for everyone, and force you to continue supporting null-unsafety longer.

I will write the small changes that I think would do a lot to communicate the actual nature of the change, prevent FUD, and encourage users to migrate:

Require to add a header line for null-safe libraries in 2.12. Show a deprecation warning saying to add a header line for null-unsafe libraries, since the default would become null-safe in the next version.
Have a "null soundness" setting in pubspec.yaml, that would default to false in 2.12 with a deprecation warning saying that it should be added, since the default would become true in the next version. Show a compiler warning if it's false and there are no null-unsafe libraries.
Explain the actual cost of migrating before your dependencies, and make it clear that it's a good choice if your dependencies don't migrate.

Thank you very much for your work, I really enjoy using it to develop an app using Flutter!
Noam

Thanks everyone for the discussion here!
At this point, the null safety migration has mostly passed and has been successful across the Dart ecosystem, so I'm going to close this.
If anyone referencing this hasn't yet migrated to null safety, dart.dev has a guide on Migrating to null safety. This page discusses how to migrate by hand or using the migration tool, and has tips to make eventual migration easier. The Unsound null safety page also has some discussion on how to migrate incrementally using language version configuration. Note that this requires Dart 2.19 as Dart 3 and later now only support sound null safety.
Thanks again!


rosdep fails on ROS 2 Rolling

ijnek@ijnek-MS-7924:~/tmp_workspaces/dynamixel_control_ws$ rosdep install --from-paths src --ignore-src -r -y
ERROR: the following packages/stacks could not have their rosdep keys resolved
to system dependencies:
pantilt_bot_description: Cannot locate rosdep definition for [realsense2_description]
Continuing to install resolvable dependencies...
#All required rosdeps installed successfully

Installation instructions' rosdep fails because the realsense2_description package isn't available in rolling. I've opened a ticket against IntelRealSense/realsense-ros to request for a release in rolling, which should solve this issue.

It's time to separate packages. https://github.com/youtalk/dynamixel_control/issues/36#issuecomment-1296210939

Closing, as examples have been separated out into a separate repository for Rolling onwards (https://github.com/dynamixel-community/dynamixel_hardware_examples).


feat(pipelines): added the workflow to have a complete pipeline

:vertical_traffic_light: Quality checklist

[x] Did you add the changes in the CHANGELOG.md?
[x] Did you run all the code checks? (go test)
[x] Are the tests passing?

@k4yt3x I changed the PR template path by renaming it from uppercase to lowercase, but it's not showing up for me my friend. What did I do wrong? I did the same for https://github.com/rios0rios0/pipelines/pull/21, but It didn't work either.


Breaking one form crashes the next consecutive forms opened.

Describe the bug
When we try to manually break a form (by removing some of the JSON and we see an error in the Output logs) we could see that the next consecutive forms we try to open are all broken. Either I do not see the form elements or the properties panels is frozen
Steps to reproduce

Create a form
Manually break the form by removing some of the lines from the JSON
Now we see the logs in the output panel
Try to create another new form
We could see weird behavior either the form elements are missing or the properties panel is frozen

https://github.com/camunda/camunda-modeler/assets/85225325/9f876525-d0b9-40f6-a1ee-63476e25150e
https://github.com/camunda/camunda-modeler/assets/85225325/cc636ff8-1ad7-4306-b3e4-f8fac70da81d
Expected behavior
The newly created forms should not be broken
Environment

OS: [ Windows 10]
Camunda Modeler Version: [5.12.0]
Execution Platform: [ Camunda Platform, Camunda Cloud]

Additional context
No response

cc @pinussilvestrus

I will have a look 👍

I can reproduce this in 5.12.0-rc.0 but not in the latest nightly and develop. The error shown in the first screencast is also what we were fixing via https://github.com/camunda/camunda-modeler/pull/3647.
So I believe that should be fixed now, but please double check 👍


Fixing the oneshot compilation problem.

Relying on a hotfix tag of tantivy.

I think this should also work
https://github.com/quickwit-oss/quickwit/pull/5054

I merged #5054 so we can close this.


Work around new setProperty behavior when passed Dart functions

Security Insights

(2) Vulnerable direct dependencies were detected
1 vulns in ini < 1.3.6 via package-lock.json
1 vulns in node-fetch < 2.6.1 via package-lock.json

Action Items

Review dependencies for available updates
See this Splunk dashboard for more CVE details
Review PR for security impact; comment "security review required" if needed or unsure
Verify aviary.yaml coverage of security relevant code

Questions or Comments? Reach out on Slack: #support-infosec.

Security Insights

(2) Vulnerable direct dependencies were detected
1 vulns in ini < 1.3.6 via package-lock.json
1 vulns in node-fetch < 2.6.1 via package-lock.json

Action Items

Review dependencies for available updates
See this Splunk dashboard for more CVE details
Review PR for security impact; comment "security review required" if needed or unsure
Verify aviary.yaml coverage of security relevant code

Questions or Comments? Reach out on Slack: #support-infosec.

Done in https://github.com/Workiva/react-dart/pull/305


Remove version: Bitnami.Drupal version 9.3.4-0

[Automated] It returns code over 400 in all urls
Microsoft Reviewers: Open in CodeFlow

URL: https://downloads.bitnami.com/files/stacks/drupal/9.3.4-0/bitnami-drupal-9.3.4-0-windows-x64-installer.exe
OK
(Automated message - build 910)

Version still available.


Write pg_xlog/* into manifest

When archive logs are copied to pg_xlog, be sure to add them to the manifest.
This might be required to make some of the new unit tests work.

This was required to make restores of type "none" to work. 13544d51bf9be1128486b167a3ecb5dc3fb6a09c


i18n(es): Translated mdx.mdx

What kind of changes does this PR include?

New or updated content
Translated content

Description

What does this PR change? Give us a brief description.
Translated mdx.mdx to spanish

I have fixed a file that had broken links pointing to this page.

Gracias por la revisión 🤠


Use a web framework rather than raw Node.js http module

Our framework currently just uses raw http modules from Node.js core. We might consider using an existing framework - perhaps one optimized for speed such as Fastify.

@slinkydeveloper Fastify is as fast or faster than raw HTTP, and in refactoring the code to use it, I found that it was all a bit leaner, and provides a framework on which we can build and add features if necessary. The routing is less of a concern than just handling the requests, logging and other standardizing choices we would need to make. Using a framework makes these choices for us in many cases.

Ok no problem, just let's try to keep the dependencies as less as possible... More dependencies means more build time, that's why i'm worried

Yes, I agree with you re: build time. It is definitely something to keep an eye on.


Steps to reproduce
Choose any backend renderer and open a blank scene
Create a skeleton with 2 bones as seen in the screenshots
Select the skeleton and create a new SkeletonModificationStack2D, and add a SkeletonModification2DTwoBoneIK
Create a target node for the IK chain, and assign the target and the bones in the SkeletonModification2DTwoBoneIK
Make sure the SkeletonModifcationStack2D is enabled and run the scene
From what I know, this is the intended way to use IK in Godot 4, so realistically I assume it shouldn't throw any confusing errors and warnings? I could be doing something wrong though, considering that the current documentation is outdated...
Minimal reproduction project
SkeletonModifcationIKBug.zip

This has been reported in:

#81433

Which provides more information, consolidating there
Duplicate of: #81433

I encounter a similar case:
When I save a scene that contains skeleton node with another name, if I import that scene to another scene godot logs will flood with Drawing is only allowed inside NOTIFICATION_DRAW, _draw() function or 'draw' signal. errors.
Below is the video evidence, I saved Player scene as King scene because I want it to have the same skeleton and everything, but when I link it to the main scene the logs are flooded with errors. The skeleton modification that I use was SkeletonModification2DLookAt. It can be resolved by making a new scene instead, and copying each node one by one.
https://github.com/godotengine/godot/assets/29392405/96722c68-d26e-4e4c-9bbf-fd6c164e66c9


How to suppress auto-update

While testing it was found that when old version v5.6 is installed and shortcut is launched. Below pop-up comes up.

How to suppress auto-update during installation or post installation silently?
Note: Testing is done on Windows 10 x64 VM.

We are looking for settings to be implemented silently. Creating file BCUninstaller.settings in the install directory after installation and adding only values for suppressing check for updates does not work.

It re-takes the other inputs and above screen appears wherein check for updates is enabled:
There are multiple inputs that are taken after launching shortcut and all the settings are stored in BCUninstaller.settings.  Can you please suggest minimum settings that are required in the file, so that we can add above setting for suppressing the update.


No way to specify spec.ios.deployment_target for generated spec file

Because there's no way to specify the iOS deployment target, the build defaults to the lowest support iOS version (I believe iOS 4.3) for the sharedSwift project. This results in the build failing with:
<unknown>:0: error: Swift requires a minimum deployment target of iOS 7
Command CompileSwiftSources failed with a nonzero exit code

This can be worked around by forcing the target in the projects Podfile, but this is obviously not ideal.
post_install do |installer|
  installer.pods_project.targets.each do |target|
    target.build_configurations.each do |config|
      config.build_settings.delete 'IPHONEOS_DEPLOYMENT_TARGET'
    end
  end
end

Firstly it would be good to have a setting to be able to specify this. Although, would it make sense for a future version to use the cocoapods plugin configuration if available?

hi!
do you have platform :ios, '11.0' in your Podfile? with required for you version. Just our generated podspec not contains any target version and as i think this line set target for all pods which not have any own settings.
in sample app i not see any problems

I have platform :ios, '14.1' in my Podspec as the code I was attempting to generate uses SwiftUI and Combine. platform sets the main projects target not that of its dependencies.
See https://stackoverflow.com/a/37289688/425538 and https://github.com/CocoaPods/CocoaPods/issues/4859

ability to set iosDeploymentTarget was added in 0.3.0 - see readme for details

Worth adding the same for macOS, tvOS and watchOS?

i not test kswift with not ios apple targets, not know what will work what not...i think it should be separated issue for support all of apple targets - we should implement samples for testing at all, and deployment_target control


BugShaker logo banner text is blurred

The original asset seems to have soft edges. I don't think this is obvious enough to be by design? cc @davidklaw for thoughts:

The image I used was designed for non-retina and probably doesn't scale well. I suppose we'll give 2x a shot (it looks clearer in my branch) but I don't know how to juggle retina and non-retina like I normally would with a regular web app.

That looks much sharper to me (on a retina screen)!

Resolved by #35


Taxonomy

The kind of stuff described in https://attila.zutrinken.com/organising-content/
Required

a way to indicate tags, page var is fine
some functionality to collect all tags (basically just need to go through ALL_PAGE_VARS)
generate mainurl/tags/tagname/ would use a _layout/tag.html and fill it with a generated list

This is all pretty easy to do
Notes

need to keep track of tags associated to all pages so that if they get modified can re-trigger generation of tag pages, could just do that in a dict.

PS: cc @wikunia since you mentioned this, if you want to give it a shot I can lend you a hand :-)

Sounds nice. I'm interested on working on it on Monday. Will ask questions in slack if I have some. (I'll :smile: )

I had something like this working, but I don't remember on which machine so I guess it is lost now. Would be nice to have!

One small question: this should all be done whenever such a page variable tags exists, right? So the user still just calls serve and all folders are created automatically.

Ok here's at a high level what I would do:

optional path _layout/tag.html which would contain the structure that goes around one of those tag-list pages. If not there and tags are given, something would fail.
a local page var tags which allows a Vector{String} and is empty by default
a global dictionary TAGS which contains pairs rpath => [tags]
when process_mddefs is called (inside convert_md so that's called on every page trigger) check if tags is given, if it is check the TAGS dictionary and either add, remove or update the entry. If it's identical than before, do nothing, if it isn't and that we're not on the initial fullpass then trigger a generate_tag_pages function

The generate_tag_pages function would

take an optional argument indicating which page has triggered the update
create a __site/tag/ folder if it isn't there already
invert the dictionary TAGS to get tag => [rpaths]
go through each tag, (if the triggering page is given & the list of rpaths does not intersect with it, ignore)
for the tags that need an update, create the html which would be built out of _layout/tag.html and with the list of links, extracting page titles too via {{fill title rp}} etc
convert that html to resolve any {{...}} using convert_html
create with the converted html a page __site/tag/tagname/index.html

The generate_tag_pages would also have to be called after the initial fd_fullpass after ALL_PAGE_VARS and TAGS is populated

Ok this is now in master (and 0.7.6 will be released soon), un-announced officially because I'd like to battletest it a bit more (I'll add a theme/template which uses it soon). Help to report any problems in the mean time would be very welcome here!
API

add tags to a page with @def tags = ["aa", "bb"]
this will generate pages at /tag/aa/ and /tag/bb/ with the list of pages with the same tags
the way the list of results is shown is controlled by the html function hfun_list which

finds the pages with a given tag
sorts them by date, and if date not given by creation date
puts the results in a simple list

Users can easily overwrite this behaviour, they would need to implement something like this in their utils.jl, modifying the core of the logic however they want.
For instance users could define a variable short_description for all these pages and display  those in some order instead of a list.
function hfun_list(params)
    tag = params[1]
    TAG_PAGES = globvar("fd_tag_pages")
    c = IOBuffer()
    # -------------------------------------------
    # add your logic here
    write(c, "
Tag: $tag
")
    write(c, "
")
    rpaths = TAG_PAGES[tag]
    sorter(p) = begin
        pvd = pagevar(p, "date")
        if isnothing(pvd)
            return Date(Dates.unix2datetime(stat(p * ".md").ctime))
        end
        return pvd
    end
    sort!(rpaths, by=sorter, rev=true)
    for rpath in rpaths
        title = pagevar(rpath, "title")
        if isnothing(title)
            title = "/$rpath/"
        end
        write(c, "
$title
")
    end
    write(c, "
")
    # -------------------------------------------
    return String(take!(c))
end

Currently locvar("fd_rpath") doesn't seem to work on tag pages. For me it just spits out some (for me random) path instead of the tag path. This is probably because the tag pages only exist in the __site folder

yes tag pages don't have their own page variables. If you want to recover which tag  page you're on you can do so via fd_tag

this  is now supported.


[bug] MetaMask connector opens both MetaMask and Coinbase Wallet modals

Is there an existing issue for this?

[X] I have searched the existing issues

Package Version
0.2.28
Current Behavior
https://user-images.githubusercontent.com/1538687/164948227-b637a2df-483f-4665-85c1-238bcd5075be.mp4
connect(metamaskConnector) opens both MetaMask and Coinbase
Expected Behavior
Button to open MetaMask extension should open just MetaMask
Steps To Reproduce

Go to https://wagmi.sh/guides/connect-wallet
Tap MetaMask

Link to Minimal Reproducible Example (CodeSandbox, StackBlitz, etc.)
No response
Anything else?
No response

See https://github.com/tmm/wagmi/issues/260


Implement revised time stepping schemes

Purpose
The purpose of this SDI is to implement the SSP IMEX scheme, described in this document. The motivation for implementing this scheme is to maintain bounds-preservation of limited prognostic fields across stages.
Cost/Benefits/Risks

Cost: 2-3 engineers/scientists for 3-4 weeks
Benefits: It's expected that this scheme should preserve bounds constraints and (hopefully) improved numerical stability
Risks: Utilization of time and cost of resources

People and Personnel
(@ the personnel required/requested to implement the software solution)

Lead: @dennisYatunin and @charleskawczynski
Collaborators: @Zhengyu-Huang
Reviewers: @Zhengyu-Huang

Components
Components delivered will include:

[ ] Fix the (currently broken) docs
[ ] An implementation of a user-facing scheme constructor
[ ] An implementation of ClimaTimeSteppers's step_u! with appropriate caching
[ ] A detailed outline of the notation and scheme in the documentation
[ ] Improve performance (if necessary). If this scheme is more than 30% slower than the existing implementation, we will spend 1 week on investigating and improving performance.

Inputs
N/A
Results and deliverables
See the components section
Task Breakdown And Tentative Due Date

[ ] One PR for detailed documentation including notation and the algorithm
[ ] One PR containing implementation of the algorithm, cache and tests

Proposed Delivery Date
December 14th

What about this should take 3-4 weeks? The straightforward implementation should not take long. Are you concerned about performance?

What about this should take 3-4 weeks? The straightforward implementation should not take long. Are you concerned about performance?

I think the 3-4 weeks takes several things into account:

We need to carefully converge on the notation in the code and documentation, to ensure that there's a clear mapping between the documentation and algorithms
We need to (or, there's great benefit to) extend the existing design, which adds some (but not excessive) friction to leverage already-engineered solutions (e.g., custom/generic stopping criteria, compatibility with OrdinaryDiffEq, leveraging existing CI / docs infra and tests).
We need to convert, to some extent, the google document into documentation in the code
We need to implement the algorithm, a (simple) caching structure
We need to get the resulting code running, i.e., fix bugs in the algorithm / caching structure after our first draft
Add tests (this should be fairly straight forward to extend), and time to fix issues that arise when running unit tests
We'll want to test this in ClimaAtmos, before merging, to make sure that we can demonstrate that the algorithm works in at least a simple example.

I'm not concerned about performance. At the moment, we're going to do the bare minimum for the implementation, and we'll only work on performance if we see it as an issue in the first ClimaAtmos tests.

Ok. Tests we already have for all standard cases. You may just need to re-tool tests for limiters (incorporating @valeriabarra's tests).
Daniel and I can help with notation in the doc. Just let us know what you need. This is straightforward, as is making it code documentation when it's done.
How about we first get the code working (e.g., the revamped ARK_IMEX--it should be a straightforward replacement of what we have, with small changes when there are limiters)? Finish this, merge it, test it (with existing tests), and then move on. I want to avoid a situation in which this leads to overengineering before we test the simplest cases.

From our discussion today: Possible test cases could be: gravity waves, sound wave on a sphere, diffusion.

From our discussion today: Possible test cases could be: gravity waves, sound wave on a sphere, diffusion.

@charleskawczynski and I talked some more about this. It'll be better to have simpler test cases, which do not require an atmosphere model yet exercise the full functionality of the timesteppers. There are good tests in ARKode, including some that are multivariate (e.g., 1.13 and 1.14 in http://runge.math.smu.edu/ARKode_example.pdf).

Updates:

Imex ARK is now complete, merged in #85

Related PRs:

https://github.com/CliMA/ClimaAtmos.jl/pull/1179
https://github.com/CliMA/ClimaAtmos.jl/pull/1196
https://github.com/CliMA/ClimaAtmos.jl/pull/1185
https://github.com/CliMA/ClimaAtmos.jl/pull/1193
https://github.com/CliMA/ClimaAtmos.jl/pull/1190
https://github.com/CliMA/ClimaAtmos.jl/pull/1179
https://github.com/CliMA/ClimaAtmos.jl/pull/1177

@OsKnoth, can you please comment on this issue and summarize the issue we faced, and fixed, in this commit? Just so that we have a public record

Next we have:

[ ] Delete old (and unused) time steppers (and related tests)
[ ] Add more unit tests, (e.g., 1.13 and 1.14 in http://runge.math.smu.edu/ARKode_example.pdf)
[ ] Add SSP algorithm, described in the google doc


Set check_same_thread false so that one App can be used in parallel

Description
This PR adds check_same_thread=False which will help us use Embedchain directly as a bot or an instance in REST APIs.
Refer: #856

can you please add a test for this @sidmohanty11 ?


addComponents with @variants always applies to all selectors.

What I was trying to solve
I am using the addComponents function to add a custom component with variants on child selector as follows:
addComponents({
    "@variants hover": {
        ".parent .child": {
            color: "blue"
        }
    }
});

The Issue I was facing
The variants are also applied to the .parent selector:
.parent .child {
  color: blue;
}

.hover\:parent:hover .hover\:child:hover {
  color: blue;
}

What I tried
Nesting the @variants directive inside the .parent selector:
addComponents({
    '.parent': {
         '@variants hover': {
            '.child': {
                color: "blue"
            }
        }
    }
});

But the nesting doesn't resolve:
.parent {
  .child {
    color: blue;
  }
  .hover\:child:hover {
    color: blue;
  }
}

How I solved it
I manually required and used the postcss-nested package and added the plugin after tailwindcss in the postcss config which successfully ensures the nesting selectors are appended as a selector after the variants are applied.
Where was the problem
By looking at the code in src/util/processPlugins.js, it applies the postcss-nested too early.
Proposed solution
An easy fix would be to also apply postcss-nested after the tailwindcss in src/index.js
Why bother
The proposed solution will help in using the tailwindcss plugin mechanism out of the box as opposed to asking people to manually require the postcss-nested plugin in addition to the custom plugin.

@variants is really only meant to be used with simple single class utilities, not multi-class selectors like .parent .child, so what you're trying to do here is really undefined behavior right now.
I would just write the component selectors you want manually:
addComponents({
  ".parent .child": {
    color: "blue"
  },
  ".parent .hover\:child:hover": {
    color: "blue"
  },
});

Even that looks really weird to me though so I'm guessing you're real use case is a bit different.
Our use of postcss-nested is meant just for the CSS-in-JS syntax in plugins and if we moved where that processing happens it would run across your entire CSS file which might result in unexpected behavior for people who would rather use another nesting plugin with a different syntax like postcss-nesting.
No plans to change anything about how this works right now, if anything we may change things to be more defensive and throw an explicit error if you try to use @variants when defining a component or try to use multiple classes in a utility 👍

Thanks.
Fair enough. Yes, I was working on a site color switcher where one can set any color on a parent and the entire tree where the site color is being used will then reflect the new site color.
Basically an alternate to css variables for site color switching.
I guess I should stick to using postcss-nested manually.


Update ApesPlanet extensions twitter link

I'm submitting an update request to update the existing token extension

here is PR link https://github.com/solana-labs/token-list/pull/23341
[ ] bug report
[ ] feature request
[ ] question about the decisions made in the repository
[ ] question about how to use this project

Summary

Other information (e.g. detailed explanation, stack traces, related issues, suggestions how to fix, links for us to have context, eg. StackOverflow, personal fork, etc.)

merged


decode_transactions error: InputTooShort, use empty tx_list

Describe the bug
Good afternoon, dear taiko team. Can you tell me how to fix this error? It arose after I updated the files today using "git pull". At the same time, everything works as before, but this error has appeared. Thank you.

Steps to reproduce
Steps to reproduce here.
Spam policy

[X] I verify that this issue is NOT SPAM and understand SPAM issues will be closed and reported to GitHub, resulting in ACCOUNT TERMINATION.

Ah this is not a real error and part of the normal process of decoding the tx data. While it is a kind of error, it's an error that needs to be handled internally so indeed a bit confusing for people that look at it, we probably shouldn't print it as an error.

Understood, thanks :)


Implement OAuth for Sign-In

Integrate OAuth authentication mechanisms, including Google and Microsoft, to allow users to sign in securely.

Currently setup for Github. Will spin separate issues out for other auth providers.


Burp Extension Java versions mismatch

When compiling the Burp extension, it is compiled for java 9 (major version 53), as some files define this as the desired/required version.  When trying to add the extension in Burp, if running from the Burp installer and launcher (which uses the bundled Java 8 instance included with Burp), the extension cannot be loaded due to the major version mismatch (53 vs 52).
Attempts to compile the extension for "-target 8" fail, because the code requires to be targeted for Java 9.
One can workaround the issue by running Burp manually with "java -jar burp.jar", using Java 9.  However, when this is done, Burp "complains" that it has not been tested in Java other than 8, which is the recommended, and "things could fail or go wrong".
Thus, the only way of using the Extension is to use Burp with a "non-recommended" Java.
The following files require major version 53:
burp/IBurpExtender.class
burp/IBurpExtenderCallbacks.class
com/nccgroup/autochrome/useragenttag/BurpExtender.class

There shouldn't be anything in the code that requires Java 9.  (It builds cleanly for me using javac 1.8.0_92 from Homebrew on macOS, for example.)
Can you try compiling using -release 8 instead of -target 8, and see if that works?  If it doesn't, please let me know what compiler + version you're using, and what specific errors you get when compiling and/or loading the extension?  Thanks.

I tried using both Openjdk 8 and Oracle Java 8.  However, both javac binaries do not have a -release, but only a -target, as stated in the -help command:
-target <release>            Generate class files for specific VM version
The output when trying to compile it with -release is the following:
warning: ./burp/IBurpExtender.class: major version 53 is newer than 52, the highest major version supported by this compiler.
  It is recommended that the compiler be upgraded.
warning: ./burp/IBurpExtenderCallbacks.class: major version 53 is newer than 52, the highest major version supported by this compiler.
  It is recommended that the compiler be upgraded.
warning: ./com/nccgroup/autochrome/useragenttag/BurpExtender.class: major version 53 is newer than 52, the highest major version supported by this compiler.
  It is recommended that the compiler be upgraded.
3 warnings

Yes, the -release flag is new with the Java 9 javac.  If you're compiling with Java 8, no flags should be necessary.
I'm sorry, but I haven't been able to reproduce the major version warning that you're seeing, on multiple platforms and Java versions.  Maybe try running javac under env -i, to ensure you don't have any environment variables related to other Java versions affecting things?
In any case, I've released a binary JAR of the extension for anyone who's having difficulty building it themselves.  Hope that's helpful:  https://github.com/nccgroup/autochrome/releases/download/20180411-burp-ext-snapshot/autochrome-useragenttag.jar

I saw this on Ubuntu, it is fairly simple to fix your environment though in order to correctly build the jar.  First check what versions of Java you have installed:
# update-java-alternatives -l
java-1.9.0-openjdk-amd64       1091       /usr/lib/jvm/java-1.9.0-openjdk-amd64
java-8-oracle                  1081       /usr/lib/jvm/java-8-oracle
java-9-oracle                  1091       /usr/lib/jvm/java-9-oracle

Set to Java 8(I'm using Oracle Java here, if you installed from the repos then the openjdk 8 name will be different):
# sudo update-java-alternatives -s java-8-oracle

If you have already ran javac under Java 9, then rebuilding will generate some warnings:
warning: ./burp/IBurpExtender.class: major version 53 is newer than 52, the highest major version supported by this compiler.
  It is recommended that the compiler be upgraded.
warning: ./burp/IBurpExtenderCallbacks.class: major version 53 is newer than 52, the highest major version supported by this compiler.
  It is recommended that the compiler be upgraded.
warning: ./com/nccgroup/autochrome/useragenttag/BurpExtender.class: major version 53 is newer than 52, the highest major version supported by this compiler.
  It is recommended that the compiler be upgraded.

To get rid of those, you can either clean up all the class files from the previous build or revert to put src folder in a clean state.

Closing, please re-open the issue if it still exists.


[Test] Disable flakey test

This seems to be failing more regularly now and is often blocking CI. Disable for now while we investigate.

@swift-ci please smoke test


Disabling section/component separator does not work.

Current config
  use {
    'hoob3rt/lualine.nvim',
    requires = {'kyazdani42/nvim-web-devicons', opt = true},
    event = 'VimEnter *',
    config = function()
      require('lualine').setup{
        options = {
          theme = require('helpers').getLualineTheme(),
          icons_enabled = true,
          -- section_separators = nil, component_separators = nil
          component_separators = {'', ''},
          section_separators = {'', ''}
        },
        sections = {
          lualine_a = { 'mode' },
          lualine_b = { 'branch' },
          lualine_c = { 'filename', 'diff', 'g:coc_status' },
          lualine_x = { 'encoding', 'fileformat', 'filetype' },
          lualine_y = { 'progress' },
          lualine_z = { 'location' },
        },
        inactive_sections = {
          lualine_a = {  },
          lualine_b = { 'branch' },
          lualine_c = { 'filename' },
          lualine_x = {  },
          lualine_y = {  },
          lualine_z = { 'location' }
        },
        extensions = { 'fzf' }
      }
    end
  }

To disable separators, I tried using section_separators = nil, component_separators = nil which doesn't work. So I am currently setting empty values for them which works.

It's here . Since setting a key to nil removes the key from table , section/conponent_separator keys don't apear in pairs :D . @hoob3rt maybe we should just drop the nil to remove separators .

section_separators = '',
component_separators = ''

Yep this works too.

section_separators = '',
component_separators = ''

Yep this works too. Thanks. We can close this issue then.

No, don't close this yet. I was aware of this and have a fix ready. I will merge it late today when I get on my private machine

Actually seems like my solution was incorrect and @shadmansaleh is right about nil not being indexed. I have changed the docs in https://github.com/hoob3rt/lualine.nvim/commit/9db1a38357f8c3d240eef449f0ddd4e7656e253b


feat(home-manager): add support for freetube

Adds support for theming FreeTube. The colors are built-in, so no new sources have been added.
Also, FreeTube supports two different accent colors, so I added a secondaryAccent option. I made it default to FreeTube's accent rather than the global accent setting because it seemed like it would be intuitive behavior to have them match if, say, only accent is overridden.

No worries! Thank you too!


[Bug] consecutive tests with the same resource names show intermittent failures

chainsaw version Version
v0.2.8
Description
When there are several consecutive tests which use the same resource names for cluster resources, there are intermittent failures.
Setting unique resource names works.
Trying to use the Kubernetes generateName fails with an error stating a name is required.
Steps to reproduce
See above.
Expected behavior
Fix cleanup logic across tests.
Support create with generateName, or provide some way to automatically add a unique suffix to names.
Screenshots
No response
Logs
No response
Slack discussion
No response
Troubleshooting

[X] I have searched other issues in this repository and mine is not recorded.

Thanks for reporting @JimBugwadia.
Do you have an example ? Are test running concurrently ?

Closing, cannot reproduce. Please reopen if needed.


Introduce MR metrics

Description of your changes

Consume https://github.com/crossplane/crossplane-runtime/pull/683 and https://github.com/crossplane/upjet/pull/390.
I have:

[x] Read and followed Crossplane's contribution process.
[x] Run make reviewable to ensure this PR is ready for review.
[ ] Added backport release-x.y labels to auto-backport this PR if necessary.

How has this code been tested

I haven't tested yet, because I don't have my GCP ProviderConfig set up. Testing steps can be found at https://github.com/crossplane-contrib/provider-upjet-aws/pull/1281.

/test-examples="examples/cloudplatform/serviceaccount.yaml"

/test-examples="examples/cloudplatform/serviceaccount.yaml"

Hi @turkenf,
Let's mention about the Ready and Sync column swap in kubectl get output in the release notes as we did before for the other providers.


2024-12-10_01-37-31_master-next_aws-c-s3

Automatically created.

Successfully created backport PR for kirkstone-next:

#10667

Successfully created backport PR for scarthgap-next:

#10668

Successfully created backport PR for styhead-next:

#10669


Import bank holidays from google

New dialog probably?

Or simply import holidays from a public API such as https://holidayapi.com/ which has a Node.js API as well: https://github.com/joshtronic/node-holidayapi

hi @jekuno!
thank you for those links
(I was not aware of this service)

It appeared that holidayapi.com has quite expensive package to suite our needs so probably worth re-using some other resources as http://www.officeholidays.com/countries/index.php

Oh sorry, I thought holidayapi.com was a free service. It seems as if officeholidays.com doesn't offer an API, does it?

The holidayapi.com offers free historical data..
I was thinking scraping officeholidays.com, not sure about there license though... This needs to be clarified.

I think in the long run we need a reliable API because dates of certain holidays differ from year to year. So you would have to scrape the website on a regular base which is very error prone (will break sooner or later).

Absolutely!
I just had an idea to allow customers to use https://holidayapi.com/ by purchasing their API token and linking it to the TimeOff.management account.
I need to elaborate on this more.

You're right it's quite expensive. Only big companies will be willing to spend $135 a year just for receiving maybe 20 dates per year.
Maybe there are free alternatives which offer an API?

For instance this does not promise easy ride: https://opendata.stackexchange.com/questions/1926/list-of-public-holidays-by-countries

https://github.com/novafloss/workalendar looks interesting.

yeah

Ended up using https://github.com/vpp/date-holidays

Now system use set of default holidays when creating new account.
What is left: to add ability to update current year's bank holidays for existing account.

Just added ability to import default bank holidays into existing accounts.


Update Model.md

Not totally sure about this (but it's the only way I've gotten it to work), but I think instances of MeshNormalMaterial need THREE. in front of them to work. With just new MeshNormalMaterial I get ReferenceError: Can't find variable: MeshNormalMaterial. This change adds THREE. to the documentation.

The intended behavior is that you need to import MeshNormalMaterial from the Form library. But you could of course import it from THREE as well.

Ah, like here? https://github.com/emilwidlund/framer-form/blob/5407e9e1892d52299925adf742416b96382cf619/debug/app.coffee#L7

Yes 😊


Migrate to EnumShape

Deprecate EnumTrait and migrate to EnumShape.
Closes #1671
Checklist

[x] I have updated CHANGELOG.next.toml if I made changes to the smithy-rs codegen or runtime crates
[x] I have updated CHANGELOG.next.toml if I made changes to the AWS SDK, generated SDK code, or SDK runtime crates

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Projection s3 failed: software.amazon.smithy.codegen.core.CodegenException: Unnamed @enum shapes are unsupported.

Heh. We may need to upgrade the SDK models for this to pass. The current S3 model is IDLv1.
Unfortunately, we can't upgrade the models until our endpoints 2.0 implementation lands though.

Projection s3 failed: software.amazon.smithy.codegen.core.CodegenException: Unnamed @enum shapes are unsupported.

Heh. We may need to upgrade the SDK models for this to pass. The current S3 model is IDLv1.
Unfortunately, we can't upgrade the models until our endpoints 2.0 implementation lands though.

It fails on EC2 and S3. For EC2 v2:

[ERROR] com.amazonaws.ec2#AmazonEC2: Unable to resolve trait smithy.rules#endpointTests. If this is a custom trait, then it must be defined before it can be used in a model.

For S3 v2:

[ERROR] com.amazonaws.s3#DeleteBucketWebsiteRequest$Bucket: Unable to resolve trait smithy.rules#contextParam. If this is a custom trait, then it must be defined before it can be used in a model.

@enums work. We can either remove this check until v2 or I'm ok waiting for the model upgrades (there might be some merges / refactoring to be done by then)

This PR is waiting for the migration to v2 models; there are missing features on the client before this migration can be done. When test models are in v2, this PR can be merged. (agreed with @jdisanti )

I can update the models once https://github.com/awslabs/smithy-rs/pull/1972 is merged.

The models are updated. This should be unblocked now.

we've decided to begin closing old PRs that we don't plan to work on in the near future. Please let us know if you still think this PR is needed


feat!: constant inputs for blackbox

This PR allows to use constant values for blackbox inputs.
This is a draft PR:
Only MultiScalarMul is currently handling constant input, so it will fail if constant inputs are used for any other blackboxes.

I've pushed a commit which removes the trait bounds being applied to the various struct definitions as it's generally good practice to avoid these unless absolutely necessary and apply the bounds to impls instead.

Benchmark results
Metrics with a significant change:

avm_simulation_time_ms (Token:transfer_public): 31.8 (-37%)
protocol_circuit_witness_generation_time_in_ms (private-kernel-init): 461 (-16%)

Detailed results
All benchmarks are run on txs on the Benchmarking contract on the repository. Each tx consists of a batch call  to create_note and increment_balance, which guarantees that each tx has a private call, a nested private call, a public call, and a nested public call, as well as an emitted private note, an unencrypted log, and public storage read and write.
This benchmark source data is available in JSON format on S3 here.
Proof generation
Each column represents the number of threads used in proof generation.

Metric
1 threads
4 threads
16 threads
32 threads
64 threads

proof_construction_time_sha256_30_ms
11,370
3,073 (+1%)
1,663 (+13%)
1,475 (-9%)
1,581 (+3%)

proof_construction_time_sha256_100_ms
43,840
11,804 (+1%)
5,490
5,492 (+1%)
5,374 (+1%)

proof_construction_time_poseidon_hash_ms
78.0 (+1%)
34.0
34.0
58.0
87.0 (-1%)

proof_construction_time_poseidon_hash_30_ms
1,518
418 (+1%)
203 (+1%)
229 (+1%)
268

proof_construction_time_poseidon_hash_100_ms
5,603 (-3%)
1,518 (-3%)
679 (-5%)
726 (-5%)
751 (-6%)

L2 block published to L1
Each column represents the number of txs on an L2 block published to L1.

Metric
4 txs
8 txs
16 txs

l1_rollup_calldata_size_in_bytes
1,412
1,412
1,412

l1_rollup_calldata_gas
9,476
9,468
9,476

l1_rollup_execution_gas
610,297
610,289
610,297

l2_block_processing_time_in_ms
756 (-1%)
1,406 (-1%)
2,698 (-1%)

l2_block_building_time_in_ms
25,655
51,208
100,352

l2_block_rollup_simulation_time_in_ms
25,655
51,208
100,351

l2_block_public_tx_process_time_in_ms
22,056
47,397
96,581

L2 chain processing
Each column represents the number of blocks on the L2 chain where each block has 8 txs.

Metric
3 blocks
5 blocks

node_history_sync_time_in_ms
6,961 (-2%)
9,829

node_database_size_in_bytes
12,177,488
16,113,744

pxe_database_size_in_bytes
16,254
26,813

Circuits stats
Stats on running time and I/O sizes collected for every kernel circuit run across all benchmarks.

Function
time_ms
bytecode_size_in_bytes

GasToken:_increase_public_balance
66.8
13,873

GasToken:set_portal
16.7 (-2%)
3,495

Token:constructor
93.6 (+1%)
24,207

FPC:constructor
63.2 (-1%)
13,893

GasToken:mint_public
51.8 (-1%)
10,241

Token:mint_public
633 (+4%)
19,216

Token:assert_minter_and_mint
60.3
13,034

AuthRegistry:set_authorized
32.5 (+2%)
7,869

FPC:prepare_fee
187 (+22%)
15,129

Token:transfer_public
:warning: 31.8 (-37%)
31,425

FPC:pay_refund
193 (-7%)
28,061

Benchmarking:increment_balance
2,711
15,407

Token:_increase_public_balance
56.2
15,089

FPC:pay_refund_with_shielded_rebate
199 (-1%)
29,148

Public DB Access
Time to access various public DBs.

Function
time_ms

get-nullifier-index
0.150 (-4%)

Tree insertion stats
The duration to insert a fixed batch of leaves into each tree type.

Metric
1 leaves
16 leaves
64 leaves
128 leaves
256 leaves
512 leaves
1024 leaves

batch_insert_into_append_only_tree_16_depth_ms
10.3
16.6
N/A
N/A
N/A
N/A
N/A

batch_insert_into_append_only_tree_16_depth_hash_count
16.8
31.7
N/A
N/A
N/A
N/A
N/A

batch_insert_into_append_only_tree_16_depth_hash_ms
0.599
0.512
N/A
N/A
N/A
N/A
N/A

batch_insert_into_append_only_tree_32_depth_ms
N/A
N/A
48.2
75.7
131
244 (-1%)
470

batch_insert_into_append_only_tree_32_depth_hash_count
N/A
N/A
95.9
159
287
543
1,055

batch_insert_into_append_only_tree_32_depth_hash_ms
N/A
N/A
0.492
0.465
0.451
0.442 (-1%)
0.439

batch_insert_into_indexed_tree_20_depth_ms
N/A
N/A
59.6 (-1%)
112 (+1%)
183 (+1%)
351 (-1%)
694

batch_insert_into_indexed_tree_20_depth_hash_count
N/A
N/A
109
207
355
691
1,363

batch_insert_into_indexed_tree_20_depth_hash_ms
N/A
N/A
0.504 (-1%)
0.501
0.485 (+1%)
0.476 (-1%)
0.476

batch_insert_into_indexed_tree_40_depth_ms
N/A
N/A
72.7
N/A
N/A
N/A
N/A

batch_insert_into_indexed_tree_40_depth_hash_count
N/A
N/A
133
N/A
N/A
N/A
N/A

batch_insert_into_indexed_tree_40_depth_hash_ms
N/A
N/A
0.518
N/A
N/A
N/A
N/A

Miscellaneous
Transaction sizes based on how many contract classes are registered in the tx.

Metric
0 registered classes
1 registered classes

tx_size_in_bytes
85,672
670,983

Transaction size based on fee payment method
| Metric |  |
| - |  |

Looks good, shall we merge this on monday so it can be included in the Tuesday release? We'll be able to immediately sync out to Noir then.

We've got a release tomorrow so merging this now.


[release-1.5] Manual cherrypick of pull#21323

This is a manual cherrypick of https://github.com/istio/istio/pull/21323. It also pulls in https://github.com/istio/cni/pull/255 and updates the generated files.
This and the related commits fix the istioctl parameters that are passed to CNI and the default behavior of the CNI repair controller.

@stewartbutler: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

gencheck_istio_release-1.5
d74d2c52a9552a002cfa676a5b52e8e8bbdac3e0
link
/test gencheck_istio_release-1.5

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@stewartbutler: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-security-k8s-tests_istio_release-1.5
7cb38eb06ae1374ad9a018f82e7fc2d97171392d
link
/test integ-security-k8s-tests_istio_release-1.5

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/test integ-security-k8s-tests_istio_release-1.5


ModuleNotFoundError: No module named 'streamlit.components'; 'streamlit' is not a package

I want to run the example in https://folium.streamlit.app/ but encountered ModuleNotFoundError: No module named 'streamlit.components'; 'streamlit' is not a package. I have installed steamlit and steamlit-folium.
import streamlit as st
from streamlit_folium import st_folium
python version: 3.11.9

How are you trying to run the example? Did you make a fork of this repo, are you copying the code in...something else?

`import folium
import streamlit as st
from streamlit_folium import st_folium
m = folium.Map(location=[39.949610, -75.150282], zoom_start=16)
folium.Marker(
[39.949610, -75.150282], popup="Liberty Bell", tooltip="Liberty Bell"
).add_to(m)
st_data = st_folium(m, width=725)`
just copy the code into PyCharm and install the packages.

Well, I could run it in another pc so maybe I could find the problem by myself. Thanks!


Make rascaline-torch an optional dependency of rascaline

Trying to run pip install .[torch] from source will fail with an error like this:
INFO: pip is looking at multiple versions of metatensor-torch to determine which version is compatible with other requirements. This could take a while.
ERROR: Cannot install rascaline-torch, rascaline==0.1.0.dev457 and rascaline[torch]==0.1.0.dev457 because these package versions have conflicting dependencies.

The conflict is caused by:
    rascaline[torch] 0.1.0.dev457 depends on metatensor-core 0.1.0 (from https://github.com/lab-cosmo/metatensor/archive/d97ea65.zip#subdirectory=python/metatensor-core)
    rascaline 0.1.0.dev457 depends on metatensor-core 0.1.0 (from https://github.com/lab-cosmo/metatensor/archive/d97ea65.zip#subdirectory=python/metatensor-core)
    metatensor-torch 0.1.0 depends on metatensor-core 0.1.0 (from /private/var/folders/nz/mgmqnhrj4mzfjlnqbgn02t780000gn/T/pip-install-v_q_c4ik/metatensor-torch_49679123430840aca28a7d2b54835964/python/metatensor-core)

This is a known limitation of pip, that will be lifted once we have metatensor on PyPI (soon!). In the mean time, this code should allow to install rascaline[torch] from https://github.com/Luthaf/nightly-wheels.

:books: Documentation preview :books:: https://rascaline--230.org.readthedocs.build/en/230/

I was thinking this could wait for the release of metatensor on pypi, which would make it much more usable. Right now, this is not very useful.

Ahh the error is still appearing with the current change?

Okay then I agree to wait until we have a pip release.