fix: support aria-controls with multiple ids in Toogler

Closes https://github.com/zurb/foundation-sites/issues/11166
-- edited by @ncoden

I removed the old code, but now I get a failed check. I can't see what I did wrong so could you take a look?

The Travis test? Well, it seems there was a timeout accessing the Browserstack API in general. I'll try to rerun the test.

Thanks!

The Browserstack test successfully ran now. You can also do it by clicking on the retry button.

https://travis-ci.org/zurb/foundation-sites/builds/365598109 (you get there by clicking on the green checkmark / red cross next to your commit).

Ah, your first contribution here. Congrats :tada:
We can also push changes to your branch and can give you feedback through reviews.
Great that you spotted the issue.
So far everything is ok and tests are stilk ok. I'll try to test your changes later.

Hi @MoarCoding. Thanks for your issue & PR, that's a nice first contribution 🎉!
I have a few comments to make about it. I hope it will help you to improve yourself in Git and working on Open Source projects.

Your commits names and Pull Request title must be in the "imperative" form. It must describe "what this commit/PR does", like if the sentence was starting by now the software should.... I renamed your PR to ...support aria-controls with multiple ids in Toogler
At Foundation, we use prefixes like feat (new feature), fix (you repair something), docs (documentation), refactor (you change the code without introducing changes), style (you simply change code formatting), tests (units or visual tests) or chore (for boring day-to-day tasks not touching the actual code). I would recommend you to use them for Foundation, but also your others projects. You can take a look at the AngularJs Git Commit Message Convention also.
Please describe everything you did and why in your commits and Pull Requests body. Even if you talked about it in the PR you're resolving. It's always helpful later. Explains what you did if the code is not clear enough (but it should be) and for which reasons. Give references (in this case the W3C Reference about aria-controls would be useful. You should always reference the issue you are closing (like Closes  #11166).
Configure Git so it uses your GitHub email address. See https://help.github.com/articles/setting-your-commit-email-address-in-git/. This way we can know you are the author of these commits. You can also sign them if you like.
Always open a pull request from a dedicated branch (like fix/toggler-support-aria-controls-multiple-ids-11166). So you develop branch stay clean and you can provide multiple Pull Requests for various issues.

And finally, here are some helpful ressources for Git: 📚

http://rogerdudler.github.io/git-guide/
https://guides.github.com/introduction/git-handbook/
http://nvie.com/posts/a-successful-git-branching-model/

Thanks, ncoden! I'll make sure to tick those boxes when submitting my next PR.


Documentation incomplete - and links to Portugese pages?

I have no idea how to issue a query on documents.
You just state "query like this..." but where to put the query in the msg object? No clue.
If I run without the query statement, I get an error message "Cannot read property 'replace' of undefined"
The idea is nice, but the current state is not really useful.
All your links to more information lead to Portugese pages... :-(

Hi, @Zordid - same comment as the other issue. If you're still up for trying this node, the document was updated a bit to help you get going.


Header value contains an extra trailing empty space

GitHub

Disovered in https://github.com/mswjs/msw/pull/648 (build log).

Current behavior
When appending a header via headers.set(name, value) the value sometimes contains an empty trailing space:
{
  "x-powered-by": "msw ",
  "content-type": "application/json ",
  "x-header": "yes"
}

See the values of the x-powered-by and content-type headers.

Expected behavior
Header values do not contain extra leading/trailing spaces.

This is an issue in NRI when calling XMLHttpRequest.getAllResponseHeaders():
https://github.com/mswjs/node-request-interceptor/blob/b968f90042de6a34d7ffcdee7f18d7264f95e586/src/interceptors/XMLHttpRequest/XMLHttpRequestOverride.ts#L448-L450
There is an extra space after the value causing this issue.


Three layered clusterable model with orderables causes issues

Issue Summary
When creating a clusterablemodel with an orderable that contains an orderable on it's own as well, the code seems to break for the last orderable.
Steps to Reproduce

create a model structure as followed

  class Schedule(ClusterableModel):
      base_form_class = ActivityScheduleForm

      page = models.OneToOneField(
          'wagtailcore.Page',
          null=True,
          blank=True,
          on_delete=models.SET_NULL,
          related_name='schedule',
      )

      panels = [
          PageChooserPanel('pagename'),
          InlinePanel('available_days'),
      ]

  class AvailableDay(ClusterableModel, Orderable):
      day = models.CharField(
          choices=settings.DAYS,
          max_length=max([len(choice[0]) for choice in settings.DAYS]),
          verbose_name=_("day"),
      )
      schedule = ParentalKey(
          Schedule,
          verbose_name=_("schedule"),
          related_name='available_days',
      )

      panels = [
          FieldPanel('day'),
          InlinePanel('timeframes'),
      ]

  class AvailableTime(Orderable):
      start_time = models.TimeField(
          verbose_name=_("start time"),
      )
      end_time = models.TimeField(
          verbose_name=_("end time"),
      )
      available_day = ParentalKey(
          AvailableDay,
          verbose_name=_("available day"),
          related_name='timeframes',
      )

      panels = [
          FieldPanel('start_time'),
          FieldPanel('end_time'),
      ]

note: settings.DAYS is structured as followed
    DAYS = [
        ('monday', _("Monday")),
        ('tuesday', _("Tuesday")),
        ('wednesday', _("Wednesday")),
        ('thursday', _("Thursday")),
        ('friday', _("Friday")),
        ('saturday', _("Saturday")),
        ('sunday', _("Sunday")),
    ]

Edit admin.py as followed

  @modeladmin_register
  class ScheduleAdmin(ModelAdmin):
      model = Schedule
      menu_label = _("Activity schedule")
      menu_icon = 'date'

Steps to reproduce bug:
Go to the schedule admin page

Click on the “add” button and add a day

Click once more on the “add” button and add two timeframes

The first one will show you an option for times. The second one however will have no functionality, nor will it save it’s data when trying to save.

Notes:
This only happens on the initial creation of a day+timeframe. After the initial creation you can add as many time timeframes without it breaking for that specific day.
When adding two different timeframes, it doesn’t recognize the fact that there is two but when saved it takes the times of the last created one.

I have confirmed that this issue can be reproduced as described on a fresh Wagtail project: (no)

Technical details

Python version: Python 3.8.5.
Django version: Version: 3.1.3.
Wagtail version: Version: 2.10.1
Browser version: Firefox 83

Hi @CherryChopsticks - thanks for the report. This is a known issue, covered here - #5770


update recipe for 803 release

Checklist

[x] Used a personal fork of the feedstock to propose changes
[ ] Bumped the build number (if the version is unchanged)
[x] Reset the build number to 0 (if the version changed)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[ ] Ensured the license file is being packaged.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.
I do have some suggestions for making it better though...
For recipe:

It looks like the 'papilo' output doesn't have any tests.
License is not an SPDX identifier (or a custom LicenseRef) nor an SPDX license expression.

Documentation on acceptable licenses can be found here.

@conda-forge-admin please rerender


feat(bindings/c): add writer operation for Bindings C and Go

part of #4892.

I changed the test service to fs for maximum full capabilities.
Use BlockWriter instead of StdWriter as StdWriter has a limitation of max capacity of buffer to write in for each write: https://github.com/apache/opendal/blob/7821d778859ecdf9915a9bde75b8bdeec9cfc0bb/core/src/types/blocking_write/std_writer.rs#L42
Fixed some behavior tests.

Ready for review


Module Review html.angular

I'll do the adjustments @junichi11 requested and then merge. Thank you.


CLI help doesn't work well without a working configuration

Have you checked the roadmap on the website, and existing issues, before opening a dupllcate issue?
Yes
Describe the bug
Multiple CLI commands for bitmagnet cause numerous errors due to lack of working configuration before/instead of giving the help output expected.
To Reproduce

Run postgres/redis in non-default location.
Have a copy of bitmagnet daemon running.
Run bitmagnet config --help
Get:

ERROR   migrations/decorator.go:31      failed to ping database: failed to connect to `host=localhost user=postgres database=bitmagnet`: server error (FATAL: no pg_hba.conf entry for host "<IP_ADDRESS>", user "postgres", database "bitmagnet", no encryption (SQLSTATE 28000))
github.com/bitmagnet-io/bitmagnet/internal/database/migrations.NewDecorator
...
WARN    tmdb_client     tmdb/client.go:40       you are using the default TMDB api key; TMDB requests will be limited to 1 per second; to remove this warning please configure a personal TMDB api key
2023/11/27 10:58:06 Failed to collect metrics data: failed to get queue names: dial tcp [::1]:6379: connect: connection refused
ERROR   fx      fxevent/zap.go:59       OnStart hook failed     {"callee": "github.com/bitmagnet-io/bitmagnet/internal/protocol/dht/server.New.func1()", "caller": "github.com/bitmagnet-io/bitmagnet/internal/boilerplate/cli/hooks.New", "error": "could not open socket: address already in use"}
...
ERROR   fx      fxevent/zap.go:59       start failed, rolling back      {"error": "could not open socket: address already in use"}
...
ERROR   fx      fxevent/zap.go:59       start failed    {"error": "could not open socket: address already in use"}

Expected behavior
Display the help output for that command without any attempts to connect to the databases.
General (please complete the following information):

Bitmagnet version: 0.2.0
OS and version: nixos

Thanks, I'm aware of this - it's a tricky one to fix, due to some inflexibilities in the FX framework, which is geared towards long-running processes with a fixed set of dependencies, not really to a CLI app like this. It's annoying as there's a lot to like about FX and it seems there aren't many other good options for dependency injection in GoLang...
A workaround is probably possible but not trivial. It might be a case of removing the CLI altogether and driving everything through the API and GUI...


Can't run a script without env variables.

I was following this recipe and got    this:
/usr/local/lib/python3.5/dist-packages/gpiozero/devices.py:451: PinFactoryFallback: Falling back from rpigpio: No module named 'RPi'
  'Falling back from %s: %s' % (name, str(e))))
/usr/local/lib/python3.5/dist-packages/gpiozero/devices.py:451: PinFactoryFallback: Falling back from rpio: No module named 'RPIO'
  'Falling back from %s: %s' % (name, str(e))))
/usr/local/lib/python3.5/dist-packages/gpiozero/devices.py:451: PinFactoryFallback: Falling back from pigpio: failed to connect to localhost:8888
  'Falling back from %s: %s' % (name, str(e))))
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Can't connect to pigpio at localhost(8888)

Did you start the pigpio daemon? E.g. sudo pigpiod

Did you specify the correct Pi host/port in the environment
variables PIGPIO_ADDR/PIGPIO_PORT?
E.g. export PIGPIO_ADDR=soft, export PIGPIO_PORT=8888

Did you specify the correct Pi host/port in the
pigpio.pi() function? E.g. pigpio.pi('soft', 8888)
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
/usr/local/lib/python3.5/dist-packages/gpiozero/devices.py:451: PinFactoryFallback: Falling back from native: unable to open /dev/gpiomem or /dev/mem; upgrade your kernel or run as root
  'Falling back from %s: %s' % (name, str(e))))
Traceback (most recent call last):
  File "/home/petrarca/remote_gpio/main.py", line 1, in <module>
    from gpiozero import LED
  File "/usr/local/lib/python3.5/dist-packages/gpiozero/__init__.py", line 22, in <module>
    from .devices import (
  File "/usr/local/lib/python3.5/dist-packages/gpiozero/devices.py", line 480, in <module>
    Device.pin_factory = _default_pin_factory()
  File "/usr/local/lib/python3.5/dist-packages/gpiozero/devices.py", line 452, in _default_pin_factory
    raise BadPinFactory('Unable to load any default pin factory!')
gpiozero.exc.BadPinFactory: Unable to load any default pin factory!

Process finished with exit code 1

So, is there a way to not use environment variables?
My script:
from gpiozero.pins.pigpio import PiGPIOFactory
from time import sleep

remote_factory = PiGPIOFactory(host='<IP_ADDRESS>')
led = LED(17, pin_factory=remote_factory)  # remote pin

while True:
    led.off()
    sleep(1)
    led.on()
    sleep(1)

This will work without environment variables if you have RPi.GPIO installed, as you do on Raspbian desktop by default, or Raspbian Lite (if you installed the apt package). If, however, you install with pip (either system-wide or in a virtualenv), it won't bring in RPi.GPIO, and no default pin factory will be loaded.
So the documentation is correct, assuming you have RPI.GPIO installed as per Raspbian default.
What happens when you do have RPi.GPIO installed is it happily loads RPi.GPIO as the default pin factory, and then you don't use it but instead manually set your LED's pin factory to a PiGPIO one.
What happens when you don't have RPi.GPIO installed is it looks for RPi.GPIO (and fails), looks for RPIO (and fails), looks for pigpio (and finds it, but as no PIGPIO_ADDR is set, uses 'localhost' and if you don't have pigpiod running locally, it fails).
So to use that script you need one of the following:

RPi.GPIO installed
pigpiod running locally
PIGPIO_ADDR environment variable set
GPIOZERO_PIN_FACTORY environment variable set to mock

I installed RPI.GPIO but the problem remained.

When I entering python on my Mac by:
$ python
then I testing if gpiozero works by performing:
>>> import gpiozero
the output it gives me is following:
/Users/maksimdreggevik/anaconda/envs/myenv3.5/lib/python3.5/site-packages/gpiozero/devices.py:451: PinFactoryFallback: Falling back from rpigpio: No module named 'RPi'
  'Falling back from %s: %s' % (name, str(e))))
/Users/maksimdreggevik/anaconda/envs/myenv3.5/lib/python3.5/site-packages/gpiozero/devices.py:451: PinFactoryFallback: Falling back from rpio: No module named 'RPIO'
  'Falling back from %s: %s' % (name, str(e))))
/Users/maksimdreggevik/anaconda/envs/myenv3.5/lib/python3.5/site-packages/gpiozero/devices.py:451: PinFactoryFallback: Falling back from pigpio: Parent module '' not loaded, cannot perform relative import
  'Falling back from %s: %s' % (name, str(e))))
/Users/maksimdreggevik/anaconda/envs/myenv3.5/lib/python3.5/site-packages/gpiozero/devices.py:451: PinFactoryFallback: Falling back from native: unable to open /dev/gpiomem or /dev/mem; upgrade your kernel or run as root
  'Falling back from %s: %s' % (name, str(e))))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/maksimdreggevik/anaconda/envs/myenv3.5/lib/python3.5/site-packages/gpiozero/__init__.py", line 22, in <module>
    from .devices import (
  File "/Users/maksimdreggevik/anaconda/envs/myenv3.5/lib/python3.5/site-packages/gpiozero/devices.py", line 480, in <module>
    Device.pin_factory = _default_pin_factory()
  File "/Users/maksimdreggevik/anaconda/envs/myenv3.5/lib/python3.5/site-packages/gpiozero/devices.py", line 452, in _default_pin_factory
    raise BadPinFactory('Unable to load any default pin factory!')
gpiozero.exc.BadPinFactory: Unable to load any default pin factory!

I followed documentation until 4.3. Environment variables, after that I have no idea what to do.
It tells to :

The simplest way to use devices with remote pins is to set the PIGPIO_ADDR environment variable to the IP address of the desired Raspberry Pi. You must run your Python script or launch your development environment with the environment variable set using the command line. For example, one of the following:
$ PIGPIO_ADDR=<IP_ADDRESS> python3 hello.py
$ PIGPIO_ADDR=<IP_ADDRESS> python3
$ PIGPIO_ADDR=<IP_ADDRESS> ipython3
$ PIGPIO_ADDR=<IP_ADDRESS> idle3 &

On my Client PC aka Mac I've got installed Python3.5 under Anaconda env, so I downloaded the whole gpiozero folder from GitHub into site-packages folder there, since the pip installation rather put it in default Mac python environment.
This is getting pretty frustrating, since there is not much help online after I tried to google nearly everything I could think of.
Any idea how to fix this? And if there is please explain how to like you would to a 90 year old grandpa.
Thanks.

@Kaveshnikov What happens when you type python3 -c "import RPi.GPIO"?

@Herant Can you make sure pigpiod is running on the remote Pi and try GPIOZERO_PIN_FACTORY=pigpio PIGPIO_ADDR=<IP_ADDRESS> pinout ?

@bennuttall I get this traceback:
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/local/lib/python3.5/dist-packages/RPi/GPIO/__init__.py", line 23, in <module>
    from RPi._GPIO import *
RuntimeError: This module can only be run on a Raspberry Pi!

It's obvious, because I type this on my PC.

Ah, ok. So the issue is just that the documentation assumes you're on a Pi (it only works without environment variables if you're on a Pi). I'll amend that for the next release.

@bennuttall  if I understood you correctly, I replaced IP address with ip on my rpi, I also changed to "myenv3.5" which is where I git-hub'ed the install files and installed it. And yeah i did sudo pigpiod on rip first.
Now, I ran this code and the answer I am getting is :
(myenv3.5) Users-MacBook-Pro:V0.3 user1$ GPIOZERO_PIN_FACTORY=pigpio PIGPIO_ADDR=<IP_ADDRESS> pinout 0
usage: pinout [-h] [-r REVISION] [-c] [-m]
pinout: error: unrecognized arguments: 0

@Herant You have a 0 on the end of that command. Try without.

@bennuttall Oh, when u run GPIOZERO_PIN_FACTORY=pigpio PIGPIO_ADDR=<IP_ADDRESS> pinout, I'm getting colored map of gpios. But then I made a new file which I called test.py with following code:
`from gpiozero import LED
from time import sleep
red = LED(17)
while True:
red.on()
sleep(1)
red.off()
sleep(1)`
which suppose to be test code according to documentation. When I run this code by typing:
(myenv3.5) Users-MBP:Desktop user1$ PIGPIO_ADDR=<IP_ADDRESS> python test.py
I'm getting error:
/Users/user1/anaconda/envs/myenv3.5/lib/python3.5/site-packages/gpiozero/devices.py:451: PinFactoryFallback: Falling back from rpigpio: No module named 'RPi._GPIO'   'Falling back from %s: %s' % (name, str(e)))) /Users/user1/anaconda/envs/myenv3.5/lib/python3.5/site-packages/gpiozero/devices.py:451: PinFactoryFallback: Falling back from rpio: No module named 'RPIO.PWM'   'Falling back from %s: %s' % (name, str(e)))) /Users/user1/anaconda/envs/myenv3.5/lib/python3.5/site-packages/gpiozero/devices.py:451: PinFactoryFallback: Falling back from pigpio: Parent module '' not loaded, cannot perform relative import   'Falling back from %s: %s' % (name, str(e)))) /Users/user1/anaconda/envs/myenv3.5/lib/python3.5/site-packages/gpiozero/devices.py:451: PinFactoryFallback: Falling back from native: unable to open /dev/gpiomem or /dev/mem; upgrade your kernel or run as root   'Falling back from %s: %s' % (name, str(e)))) Traceback (most recent call last):   File "test.py", line 1, in <module>     from gpiozero import LED   File "/Users/user1/anaconda/envs/myenv3.5/lib/python3.5/site-packages/gpiozero/__init__.py", line 22, in <module>     from .devices import (   File "/Users/user1/anaconda/envs/myenv3.5/lib/python3.5/site-packages/gpiozero/devices.py", line 480, in <module>     Device.pin_factory = _default_pin_factory()   File "/Users/user1/anaconda/envs/myenv3.5/lib/python3.5/site-packages/gpiozero/devices.py", line 452, in _default_pin_factory     raise BadPinFactory('Unable to load any default pin factory!') gpiozero.exc.BadPinFactory: Unable to load any default pin factory!

Oh, when u run GPIOZERO_PIN_FACTORY=pigpio PIGPIO_ADDR=<IP_ADDRESS> pinout, I'm getting colored map of gpios

That means it's working. The pinout information is actually from your remote Pi. Try the same environment variables when running your Python script:
GPIOZERO_PIN_FACTORY=pigpio PIGPIO_ADDR=<IP_ADDRESS>  python3 test.py

@bennuttall when I'm running GPIOZERO_PIN_FACTORY=pigpio PIGPIO_ADDR=<IP_ADDRESS> python3 test.py I getting this:
(myenv3.5) Users-MBP:Desktop user1$ GPIOZERO_PIN_FACTORY=pigpio PIGPIO_ADDR=<IP_ADDRESS> python test.py
Traceback (most recent call last):
  File "test.py", line 1, in <module>
    from gpiozero import LED
  File "/Users/user1/anaconda/envs/myenv3.5/lib/python3.5/site-packages/gpiozero/__init__.py", line 22, in <module>
    from .devices import (
  File "/Users/user1/anaconda/envs/myenv3.5/lib/python3.5/site-packages/gpiozero/devices.py", line 480, in <module>
    Device.pin_factory = _default_pin_factory()
  File "/Users/user1/anaconda/envs/myenv3.5/lib/python3.5/site-packages/gpiozero/devices.py", line 455, in _default_pin_factory
    return factory.load()()
  File "/Users/user1/anaconda/envs/myenv3.5/lib/python3.5/site-packages/setuptools-27.2.0-py3.5.egg/pkg_resources/__init__.py", line 2258, in load
  File "/Users/user1/anaconda/envs/myenv3.5/lib/python3.5/site-packages/setuptools-27.2.0-py3.5.egg/pkg_resources/__init__.py", line 2264, in resolve
  File "/Users/user1/anaconda/envs/myenv3.5/lib/python3.5/site-packages/gpiozero/pins/pigpio.py", line 11, in <module>
    import pigpio
  File "/Users/user1/anaconda/envs/myenv3.5/lib/python3.5/site-packages/pigpio.py", line 13, in <module>
    from . import SPI
SystemError: Parent module '' not loaded, cannot perform relative import

I tried both with python3 and python, still same output.

@Herant how exactly did you install pigpio? From that stack trace, it's claiming that ".../site-packages/pigpio.py" contains "from . import SPI" but the pigpio client library contains no relative imports.
My guess (given that your method of installing gpiozero was to copy the source into your own site-packages), is that you copied gpiozero/pins/pigpio.py into site-packages too thinking that was a means of installing pigpio, but I'm afraid it isn't. The repo for pigpio contains the pigpio.py client library (you can ignore all the C stuff in there - it's mostly for the pigpiod daemon).
However, assuming my guess is correct, I'd suggest just it's a lot easier to just use conda's built-in pip - it should be much simpler than copying stuff manually.

@waveform80  Well it says that gpiozero is already installed.
(myenv3.5) Users-MBP:V0.4 user1$ pip3 install gpiozero pigpio
Requirement already satisfied: gpiozero in /Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages
Requirement already satisfied: pigpio in /Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages
(myenv3.5) Users-MBP:V0.4 user1$ pip install gpiozero pigpio
Requirement already satisfied: gpiozero in /Users/user1/anaconda/envs/myenv3.5/lib/python3.5/site-packages
Requirement already satisfied: pigpio in /Users/user1/anaconda/envs/myenv3.5/lib/python3.5/site-packages
(myenv3.5) Users-MBP:V0.4 user1$

Alright now it works, all I did was pip uninstall gpiozero pigpio and then pip install gpiozero pigpio. Thanks for helping @bennuttall  & @waveform80

Remotely controlling a Pi from Windows 10 using GPIOZero. Ran in to a many of the above problems. Two Windows User Environmental Variables cleaned it up. First variable was Variable name: PIGPIO_ADDR, Variable value: <IP_ADDRESS>. Not Variable value: <IP_ADDRESS> python. My Pi address is <IP_ADDRESS>. Second was Variable name: GPIOZERO_PIN_FACTORY, Variable value: pigpio. This cured the PinFactoryFallback Falling back stuff. Also set the pin numbering scheme to Broadcom (BCM) pin numbering to be consistent with GPIOZero. Beyond that just the install steps from the GPIOZero documentation. Did find not all of the methods in the Recipes are supported. Example no pulse method for LED.


EnumProcessor.Serialize can throw a null-ref exception when the object to serialize is null.

The EnumProcessor does not properly check the value before requesting its type, resulting in a null-ref exception.

This is resolved in v1.4.


Fixing W3TC issues

Hello @ftownes !
I hope you don't mind if I publicly fix & customize your plugin.
https://github.com/szepeviktor/fix-w3tc/blob/master/README.md
Please comment.
All the best!

I just wanted to say thank you @szepeviktor!
Your mods have been very useful, and I have it installed on all my important sites. How can I buy you a cup of coffee? (read: donate)
Cheers ;-)

Thank you.
https://szepe.net/wp-donate/


 This allows to e.g. develop the plugin outside the GOPATH.
This is a proof of concept and not meant to be merged yet. Everybody who is interested in Go Modules is invited to try it out and give feedback.
Follow up from https://community.mattermost.com/core/pl/a1naj6a61tfa8mdyyhpjfdgw8o.
Open questions
I've opted to place go.mod in the root directory. I would be cleaner to have a separate one for the build tool, but this would increase the work when updating dependencies.
Todo

[x] Fix make gofmt
[x] Move build/manifest in build IMO it's fine in build/manifest
[X] Think about using go mod vendor I don't want this

/check-cla

This is ready for review.

@hanzei, haven't given this a full review yet, but can you speak to removing the vendor directory? I /think/ that's independent of adopting go modules, and might still be best practice -- e.g. mattermost-server will almost certainly retain vendor even after switching. Discussion?

You'r correct, you can use still use vendor with go modules. But what is the advantage of a vendor directory? The mod file pins the required dependencies. And with go modules build into the go command, no additional software is needed. (Which is an advantage vs. dep)

I think these arguments apply equally well to dep, but we still chose to vendor there. Personally, I like the fact that my code will build without needing to make any network requests, or if GitHub is down, or if the source is taken down, etc. I really dislike node_modules for all of these reasons.

I'm not really see the problem. You only have to make network requests after go.mod has changed. But if you pulled the changes in go.mod the next go command will automatically download the new dependencies.
And updating go.mod only happens once a month (at least for server).
The big advantage of not using vendor is that you don't end up with dozen copies of files all your projects.

Yeah, that's fair, at least in this context. Plus, I just realized we only vendored the manifest tool vs. the actual server code! Sounds good to simplify.

The big advantage of not using vendor is that you don't end up with dozen copies of files all your projects.

100% agree with this.
Like dep, you do not have to manage many dependencies with version diff, and it's much faster.

I like the fact that my code will build without needing to make any network requests, or if GitHub is down, or if the source is taken down, etc. I really dislike node_modules for all of these reasons.

I think that's a problem of SaaS, not node_modules of go module. And there are many solutions for module availability: mirroring & proxying (a.k.a artifactory) and vendor directory is one of them.
At the very least, user-centric systems like plugins don't have to suffer from inconvenience for enterprise-class availability.
Even in the case of the server, the go module can still adapt to vendoring, so we can remove unnecessary diffs from our repository and manage them explicitly.

@levb Gently reminder about this PR :wink:

@crspeller Requesting your review, since you worked on Go Modules for the Server. I would like to hear your feedback, but this isn't urgent, if you are busy.


Un-pausing music is incredibly loud

OS:
Debian Testing (Linux, amd64)
Issue Descriptions:
If I pause playback and leave for a while, when I restart, the volume is incredibly loud and maxed out. This only happens with this application---If i use another music app or if I use the web browser, no problem.
Steps to Reproduce:
Simply pause the song and wait an hour or so.

I've never had this issue, however I don't use Debian. Can you pin point what audio is creeping up in volume? Is it at the mixer level or inside the application on the UI?

As the reporter has not responded to the request for additional information this issue will be closed.  If further information can be provided at some point in the future, comment on this issue with the requested information and if appropriate the issue will be reopened.


Adding the Makefile and update the readme

Added the Makefile and updated the README.

I think I am having some issues with the make file

And I dont understand make file like at all so I dont know what to do.

That's fine—those are just normal warnings from the CFLAGS, and I can turn them off if you want. If there were any issues, an error would be displayed, and Conway wouldn't be built. However, that's not the case here, so if you check, you'll see that Conway was built successfully. The Makefile is meant to simplify the build process instead of doing it manually. Also, I noticed that you used 'chmod +x conway'; it's not a script, so there's no need to do that.
CFLAGS = -Wall -Wextra -pedantic -std=c99
-Wall: Enables most common warning messages during compilation. This helps catch potential issues in the code. -Wextra: Enables additional warning messages that are not included with -Wall. These warnings are more specific and can help identify even more potential issues. -pedantic: Enforces strict adherence to the C standard (in this case, C99). It generates warnings for any code that is not strictly compliant with the standard. -std=c99: Specifies that the code should be compiled according to the C99 standard, which is a version of the C programming language standard published in 1999.

Hmmmm, I get it but the output on your screen is different from mine, I get
make: *** [Makefile:15: conway.o] Error 1
and the conway file is not generated.

Check the GCC version.

Sure I'll add it!

Oh, now I understand what's happening. I'm using Void Linux with GCC version 13.2.0, while you are using Arch Linux (EndeavourOS) with GCC version 14.1.1. I will update the Makefile accordingly.
Note: The Makefile is up to date.

Thanks for the contribution!


Add support for asynchronous compilation

Adds Asynchronous schema compilation support.
To reduce the complexity of the implementation, the compile command will only attempt asynchronous complication if only one schema is provided.  When multiple schemas are provided to compile, asynchronous complication is disabled.
validate and test will always use asynchronous compilation by default.  Of course, the application will not attempt to asynchronously request any remote schemas if they're provided by the -r option.

Interesting... If this is added, it should be definitely with additional option, so it's opt-in, otherwise it is a breaking change and I do not think I agree with it - the requirement to resolve URI via network requests is not very common, and in any case non-standard.
So the option to enable it could be --load-schema, and then it would add option loadSchema that gets schemas over HTTP(S) (or any other supported protocol in the URI).
It would work regardless how many schemas are passed


question about output files

Hi,
Is occ.bedgraph a combination of lower and uper_bound.bedgraph?
What is the different between occ.bedgraph vs nucleoatac_signal.bedgraph?
Thanks,
Duy

The upper and lower are estimates of the lower bound and upper bound for the nucleosome occupancy based on the number of reads and the model used.  This doesn't take into account systematic biases though so that should be taken into account when interpreting those tracks.  If the upper and lower bound are far apart though that is an indication that there probably weren't enough reads at that locus to make a very meaningful prediction about the occupancy.
The occ.bedgraph is an estimate of nucleosome occupancy using the mixture of fragment sizes.  It does not provide high-resolution position on information though.  In contrast, the nucleoatac_signal is based on our cross-correlation algorithm and gives higher resolution positioning information.  However, as this signal is dependent on the number of ATAC-seq fragments, which is correlated with the accessibility of the locus (especially the linkers) rather than the nucleosome occupancy, this signal does not provide a very good measure of nucleosome occupancy.
Hope this helps clarify!

Hi Alicia,
Thanks for your answer! I have another question: When you made figure 4d, 6a and 6d in your paper, which information you used (occ or nucleoatac_signal)?

in the biorxiv v1 paper, 4c is made using nucleoatac_signal,  6a is positions of dyad calls relative to CTCF, 6d is using occ.
In general, the occupancy track is easier to compare across loci or samples as it is always between 0 and 1 and shouldn't depend much on read depth (although will potentially be unreliable outside of open chromatin regions due to low signal to noise in those regions).  However, that track is smoother so either the nucleoatac_signal or the positions of dyad calls can be more useful for when one is interested in more precise nucleosome positioning information

Great! Thank you :)


Exclude compilation artifacts from searchable files

IDEs usually provide a fast search feature, which allows you to search for some text in all the source files of your project. In the case of sbt projects, sbt generates a lot of small files in the target/ directory. When we import a project via BSP in an IDE, these compilation artifacts (the content of target/) are included in the scope of a search, making it slow, and showing irrelevant results.
I think the developer experience would be improved if we introduced a concept of paths excluded from the actual sources of the project, that IDEs could leverage.
Currently, importing a project in IntelliJ via the sbt import feature does exclude the target/ directories, but this is not the case when we import the same project via the BSP import feature (so, the sbt import does not suffer from this issue).

Here is a concrete example. I did sbt new scala/scala3.g8, and then imported the project (which uses sbt 1.5.5) in IntelliJ.
By default, IntelliJ imports the project via sbt, and the target/ directory is excluded from the indexed files, as you can see here:

Then, if I re-import the project via BSP, the target/ directory is not anymore excluded (it’s interesting to see that project/target/ is excluded, though…):

As a consequence, when I search something, IntelliJ also searches in the target/ directory:

Logs: bsp-protocol-trace-2021-07-30T11-17-14.log

To me it looks like an issue in sbt or IntelliJ rather than an issue with BSP. Because, the target/ directory should never be included in the buildTarget/sources response, nor in the buildTarget/resources.
[Trace - 10:44:36 AM] Received response 'buildTarget/sources - (3)' in 131ms
Result: {
  "items": [
    {
      "target": {
        "uri": "file:/home/piquerez/scalacenter/hello-world/#hello-world/Compile"
      },
      "sources": [
        {
          "uri": "file:/home/piquerez/scalacenter/hello-world/src/main/scala/",
          "kind": 2,
          "generated": false
        },
        {
          "uri": "file:/home/piquerez/scalacenter/hello-world/src/main/scala-2.13",
          "kind": 2,
          "generated": false
        },
        {
          "uri": "file:/home/piquerez/scalacenter/hello-world/src/main/scala-2",
          "kind": 2,
          "generated": false
        },
        {
          "uri": "file:/home/piquerez/scalacenter/hello-world/src/main/java",
          "kind": 2,
          "generated": false
        }
      ]
    },
{
      "target": {
        "uri": "file:/home/piquerez/scalacenter/hello-world/#hello-world/Test"
      },
      "sources": [
        {
          "uri": "file:/home/piquerez/scalacenter/hello-world/src/test/scala",
          "kind": 2,
          "generated": false
        },
        {
          "uri": "file:/home/piquerez/scalacenter/hello-world/src/test/scala-2.13",
          "kind": 2,
          "generated": false
        },
        {
          "uri": "file:/home/piquerez/scalacenter/hello-world/src/test/scala-2",
          "kind": 2,
          "generated": false
        },
        {
          "uri": "file:/home/piquerez/scalacenter/hello-world/src/test/java",
          "kind": 2,
          "generated": false
        }
      ]
    },
}

I think it’s the responsibility of BSP to inform the IDEs about the files that should be excluded from indexing.
If BSP is used by the IDEs to import the projects, they need a way to know which files should be indexed, and which files should be excluded. I don’t see how an IDE could guess which files should be excluded since it depends of the underlying build tool, and BSP’s role is precisely to be the layer between IDEs and build tools.
For instance, we probably want README.md to be indexed, but we clearly don’t want any file from target/ (except for managed sources) to be indexed.

Actually it seems that IntelliJ exclude the classes and test-classes from the target directory.

It knows that because the classDirectory is in the ScalacOptionsItems:
{
      "target": {
        "uri": "file:/home/piquerez/scalacenter/hello-world/#root/Test"
      },
      "options": [
        "-Xplugin:/home/piquerez/.cache/coursier/v1/https/repo1.maven.org/maven2/org/scalameta/semanticdb-scalac_2.13.3/4.4.24/semanticdb-scalac_2.13.3-4.4.24.jar",
        "-P:semanticdb:sourceroot:/home/piquerez/scalacenter/hello-world",
        "-P:semanticdb:targetroot:/home/piquerez/scalacenter/hello-world/target/scala-2.13/meta",
        "-Yrangepos",
        "-P:semanticdb:synthetics:on",
        "-P:semanticdb:failures:warning",
        "-P:semanticdb:targetroot:/home/piquerez/scalacenter/hello-world/target/scala-2.13/test-meta"
      ],
      "classpath": [
        "file:/home/piquerez/scalacenter/hello-world/target/scala-2.13/classes/",
        "file:/home/piquerez/scalacenter/hello-world/target/scala-2.13/test-classes/",
        "file:/home/piquerez/.cache/coursier/v1/https/repo1.maven.org/maven2/org/scala-lang/scala-library/2.13.3/scala-library-2.13.3.jar"
      ],
      "classDirectory": "file:/home/piquerez/scalacenter/hello-world/target/scala-2.13/test-classes/"
    }

Similarly we could have an outputDirectory in the BuildTarget that would be excluded form indexing.

I think it would be nice if BSP had a notion of declaring what directories should be excluded from the IDE. I recall that the Pants IntelliJ plugin works around this limitation by manually excluding Bloop directories when using Pants via BSP. It would be more natural if the protocol had a notion of "exclude directories", which can cover more broad directories like target/ instead of only excluding the classes directories.

This PR will fix this issue for the protocol itself: https://github.com/build-server-protocol/build-server-protocol/pull/269. Then, this sbt PR https://github.com/sbt/sbt/pull/6985 and intellij-scala PR https://github.com/JetBrains/intellij-scala/pull/627 will fix the problem for IntelliJ IDEA users.


Allow formulas in spoiler heading

We need formulas in spoiler headings for subjects like math, chemistry and physics. At the moment it's only possible to write text in the heading.

Is this a frontend or edtr issue?

Oh, I am sorry, I missed that it needs to be implemented in edtr.io first. Thus I have transfered it back to serlo.org.

@yolo-bird what do you think? It's rather a small bug fix than an interesting feature for authors.

It's not a small bug fix. I guess I might take me at least ~1 week to implement it in edtr.io. Thus I am with @Entkenntnis that you need to discuss when it shall be included on the software roadmap.

@kulla Sorry. Bad wording. I never meant that the issue is a "small bug fix" for you or other software developers. I meant that it is rather unimportant for authors. It's necessary to include the feature but it's not like every author is keen on getting updates about it. Most of the authors probably don't even know that the problem exists. So maybe we don't need to put it on our trelloboard. That was my point.

Most of the authors probably don't even know that the problem exists. So maybe we don't need to put it on our trelloboard.

My opinion: When it is not important enough to put it on the Trelloboard, than we should not implement this feature...

Most of the authors probably don't even know that the problem exists. So maybe we don't need to put it on our trelloboard.

My opinion: When it is not important enough to put it on the Trelloboard, than we should not implement this feature...

Most of the authors probably don't even know that the problem exists. So maybe we don't need to put it on our trelloboard.

My opinion: When it is not important enough to put it on the Trelloboard, than we should not implement this feature...

In my opinion it's still important even if many authors won't need it. For me it's a basic feature. We have enough articles where formulas are used in spoiler headings which we can't convert properly and we will have many more use cases in the future --> we need it.

I would like to clearify that a "no" by the dev team does not mean that we think a feature is not useful or not important.
We say "no" mainly because we are restraint by our capacities. Which means that we have to say "no" even to feature that are actually important - that's not easy to do, also for us. And it's nothing that we are doing lightly.
That's the reason why I would prefer discussing feature requests in the trelloboard: It makes clear that features have to compete against each other and often, less important features will lose.
But we are also an open-source project, which means that (at least in theory), community software developers can add features that the main team can't focus on right now.

Moved to Google Doc https://docs.google.com/document/d/1rSkFo2JtsSwHHsbosQcgAN4EzeePXLnqi_eCFpUM3u4/edit#


Creating Shared Contact in G Suite

Dear GAM
Apologies if this is not posted in the correct area..
I am trying to find a way to create a Shared Contact on G Suite using GAM. There is no documentation in the Wiki and can't seem to find anything that details this on the Github page. Am I being thick? Can this be done?
Regards
Adam

Checkout ContactBook.App, that allows you to share organisational contacts across your team members using your G Suite account.


Unsimulated PhysicalBone3D in skeleton children cannot be detected by intersect_ray

Tested versions

Godot v4.3.dev (04dd299cb), Godot v4.3.dev (6c5792806) have this issue
Godot v4.3.dev (fd61a42e0), Godot v4.2  is no such issue

This issue is due to the commit:
04dd299cbac614c0ff2306b8d3cD60dcd86abd8e
@TokageItLab
System information
windows 11
Issue description
In previous versions(fd61a42e0), I can obtain ray_result through this code
extends Node3D

const RAY_LENGTH = 1000.0
var ray_result = null
func check_ray():
	var space_state = get_world_3d().direct_space_state
	var cam = %Camera3D
	var mousepos = get_viewport().get_mouse_position()

	var origin = cam.project_ray_origin(mousepos)
	var end = origin + cam.project_ray_normal(mousepos) * RAY_LENGTH
	var query = PhysicsRayQueryParameters3D.create(origin, end)
	query.collide_with_areas = true
	var result = space_state.intersect_ray(query)
	ray_result = result
	printt("ray_result",ray_result)

func _physics_process(delta):
	check_ray()

But in the version(04dd299cb), I couldn't get the correct result
Steps to reproduce

this is correct video(fd61a42e0):

https://github.com/godotengine/godot/assets/153103332/671aaf1b-9440-465f-9712-d5cb587a8ae9

this is incorrect video(04dd299cb):

https://github.com/godotengine/godot/assets/153103332/8ddf3ddd-a465-4dac-a782-12015a0602a3
node tree is:

Note that if the node tree is adjusted to

regardless of the version, ray_result can be obtained correctly
The issue should be due to the relevant modifications in Skeleton3D
Minimal reproduction project (MRP)
TestIntersectRay.zip

@TokageItLab Can you look into this?

After the start of the simulation by physical_bones_start_simulation, it seems to be functioning correctly.
I think this issue is caused by the fact that the simulation is explicitly excluded from PhysicsServer3D when it is not running, so it is not detectable from there.
However, since I don't remember changing the registration process of the PhysicsServer3D, I am rather wondering why the past PhysicalBone is still detectable by PhysicsServer3D even though it is not running a simulation. There are performance concerns with having it enabled all the time.

Maybe fixed by #92279

Maybe fixed by #92279

Doesn't seem to be, the MRP is still reproducible in latest master (a6ef250f3eada5ba1f9cc3c06663b9f76c7c2279).


Push up to 345268951

Is this still valid after this PR?
https://github.com/abseil/abseil-py/blob/cd53de736e73246d118848d2ac1e927f3c2cbe95/absl/BUILD#L3

@bhack you are right, these should also be removed. thanks!

Do we need to export It from a BUILD file in the root directory?

Are you having issues without it? I think we could provide one if there is need.

Currently on an upgrade from 0.10.0 to 0.14.0 it is failing on one rule on TF.
If you see the CI log on win it Is looking for LICENSE in absl subdir but the file is missing:
https://github.com/tensorflow/tensorflow/pull/52173

Ah got it. I'll add the top-level BUILD file and export the LICENSE file. Then
https://github.com/tensorflow/tensorflow/blob/5d070584cb31d4e50bd5d361621c3ff414acdb6e/tensorflow/tools/pip_package/BUILD#L263-L267
Should become "@absl_py//:LICENSE",

Thanks


Error CS8701: Target runtime doesn't support default interface implementation.

This tutorial uses the term "library" repeatedly yet the sample repo on Github uses a Console App. This is a problem because as far as I can tell, the default interface implementation feature does not work with class libraries. I get error CS8701: Target runtime doesn't support default interface implementation when I try to use this feature in a class library. I am using .NET Core 3.0 Preview 7 on Windows and macOS. Since Microsoft has said that Preview 7 has a Go Live license, this worries me. Please update your tutorial to show that the interface can be in a class library as would be the case in the real world. Thank you.

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

ID: c790425e-da4e-9a75-6a11-f72109ce8d6a
Version Independent ID: 09298e41-8f5a-c3c3-a849-8de67f8efba1
Content: Safely update interfaces using default interface members in C#
Content Source: docs/csharp/tutorials/default-interface-members-versions.md
Product: dotnet-csharp
GitHub Login: @BillWagner
Microsoft Alias: wiwagn

Can you share your csproj file?

I have two .csproj files because I want the interface with a default implementation of one of its method in a class library (created with dotnet new classlib) and it will be used in a console app (created with dotnet new console).
Here is the .csproj file for the class library:

netstandard2.0
preview

Note: I also tried netstandard2.1 and it gives the same compile error.
Here's the class:
using static System.Console;
namespace Packt.Shared
{
public interface IPlayable
{
void Play();
void Pause();

//void Stop();

// you cannot use default interface implementations in a class library (yet)
void Stop()
{
  WriteLine("Default implementation of Stop.");
}

}
}
In Visual Studio Code's Terminal:
$ dotnet --version
3.0.100-preview7-012821
$ dotnet build
Microsoft (R) Build Engine version 16.3.0-preview-19329-01+d31fdbf01 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.
Restore completed in 69.63 ms for /Users/markjprice/Code/Chapter06/PacktLibrary/PacktLibrary.csproj.
You are using a preview version of .NET Core. See: https://aka.ms/dotnet-core-preview
IPlayable.cs(14,10): error CS8701: Target runtime doesn't support default interface implementation. [/Users/markjprice/Code/Chapter06/PacktLibrary/PacktLibrary.csproj]
Build FAILED.
IPlayable.cs(14,10): error CS8701: Target runtime doesn't support default interface implementation. [/Users/markjprice/Code/Chapter06/PacktLibrary/PacktLibrary.csproj]
0 Warning(s)
1 Error(s)
Time Elapsed 00:00:03.37
Here is the .csproj for the console app, but since I cannot even compile the class library I don't think it matters:

Exe
netcoreapp3.0
preview

If it is not possible to use default interface implementations in .NET Standard 2.0 or 2.1 class libraries then this tutorial should say so, and stop using the term "library".

Ahh yes. .NET Standard 2.0 doesn't support them either since that was locked down before they were introduced. You need to use .NET Standard 2.1
I do agree though, the tutorial should specify this requirement.
Thanks for filing the issue.

No, I tried netstandard2.1 and that gives the same error as netstandard2.0.

I just tried on preview 6 and 7 and sure enough, you're right. net standard 2.1 isn't working with that feature. I'll send an email asking about why this is so. I did get it to work in preview 8 (unreleased) so it's probably already fixed and only related to targeting standard 2.1. I'll send an email around just to double check.
However, I do think this tutorial should be clearer about what is required for targeting.

That's great news that it works with Preview 8! It worried me that it didn't work with netstandard2.0 or 2.1 when Preview 7 was supposed to be Go Live. At least I now know that in a few weeks when Preview 8 is released it'll work. :)

OK confirmed. 2.1 never supported the default interface members of c#8 and it's coming. it may not ship in preview 8, i can't really say that.
Either way, we should note on this article the requirements 😄

Thank you for your diligent work on this issue, Thraka. Microsoft's continuing openness really helps build trust in your platforms to everyone's benefit.

Leaving this open so we can track getting that updated (whenever it comes to be)

I think we're good to close.

Folks, the doc link is resulting in 404: https://learn.microsoft.com/en-us/dotnet/csharp/misc/sorry-we-don-t-have-specifics-on-this-csharp-error?f1url=%3FappId%3Droslyn%26k%3Dk(CS8701)


Release binary of v0.11.0-rc1 for macOS is 404

@michelleN Hi, thank you for maintaining this great project 👍
The link to the macOS binary is 404 due to a typo in the URL.
You will probably want to fix v0.11-0 to v0.11.0.
BEFORE: https://azuredraft.blob.core.windows.net/draft/draft-v0.11-0-rc1-darwin-amd64.tar.gz
AFTER: https://azuredraft.blob.core.windows.net/draft/draft-v0.11.0-rc1-darwin-amd64.tar.gz

Hey! Thanks for the heads up. I noticed this earlier today and tried to fix it but made the typo. Thanks for pointing it out!


Safari 16.4 does fully support Screen Wake Lock

Screen Wake Lock was originally marked "partial" support in this PR.
There are still WPT test failures, but those failures are not because our implementation is lacking. We have full support.
The tests are failing for reasons unrelated to Screen Wake Lock, due to a lack of a WebDriver set permission command, which the testing framework uses. WPT is not the main test suite for Safari. These tests are written by other browsers for other browsers, and are often structured in ways that do not work universally.

Thanks!


fix: stuck after restart when min filtered block is previous block of a check point

Changes

In the following code:
https://github.com/nervosnetwork/ckb-light-client/blob/38aa9b200be7c6b96ded79bf3d2f84b157f2d230/src/protocols/light_client/peers.rs#L1606-L1608
min_filtered_block_number is the last filtered block which has been synchronized.
should_cached_check_point_index is the index of the check point, which contains the next filtered block which will be synchronized.
So, the it should be fixed with following patch:
  pub(crate) fn update_min_filtered_block_number(&self, min_filtered_block_number: BlockNumber) {
      let should_cached_check_point_index =
-         self.calc_best_check_point_index_not_greater_than(min_filtered_block_number);
+         self.calc_best_check_point_index_not_greater_than(min_filtered_block_number + 1);

See the following code:
https://github.com/nervosnetwork/ckb-light-client/blob/38aa9b200be7c6b96ded79bf3d2f84b157f2d230/src/protocols/light_client/peers.rs#L1141-L1143
At start, the check point index and the block number of it is 0, 0.
The following check point index and the block number of it are 1, 2000, 2, 4000 and son on.
When the client want to synchronizes the block 2000，the last check point should be 0.
When the client want to synchronizes the block 2001 to 4000，the last check point should be 1.
So, when client synchronizes the filtered block number, the check point should be:
-         (number / self.check_point_interval) as u32
+         (number.saturating_sub(1) / self.check_point_interval) as u32

Changed some naming to make the names are more appropriate.

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (38aa9b2) 71.05% compared to head (e7499f3) 71.09%.

Additional details and impacted files
@@             Coverage Diff             @@
##           develop     #162      +/-   ##
===========================================
+ Coverage    71.05%   71.09%   +0.03%
===========================================
  Files           25       25
  Lines         6420     6428       +8
===========================================
+ Hits          4562     4570       +8
  Misses        1858     1858

Flag
Coverage Δ

unittests
71.09% <100.00%> (+0.03%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


fix: unnecessary market_matching_pool in context

CancelOrderPostMarketLock context contained unnecessary market_matching_pool.


Optimize download for sapling-spend.params and sapling-output.params

Is your feature request related to a problem? Please describe.
The SDK lazily downloads sapling-spend.params and sapling-output.params when the user initiates shielded spends.  This has two problems:

It can make first spend slow as it needs to download ~50mb (and potentially unreliable if z.cash is down but lightwalletd is up)
It isn't necessary for non-sapling spend (e.g. orchard)

Describe the solution you'd like

Download the files when sapling transactions are discovered, so that first spend of these funds is faster and more reliable
Don't download these files during spend if the transaction isn't sapling

I think the easiest way to do this is to check for a unverified sapling balance after finishing syncing. If so, the parameters should be ready when the funds are confirmed.
there are some nuances to this for example when user attempts to send sapling funds while downloading the parameters. The fact that the download is started the moment unverified sapling funds are detected should avoid this scenario. but  it should be considered possible.

Thanks @pacu, this way it's possible, we need to play a bit with the code to be able to trigger the sapling parameters fetch from blocks sync mechanisms. And yes, a possible send action before the fetch is finished needs to wait for it.

Currently, all transactions received by the SDK will be Sapling transactions, either because they are received to a Sapling receiver, or are received to a transparent receiver and need to be shielded to Sapling. So for now you can just mock out the "is Sapling" check.

Thank you @str4d, we've decided to postpone this issue so we don't introduce any mocked functionality to the code base, as it's working fine now and this enhancement can therefore, wait for the orchard implementation.


Improve handling of WebSocket connection closing and subscription completion

We need to do some work whenever a client websocket is closed.
We tried to use afterConnectionClosed(WebSocketSession, CloseStatus) inside GraphQlWebSocketHandler, but it only works if disconnected though messages, not if the TCP connection is closed.
We were able to do it wrapping GraphQlWebSocketHandler:
	@Bean
	public GraphQlWebSocketHandler graphQlWebSocketHandler(WebGraphQlHandler webGraphQlHandler,
			GraphQlProperties properties, ServerCodecConfigurer configurer) {
		return new MyHandler(webGraphQlHandler, configurer,
				properties.getWebsocket().getConnectionInitTimeout());
	}

And then adding this:
	class MyHandler extends GraphQlWebSocketHandler {

		public MyHandler(WebGraphQlHandler graphQlHandler, ServerCodecConfigurer configurer,
				Duration connectionInitTimeout) {
			super(graphQlHandler, configurer, connectionInitTimeout);
		}

		@Override
		public Mono<Void> handle(WebSocketSession session) {
			log.info("Handle websocket session");
			return super.handle(session).then().doFinally(v -> {
				log.info("Finished websocket session");
				//Some work
			});
		}
	}

This is ok, just would be great if added to documentation.
Still, we have the problem of identifying the connection. Here we have websocket connection id and handshakeInfo, but nothing about content (that's ok, this is not the place).
What we did was to add a query param to /subscription, so we can have that information inside handshakeInfo in MyHandler:
String clientId = util.getQueryParam(session.getHandshakeInfo().getUri().getQuery()).get("clientId");

That way, we can correlate session closed with a specific client. Still, this is a very unclean trick.
I think the right place should be on connection_init payload and I've seen WebSocketInterceptor that can read this information. But there is no way to pass that information to previous custom handler. I've also checked handleConnectionCompletion method, but it's not triggered when TCP connection is suddenly closed.
Would it be possible to create a handler that is also called whenever the websocket connection is closed? We would also need to have some context information within this method (connection_init payload at least).
Another solution could be to add websocket session id inside WebInput and also pass WebInput to handleConnectionInitialization in WebsocketInterceptor. This way we could correlate payload information with session Id, which is accesible inside GraphQlWebSocketHandler.
It's a little bit tricky. I hope it's understandable.

We could add WebSocketInterceptor#handleConnectionClosed to be invoked when the connection is closed and have the payload from connection_init passed into it. In addition, I see that we have the subscription id on a Complete message but are not passing that into WebSocketInterceptor#handleConnectionCompleted and will correct that one too.
As an aside, I'm not sure how your comment about afterConnectionClosed fits in since that's on the WebMVC side but you're talking about the WebFlux handler. It doesn't really matter since the proposed enhancements will be addressed on both sides, but I was just puzzled by it.

As an aside, I'm not sure how your comment about afterConnectionClosed fits in since that's on the WebMVC side but you're talking about the WebFlux handler. It doesn't really matter since the proposed enhancements will be addressed on both sides, but I was just puzzled by it.

I think I confused this and I was referring to handleWebSocketCompletion inside WebGraphQlHandler. Sorry for the mistake, it was a hard issue to explain for me :stuck_out_tongue:
Thank you for accepting this enhancement!

WebSocketInterceptor now has a new handleConnectionClosed method with the statusCode and the "connection_init" payload. I've also added the WebSocket session id to all handle methods.


[BUG] Build Failed Vercel

Environment
Cloud Service (Static)
System
Edge 122
Version
2.1.2
Describe the problem
Hi! Trying to deploy dashy to Vercel and during the process an error occurs, log:
ALL LOG:
[10:37:11.977] Running build in Washington, D.C., USA (East) – iad1
[10:37:12.119] Cloning github.com/frayglsm/dashy (Branch: master, Commit: 3c5531d)
[10:37:12.597] Previous build cache not available
[10:37:14.515] Cloning completed: 2.396s
[10:37:14.993] Running "vercel build"
[10:37:15.465] Vercel CLI 33.5.3
[10:37:16.166] Warning: Detected "engines": { "node": ">=16.0.0 <21.6.2" } in your package.json that will automatically upgrade when a new major Node.js Version is released. Learn More: http://vercel.link/node-version
[10:37:16.170] Installing dependencies...
[10:37:16.493] yarn install v1.22.17
[10:37:16.930] [1/5] Validating package.json...
[10:37:16.934] [2/5] Resolving packages...
[10:37:17.471] [3/5] Fetching packages...
[10:37:34.637] error<EMAIL_ADDRESS>The engine "node" is incompatible with this module. Expected version "8 || 10 || 12 || 14 || 16 || 17". Got "18.18.2"
[10:37:34.650] error Found incompatible module.
[10:37:34.650] info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
[10:37:34.678] Error: Command "yarn install" exited with 1
[10:37:35.298]
ERRORS:
[10:37:11.977] Running build in Washington, D.C., USA (East) – iad1
[10:37:12.119] Cloning github.com/frayglsm/dashy (Branch: master, Commit: 3c5531d)
[10:37:12.597] Previous build cache not available
[10:37:14.515] Cloning completed: 2.396s
[10:37:14.993] Running "vercel build"
[10:37:15.465] Vercel CLI 33.5.3
[10:37:16.166] Warning: Detected "engines": { "node": ">=16.0.0 <21.6.2" } in your package.json that will automatically upgrade when a new major Node.js Version is released. Learn More: http://vercel.link/node-version
[10:37:16.170] Installing dependencies...
[10:37:16.493] yarn install v1.22.17
[10:37:16.930] [1/5] Validating package.json...
[10:37:16.934] [2/5] Resolving packages...
[10:37:17.471] [3/5] Fetching packages...
[10:37:34.637] error<EMAIL_ADDRESS>The engine "node" is incompatible with this module. Expected version "8 || 10 || 12 || 14 || 16 || 17". Got "18.18.2"
[10:37:34.650] error Found incompatible module.
[10:37:34.650] info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
[10:37:34.678] Error: Command "yarn install" exited with 1
[10:37:35.298]
Warnings (1):
[10:37:11.977] Running build in Washington, D.C., USA (East) – iad1
[10:37:12.119] Cloning github.com/frayglsm/dashy (Branch: master, Commit: 3c5531d)
[10:37:12.597] Previous build cache not available
[10:37:14.515] Cloning completed: 2.396s
[10:37:14.993] Running "vercel build"
[10:37:15.465] Vercel CLI 33.5.3
[10:37:16.166] Warning: Detected "engines": { "node": ">=16.0.0 <21.6.2" } in your package.json that will automatically upgrade when a new major Node.js Version is released. Learn More: http://vercel.link/node-version
[10:37:16.170] Installing dependencies...
[10:37:16.493] yarn install v1.22.17
[10:37:16.930] [1/5] Validating package.json...
[10:37:16.934] [2/5] Resolving packages...
[10:37:17.471] [3/5] Fetching packages...
[10:37:34.637] error<EMAIL_ADDRESS>The engine "node" is incompatible with this module. Expected version "8 || 10 || 12 || 14 || 16 || 17". Got "18.18.2"
[10:37:34.650] error Found incompatible module.
[10:37:34.650] info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
[10:37:34.678] Error: Command "yarn install" exited with 1
[10:37:35.298]
Additional info
No response
Please tick the boxes

[X] You have explained the issue clearly, and included all relevant info
[X] You are using a supported version of Dashy
[X] You've checked that this issue hasn't already been raised
[X] You've checked the docs and troubleshooting guide
[X] You agree to the code of conduct

I got it working with the following Vercel settings:
build command: NODE_OPTIONS=--openssl-legacy-provider yarn build install command: yarn install --ignore-engines

@Lissy93 Vercel Deploy seems to still fail, see this PR, when GH-Actions tried to deploy to vercel it also failed, however I cannot see what the error there is.

This also seems to break the build from source like mentioned here: #1495
I guess this is mostly because of #1492
For a temp fix use node 17 LTS

Got it working as well with those commands.

The Vercel build issue on the repo has now also been fixed


Enable App Analytics for test spans

What does this PR do?
Enable App Analytics for test spans.
Additional Notes

Review checklist
Please check relevant items below:

[ ] This PR includes all newly recorded cassettes for any modified tests.

[ ] This PR does not rely on API client schema changes.

[ ] The CI should be fully passing.

[ ] Or, this PR relies on API schema changes and this is a Draft PR to include tests for that new functionality.

Note: CI shouldn't be run on this Draft PR, as its expected to fail without the corresponding schema changes.

/azp run

/azp run


Fix HACS download

The filename was wrong, so HACS wouldn't download.

Please merge this asap. HACS integration is broken without this.

Great stuff! Thanks for doing that @wuwentao.


Fix name overflow for org names

What does this pull request aim to achieve? 💯
Fix for overflow of org names that appear in the createPost modal.
Please be concise and link any related issue(s):
fixes #1120

[ ] I have checked that no one else is working on similar changes.
[ ] I have read the latest README and understand the development workflow.
[ ] The name of this branch is: feature/<branch_name> (need to have cloned the repo not forked).
[ ] This branch is rebased/merged with the latest master.
[ ] There are no merge conflicts.
[ ] There are no console warnings and errors.
[ ] On the right hand side of this PR, I have linked the appropriate issue(s) under "Issues" and added a project progress under "Projects".

@vikjoshi @ppagarawal I've implemented ellispis to handle overflow, since I didnt find anything in Zeppelin related, let me know if we want to apply limitations to the org name count instead.

Thanks @nr431207 ! We do not have a character limit on org names anywhere else in the application so using ellipses seems right to me


[Model] Support multiple images for qwen-vl

This PR finishes exposing multi-image support for Qwen-VL (not Qwen2) as follow-up to https://github.com/vllm-project/vllm/pull/8029.
Multi-image offline inference example (.generate)
from vllm import LLM, SamplingParams
from vllm.multimodal.utils import fetch_image

question = "Can you compare these images?"
image_urls = [
    "https://upload.wikimedia.org/wikipedia/commons/d/da/2015_Kaczka_krzy%C5%BCowka_w_wodzie_%28samiec%29.jpg",
    "https://upload.wikimedia.org/wikipedia/commons/7/77/002_The_lion_king_Snyggve_in_the_Serengeti_National_Park_Photo_by_Giles_Laurent.jpg",
]

llm = LLM(
    model="Qwen/Qwen-VL-Chat",
    trust_remote_code=True,
    limit_mm_per_prompt={"image": len(image_urls)},
    dtype="half"
)

get_img_prompt = lambda img_num: f"Picture {img_num}: \n"
placeholders = "".join(get_img_prompt(i) for i, _ in enumerate(image_urls, start=1))
prompt = f"<|im_start|>user\n{placeholders}{question}\n<|im_end|>\n<|im_start|>assistant\n"

sampling_params = SamplingParams(temperature=0.2, max_tokens=64)

outputs = llm.generate({
        "prompt": prompt,
        "multi_modal_data": {
            "image": [fetch_image(url) for url in image_urls]
        },
    },
    sampling_params=sampling_params
)

for o in outputs:
    generated_text = o.outputs[0].text
    print(generated_text)

The two images shown are different. The first image is of a male mallard duck swimming in a body of water, while the second image is of a male lion resting in the tall grass. The two images are unrelated and cannot be compared.<|im_end|>

Chat example:
Image numbering is already handled properly in the chat utils, so no extra changes needed there.
Server:
python -m vllm.entrypoints.openai.api_server \
    --device cuda \
    --model Qwen/Qwen-VL-Chat \
    --api-key token-abc123 \
    --chat-template examples/template_chatml.jinja \
    --tokenizer Qwen/Qwen-VL-Chat \
    --dtype=half \
    --limit-mm-per-prompt image=2 \
    --trust-remote-code &

Client:
from openai import OpenAI

client = OpenAI(base_url="http://localhost:8000/v1", api_key="token-abc123")

completion = client.chat.completions.create(
  model="Qwen/Qwen-VL-Chat",
  messages=[
    {
        "role": "user", "content": [
          {"type": "image_url", "image_url": {"url": "https://upload.wikimedia.org/wikipedia/commons/d/da/2015_Kaczka_krzy%C5%BCowka_w_wodzie_%28samiec%29.jpg"}},
          {"type": "image_url", "image_url": {"url": "https://upload.wikimedia.org/wikipedia/commons/7/77/002_The_lion_king_Snyggve_in_the_Serengeti_National_Park_Photo_by_Giles_Laurent.jpg"}},
          {"type": "text", "text": "Can you compare these images?"},
        ]
    }
  ]
)

print(completion.choices[0].message)

ChatCompletionMessage(content='The images shown are different and cannot be compared. Image 1 is a duck swimming in water, and Image 2 is a lion lying in the grass. They are completely different in both content and subject.<|im_end|>\n', refusal=None, role='assistant', function_call=None, tool_calls=[])

BEFORE SUBMITTING, PLEASE READ THE CHECKLIST BELOW AND FILL IN THE DESCRIPTION ABOVE

 PR Checklist (Click to Expand)
Thank you for your contribution to vLLM! Before submitting the pull request, please ensure the PR meets the following criteria. This helps vLLM maintain the code quality and improve the efficiency of the review process.
PR Title and Classification
Only specific types of PRs will be reviewed. The PR title is prefixed appropriately to indicate the type of change. Please use one of the following:

[Bugfix] for bug fixes.
[CI/Build] for build or continuous integration improvements.
[Doc] for documentation fixes and improvements.
[Model] for adding a new model or improving an existing model. Model name should appear in the title.
[Frontend] For changes on the vLLM frontend (e.g., OpenAI API server, LLM class, etc.)
[Kernel] for changes affecting CUDA kernels or other compute kernels.
[Core] for changes in the core vLLM logic (e.g., LLMEngine, AsyncLLMEngine, Scheduler, etc.)
[Hardware][Vendor] for hardware-specific changes. Vendor name should appear in the prefix (e.g., [Hardware][AMD]).
[Misc] for PRs that do not fit the above categories. Please use this sparingly.

Note: If the PR spans more than one category, please include all relevant prefixes.
Code Quality
The PR need to meet the following code quality standards:

We adhere to Google Python style guide and Google C++ style guide.
Pass all linter checks. Please use format.sh to format your code.
The code need to be well-documented to ensure future contributors can easily understand the code.
Include sufficient tests to ensure the project to stay correct and robust. This includes both unit tests and integration tests.
Please add documentation to docs/source/ if the PR modifies the user-facing behaviors of vLLM. It helps vLLM user understand and utilize the new features or changes.

Notes for Large Changes
Please keep the changes as concise as possible. For major architectural changes (>500 LOC excluding kernel/data/config/test), we would expect a GitHub issue (RFC) discussing the technical design and justification. Otherwise, we will tag it with rfc-required and might not go through the PR.
What to Expect for the Reviews
The goal of the vLLM team is to be a transparent reviewing machine. We would like to make the review process transparent and efficient and make sure no contributor feel confused or frustrated. However, the vLLM team is small, so we need to prioritize some PRs over others. Here is what you can expect from the review process:

 After the PR is submitted, the PR will be assigned to a reviewer. Every reviewer will pick up the PRs based on their expertise and availability.
 After the PR is assigned, the reviewer will provide status update every 2-3 days. If the PR is not reviewed within 7 days, please feel free to ping the reviewer or the vLLM team.
 After the review, the reviewer will put an  action-required label on the PR if there are changes required. The contributor should address the comments and ping the reviewer to re-review the PR.
 Please respond to all comments within a reasonable time frame. If a comment isn't clear or you disagree with a suggestion, feel free to ask for clarification or discuss the suggestion.

Thank You
 Finally, thank you for taking the time to read these guidelines and for your interest in contributing to vLLM. Your contributions make vLLM a great tool for everyone!

FYI @DarkLight1337 since you reviewed the main PR for qwen-vl! 🙂

Could you add a test to verify the behavior of this model?
After #8201 is merged, can you update the example script for multi-image input to include this model as well?

Yup, definitely! I had recently started working on some stuff around the image processor to allow kwargs to be passed through as overrides for stuff pulled from the HF config - but before that, I was planning to open a PR to add some common utils for building an InputContext and some dummy data for different multimodal models to test correctness of custom input mappers / processors. I think it would be nice to have fast tests that only test the preprocessing correctness that can run without loading the full models.
I had started writing those tests for this model already - do you have any thoughts on adding those here to test this PR? Happy to do that and then submit a follow-up refactoring common stuff out + adding stuff for other models, or if you think it would be better, just adding an end-to-end test here for now and adding preprocessing tests in a separate PR

I had started writing those tests for this model already - do you have any thoughts on adding those here to test this PR?

Sure!

Happy to do that and then submit a follow-up refactoring common stuff out + adding some tests for other models, or if you think it would be better, just adding an end-to-end test here for now and adding preprocessing tests in a separate PR

I'm currently working on #7820, perhaps it would be best to refactor the tests after that.

Perfect, I'll add them to the test file to this model for now, and wait until after that's merged before making stuff common and adding similar tests for some other models 😄

Can we have an end-to-end correctness test for multi-image input just like the other models?

Can you merge main into this branch to fix the CI failure?

No problem, thanks a lot for the quick reviews! Just did 🙂

Sorry I forgot about this, Qwen2-VL has just been released so you have to update the examples file.

No worries at all, that's great news! Just rebased 😄


Shift the thread id into the random part

Allow the bits of the thread id part to precede the random bits.

Fixed.

@vladmihalcea Hi Vlad, what was the reasoning here?  To make thread id collisions less likely?  In which scenarios?  Or was this change because of some other problem you saw?  Curious, if you could explain the problem itself and the reasons for this change.  Thanks!

The reason was to avoid collisions even more since each thread identifier is unique.

Yes, that commit removes the thread contention on the generate method. As for the test case, in the original version, there were no conflicts since the generate method was allowing a single thread to execute.
Since I removed the synchronized, I wanted to check the collisions while using multiple threads when the generator takes the threadId into consideration. As long as you set the threadId, there should not be collisions even without the previous  synchronized.

Awesome thanks for answering!
We're using your package in https://db2rest.org which might interest you and will publish a blog post on TSID generation.
Thanks bye for now!

Thanks. That website you linked in your comment does not work for me.

sorry, updated the link... .com not .org

Thanks. I don't use GitHub sponsor, but I have this Coaching Basic package that could be used for the same purpose.

Thanks, well, I was thinking a "few" dollars, not quite that "many" per month. :-)

@thadguidry You can cancel the subscription any time and pay as much as you want. For instance, if you wanted to donate $4 a month for 12 years, then it's the same as buying one month of this Basic Coaching and cancel your subscription after one payment.
However, don't worry about it. I only offered this alternative because you wanted to sponsor it.

Done! (I'll cancel after 1 month)

Thanks and stay tuned for more.


Use symbols instead of strings in opts access

Hi everyone,
First I would like to thanks every contributor for their work on this gem.
I run into a little bit of trouble recently as I wanted to give a name while creating a container using :
container = Docker::Container.create(Cmd: ['ls'], Image: 'base', name: 'testing_stuff')
The parameter name was not taken into account. After some digging, I noticed that the parameter name was extracted from opts using string :
name = opts.delete('name')
As with newer ruby version, the hash syntax of {'x': 'y'} automatically transform the key to a symbol, is it not better to use symbol instead of string to extract value from opts ?
I know that I can use 'name' => 'testing_stuff' to force the usage of string as key but I don't really want to. First because I think using always symbols for key is a good pratice and secondly because I prefer the later syntax.
If you are OK with this, I'll submit a pull request using symbol instead of string while accessing opts and add something for retro-compatibility. Please let me know your thoughts about that.
Thanks and kind regards,
Albin.

We've tried to resist moving everything to symbols because the API doesn't follow in line with how rubyists generally use symbols.  It's not often that we use :Cmd as a symbol versus 'Cmd', and unfortunately docker's API isn't as uniform to let us use something like #capitalize and #underscore to and from the endpoints.  For this reason, we've tended to leave everything as strings if we could.
I think in a few places, we've done something similar to opts.delete(:name) || opts.delete('name') since these params aren't passed to API in the same way.  If you'd like to open a PR for that, I will accept it.

Thanks for the explanation. As I'm new to this gem (and to ruby and docker in general), it's not always easy to understand choice that were made even if I know that there is always a good reason behind any choices.
I'll open a PR soon then, thanks again.


Card errors are unrecoverable

Our CardHandler.swift currently sends errors on Card Flight errors, which is fine, but our SwipeCreditCardViewController handles errors by telling users something went wrong. The problem is that once a CC swipe errors, the signal no longer sends values, and subsequent card swipes aren't recognized at all. You would need to re-instantiate the view controller to get it working again. Confusing UX.

@ashfurrow do you think the results of this could manifest itself as the feedback we saw in a few auctions captured here: https://trello.com/c/wzzK232J/22-kiosk-cc-credential-management

Definitely possible – I was still a bit unclear about how that bug presented itself.
This problem would be:

User is asked to swipe their card.
The tokenization fails for whatever reason (swiped too quick/slow, api is down, network hiccup, etc).
The user sees an error, and is asked to swipe again, but the card reader is no longer listening for swipes.

Obviated.


Docker will now force-remove rendition entries from db

Since Docker will use a new file system on a rebuild, old renditions in
$MEDIA/images will no longer be present. By removing rendition entries from db
Wagtail will be forced to generate new renditions, instead of providing dead
links to the old renditions.

@Eeemil Sorry this PR did not get reviewed sooner. The management command to clear renditions from the database is really helpful.
I am not 100% sure about running it from docker-entrypoint.sh. It looks to me like the Dockerfile is trying to be an example of how one might build production images (starting with the slim image and clearing up caches as you go). If I interpreted this correctly, then I am concerned about code that always clears the image renditions when the container starts (even though it is just fine for the demo).
Can you help me think through when this command should run - and when it will run? When I stopped my containers using Ctrl-C to stop docker-compose up, the database and the image renditions were both preserved. docker-compose up -d followed by docker-compose stop also preserved the database and rendition files. Using docker-compose down got rid of the database (and presumably the files).
I think the need for your delete_renditions command comes when the database data is preserved by the app container is not. I think that combination does not occur when using the instructions and Dockerfile + docker-compose.yml in this project. It happens when using the Dockerfile and docker-compose.yml in https://github.com/wagtail/docker-wagtail-develop (which does preserve the database volume). In which case we need to add the management command here and then use it from https://github.com/wagtail/docker-wagtail-develop.

@Eeemil you're right:
The management command to clear renditions from the database is really helpful.
My thinking is that Dockerizing any file-based app or set of apps is a "shifting sands" proposition, and rather than welding in a command to clear what may or may not be a bunch of orphan renditions, why not just ship it from github and document it along with the use cases that make it a valuable utility. "load_initial_data" and "delete_renditions" are needed in the early dev ("hack") phases of experimenting with the bakerydemo/Wagtail learning experience.


There are some warnings of Inspector's Elements

When I selecting a element by Inspector, there are some yellow box with warngin.

It fixed, then close this issue.


deleted unused image

Validation Status: Successful
JobID: 512718f5-28d0-4b3d-afa9-8310413bd3c4

:white_check_mark: Validation status: passed
For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


feat(HMS-4156): confirmation checkbox in delete domain confirm modal

Add confirmation checkbox that enables delete button to warn user that the action cannot be undone.
In unit test, some jest calls were replaced by newer variants as the older were deprecated.

I tested the change locally but the UI was unchanged.  Maybe I  missed something?  Screenshots look great though!


Whatsapp no longer working

Describe the bug
Since yesterday, clicking on Whatsapp only leads to a page that tells me to update chrome.
To Reproduce

Add Whatsapp Service
Try opening it

Expected behavior
It should open Whatsapp
Screenshots

Desktop (please complete the following information):

OS: Windows 10
Version 5.0.0-beta.24
Release 4.0.2 / win32 / x64

Got same issue here, but I went a little bit further
**Observations : **

When you start Franz, WhattsApp fails loading as @destructive-dragon described.

When you right click on the WhattsApp icon on the left panel and hit "reload", WhattsApp starts fine !

When WhattsApp have started (after the "reload"), it proposes to update WhattsApp

(Sorry, screen in french as I'm French speaking :( )

Updating used to be successfull

When you close Franz, you have to restart the whole process : Start Franz - Reload WhattsApp - Update WhattsApp

Environement :

OS: Windows 10 pro
Version 5.0.0-beta.24
Release 4.0.2 / win32 / x64

After deep check, it looks like issue is already known
#https://github.com/meetfranz/franz/issues/1185


docker-machine-kvm: init at 0.7.0

Things done

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

[x] NixOS
[ ] macOS
[x] Linux

[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

Merging this pr, as i'm using it and it works fine.


Bluetooth: Host: L2CAP data gets truncated if MTU is larger than 245 bytes

Discussed in https://github.com/zephyrproject-rtos/zephyr/discussions/55380

Originally posted by fbzhomi March  2, 2023
Hi Folks,
Currently I am running on Zephyr 3.2 at a vendor specific platform and create an application to run BLE L2CAP stress TX test. I found an issue that when the applications tries to send a L2CAP SDU data with 2000 bytes which is beyond 245 bytes(a full L2CAP complete packet size) data via zephyr API bt_l2cap_chan_send call every 15ms, device has a chance to send a corrupted L2CAP data over the air. The symptom is like whole trunk of L2CAP start traffic is missing, and L2CAP continue packet becomes the first L2CAP packet to the air and when remote device received the corrupted L2CAP data, it wrongly consider L2CAP continue to be L2CAP start and try to parse L2CAP SDU length field and complains about invalid SDU length, then force disconnect the L2CAP channel.
My current prj.conf for L2CAP setting are
CONFIG_BT_BUF_ACL_RX_SIZE=251
CONFIG_BT_L2CAP_TX_MTU=2000
CONFIG_BT_BUF_ACL_TX_SIZE=251
CONFIG_BT_CTLR_DATA_LENGTH_MAX=251
CONFIG_BT_BUF_ACL_TX_COUNT=255
I can reproduce this issue in two platforms using Zephyr 2.3 and Zephyr 3.2 so it seems like a bluetooth host issue in subsys of Zephyr.
I was wondering that if Zephyr stack has been running L2CAP stress test per each version upstreams. I check the L2CAP shell zephyr/subsys/bluetooth/shell/l2cap.c only support 230 bytes L2CAP SDU and only support single TX via CLI instead of TX stress test. So it might be a mis-coverage.

@fbzhomi Are you able to push your stress test somewhere so that we can use it to reproduce the issue?

We have downstream tests with 1230-byte SDUs: https://github.com/jori-nordic/zephyr/blob/66d9ddd9dc587f299c530a5aea307f1b68075e59/tests/bluetooth/bsim/host/l2cap/stress/src/main.c#L1
We also have the same in hardware downstream. This could still be a corner-case that is missing coverage.
@fbzhomi So knowing how exactly you call the l2cap APIs will help us (ie your stress-test app sources):
If you are using nordic hardware and don't want to share the sources publicly, you can open a private devzone ticket and mention my name so I get added to it (Jonathan Rico).

Hi
Thanks for the reply.
I am sorry that I cannot share a complete code logic for you due to the company IP policy. I am running host only build using zephyr BT stack 3.2 and use a vendor controller build. I believe you can use nRF5340 DK to test it since I used to reproduce this issue using zephyr 2.3 one year ago and started to hit this issue.
My l2cap application will be similar like l2cap shell implementation in zephyr.
I have global tx pool for L2CAP tx purpose.
NET_BUF_POOL_FIXED_DEFINE(data_tx_pool, L2CAP_TX_BUFF_NUM,
BT_L2CAP_SDU_BUF_SIZE(BSL_MAX_TX_BUFF_SIZE), 8, NULL);
My core l2cap send os like
sEffectiveTxMTU = 491;
int l2cap_send(uint8_t *buf_data, uint16_t len) { 	int ret; 	if (len == 0) { 		BSL_LOG("0 length buf_data to send!"); 		return -1; 	} 	uint16_t l = 0; // length to be transmit in one SDU 	int count = (len - 1) / sEffectiveTxMTU + 1;   struct net_buf *buf; 	if (l2ch_chan_server.ch.tx.credits < count) { 		return -ENOEXEC; 	} 	while (count--) { 		buf = net_buf_alloc(&data_tx_pool, K_NO_WAIT); 		if (!buf) { 			BSL_LOG("no buffers in data_tx_pool"); 			return -1; 		} 		net_buf_reserve(buf, BT_L2CAP_SDU_CHAN_SEND_RESERVE); 		l = MIN(sEffectiveTxMTU, len); 		net_buf_add_mem(buf, buf_data, l); 		len -= l; 		ret = bt_l2cap_chan_send(&l2ch_chan_server.ch.chan, buf); 		if (ret < 0) { 			BSL_LOG("unable to send: %d", -ret); 			net_buf_unref(buf); 			return -ENOEXEC; 		} 	} 	return 0; }
And I am calling this function with a buffer size 491 bytes every 15ms and LE connection interval is 15ms as well. I enable 2m phy and data length extension feature to 251 TX octets to maximize the TX throughput.

Yep, I was working on that yesterday, already found two bugs in l2cap. Don't know yet if your problems will be fixed by those fixes, but I'll probably have a PR you can try in the next days.

@fbzhomi could you try with the changes in https://github.com/zephyrproject-rtos/zephyr/pull/55519 ?

Hi Jonathan,
What is the fix you want me to try? Is there some fix in L2CAP TX side?

From: Jonathan Rico @.>
Sent: Tuesday, March 7, 2023 1:57 AM
To: zephyrproject-rtos/zephyr @.>
Cc: Ming Zhou @.>; Mention @.>
Subject: Re: [zephyrproject-rtos/zephyr] Bluetooth: Host: L2CAP data gets truncated if MTU is larger than 245 bytes (Issue #55404)
@fbzhomi could you try with the changes in #55519 ? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned. Message ID: <zephyrproject-rtos/zephyr/issues/55404/1457877404@ github. com>
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
ZjQcmQRYFpfptBannerEnd
@fbzhomihttps://github.com/fbzhomi could you try with the changes in #55519https://github.com/zephyrproject-rtos/zephyr/pull/55519 ?
—
Reply to this email directly, view it on GitHubhttps://github.com/zephyrproject-rtos/zephyr/issues/55404#issuecomment-1457877404, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AVOXI2YT6FQFAJLWX63P36LW24A7ZANCNFSM6AAAAAAVOP6YV4.
You are receiving this because you were mentioned.Message ID: @.***>

Yes there are changes in both TX and RX sides, you need to apply all the commits with the message "Bluetooth: host: ..." from here https://github.com/zephyrproject-rtos/zephyr/pull/55519/commits.
You can do that by doing git fetch pull/55519/head and then git rebase -i FETCH_HEAD.

Hi Jonathan,
Thanks. In our end, we have narrowed down the issue seems to happen below the Zephyr BT host stack and it could be some where in hci driver or even controller build. Because these two areas are both customized implementation. I think your fix won't help solve my problem.
I will continue looking into this issue and will keep you posted if we confirm there is an issue in Zephyr BT host stack.
Thanks.

From: Jonathan Rico @.>
Sent: Tuesday, March 7, 2023 10:52 PM
To: zephyrproject-rtos/zephyr @.>
Cc: Ming Zhou @.>; Mention @.>
Subject: Re: [zephyrproject-rtos/zephyr] Bluetooth: Host: L2CAP data gets truncated if MTU is larger than 245 bytes (Issue #55404)
Yes there are changes in both TX and RX sides, you need to apply all the commits with the message "Bluetooth: host: .. . " from here https: //github. com/zephyrproject-rtos/zephyr/pull/55519/commits. You can do that by doing git fetch pull/55519/head
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
ZjQcmQRYFpfptBannerEnd
Yes there are changes in both TX and RX sides, you need to apply all the commits with the message "Bluetooth: host: ..." from here https://github.com/zephyrproject-rtos/zephyr/pull/55519/commits.
You can do that by doing git fetch pull/55519/head and then git rebase -i FETCH_HEAD.
—
Reply to this email directly, view it on GitHubhttps://github.com/zephyrproject-rtos/zephyr/issues/55404#issuecomment-1459628259, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AVOXI24B7JDABZESZBIDRULW3AUC7ANCNFSM6AAAAAAVOP6YV4.
You are receiving this because you were mentioned.Message ID: @.***>

Sounds good. Thanks for the bug report though, it prompted me to find and fix more issues in l2cap :)

Closing as invalid, please re-open if you find out the bug is indeed coming from the host.


close recipe loses search

When you do a search, open a recipe, and then close the recipe, you're brought back to your library without your prior search. Using the back button doesn't lose the search, and closing the recipe is "the same" as going back one step.
Exactly how durable the 'active library search' should be is up for debate. Perhaps a machine preference, so navigating to the library always retains the most recent search? I'm not sure if that's weird or not.
Relates to #30.

https://github.com/folded-ear/gobrennas-client/pull/111


Add Gemini icon

Contribution Guidelines

[X] I have read and agree to the Contribution Guidelines

Icon Name
google-gemini-icon
Icon(s)

https://github.com/walkxcode/dashboard-icons/pull/683


EC2 images (AMI's) - No longer working?

Is there a reason the AWS EC2 AMI's no longer work?
I just copied/installed both listed in the docs:
ami-c74d0db4
ami-06220275
Neither of them boot to a system with docker (or Scrapoxy stand-alone) installed?

Hello @rkmfl ,
I've just tested images : it works fine.
Can you details your problem ?
Thanks,
Fabien.

@fabienvauchelles thank you for the reply.
There isn't much detail I can provide, because the copy of the EC2 images appeared to be empty.  I can explain my steps, if that helps?  I reach the entire documentation, then I followed the steps outlined in both documents:

http://scrapoxy.readthedocs.io/en/master/standard/providers/awsec2/index.html
https://media.readthedocs.org/pdf/scrapoxy/master/scrapoxy.pdf
I've attempted to copy the image, then deploy - each of the two options:
ami-c74d0db4
ami-06220275
In each case, when I finish, I'm left with a base OS, without Scrapoxy or Docker installed.  Of course nothing at the local IP, port 8889 (eg http://localhost:8889/ ).

I've copied AWS EC2 images and run them hundreds of times.  I don't see where I could be running into any issue there, I've triple-confirmed I am running the copy of those images without issue.
Although I'm replying immediately, please remember that the issue was 2.5 months ago.  I could repeat the process again now if you like, but this is such a very basic process and the outcome of deploying an EC2 instance cannot be somehow different than the copy, so I'm just not sure what else to do?
Perhaps if you could give me some "next steps", I could follow those and get you more details?  In the documentation I mentioned, the next-steps are either (a) test via the HTTP GUI @port 8889, or (b) Run Docker.  Neither of those worked.  Do you have some other things you'd like me to try instead?
Thank you in advance,
rkmfl

corrected with the easy install in 4.0.0

Hey there! 🌟 Exciting news! Scrapoxy 4 is ready to rock 🚀. Check it out at Scrapoxy.io (explore the "get started" guide, deployment documentation, and more 📚).
I can't wait to hear your feedback on this new version! Send me your coolest screenshots with as many proxies as possible! 📸💻
Join the Discord community if you have any questions or just want to chat. You can also open a GitHub issue for any bug or feature request 🐞✨.
See you soon!  😎
Fabien


missing punctuation

@linsun @duglin please review & merge -- just some missing punctuation.

easy one

LGTM


Instruction for building server package is incorrect

The instruction for building Debian packages said to run this
make package-deb VERSION=x.y.z.build UNOFFICIAL_RELEASE=true

However, I get an error when I'm trying to build version 3.6.5 on a Xenial machine:
~/rabbitmq-server-3.6.5$ make package-deb VERSION=3.6.5 UNOFFICIAL_RELEASE=true
make: *** No rule to make target 'package-deb'.  Stop.

All packaging bits were moved to rabbitmq-server-release.

With the new repo, can we still build older versions?
I'm still getting error:
cp -a /home/rabbitmq-server-release/PACKAGES/rabbitmq-server-3.7.0.milestone8.tar.xz rabbitmq-server_3.6.5.orig.tar.xz
xzcat rabbitmq-server_3.6.5.orig.tar.xz | tar -xf -
rsync -a \
	--exclude '.sw?' --exclude '.*.sw?' \
	--exclude '.git*' \
	--delete --delete-excluded \
	debian/ rabbitmq-server-3.6.5/debian/
rsync: mkdir "/home/rabbitmq-server-release/packaging/debs/Debian/rabbitmq-server-3.6.5/debian" failed: No such file or directory (2)
rsync error: error in file IO (code 11) at main.c(674) [Receiver=3.1.1]
Makefile:35: recipe for target 'package' failed
make[2]: *** [package] Error 11
make[2]: Leaving directory '/home/rabbitmq-server-release/packaging/debs/Debian'
Makefile:72: recipe for target 'package-deb' failed
make[1]: *** [package-deb] Error 2
make[1]: Leaving directory '/home/rabbitmq-server-release/packaging'
Makefile:214: recipe for target 'package-deb' failed
make: *** [package-deb] Error 2

Why do you need to build a Debian package of 3.6.5?

we want to build and keep packages for our own deployment for better security tracking.

Our build system does not assume that past packages
may need rebuilding.
You are trying to build from master, by the way.

On 12 Jan 2017, at 23:56, mydiemho<EMAIL_ADDRESS>wrote:
we want to build and keep packages for our own deployment for better security tracking.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

Forgive my lack of knowledge, but what branch should I build on then?
Here's the script I use:
#!/bin/bash

set -e

VERSION=$1

if [[ -z $VERSION ]]; then
    echo ERROR: "must specify the build version (i.e. 3.6.5)"
    exit 1
fi

echo "Ensuring packages exist..."
sudo apt-get update && apt install -y debhelper erlang-dev erlang-src python-simplejson \
            xmlto xsltproc erlang-nox zip rsync elixir

rm -rf rabbitmq-server-$VERSION
git clone https://github.com/rabbitmq/rabbitmq-server-release.git

cd rabbitmq-server-release
make package-deb VERSION=$VERSION UNOFFICIAL_RELEASE=true

You need to check out the umbrella, switch to the right tag with make up BRANCH={something that git can check out}, and then use the build procedure that was used at that point in time.
You cannot build an older version from master or stable (which is what I was referring to by "rebuilding" above).

Not sure how to proceed with this but in general, with development alpha builds now being produced by our CI/CD pipeline, building from source is not necessary nearly as often.