Huion tablets not working in ublue images, while Fedora's images work

Hi!
Huion tablets are not working on ublue images:
Bazzite KDE: Not working
Bazzite Gnome: tablet shows up but pen doesn't work, so I'd consider it now working
Aurora: Not working
Kinoite Ublue: Not working (rebased from fedora kinoite, where it was working previously)
While on non ublue images (tested Fedora Workstation Gnome non atomic, Fedora KDE non atomic, Fedora Kinoite) it works out of the box.
All tests on wayland, just plain default out of the box.
There are a couple of things that are puzzling. First we thought this had to do with a not up to date libwacom package, currently bazzite uses 2.11.0, while latest is 2.12.2, and changelog shows some work on Huion tablets, but this was not it, as I downgraded my working arch installation package to 2.11 and it kept working.
Another thing worth mentioning is how KDE shows the Drawing tablet interface. When the tablet is unplugged, but "it's going to work" when plugged, it shows this interface:

Meanwhile, when it's unplugged but "it's not going to work" when plugged, it shows this:

You can find our discussion over here https://discord.com/channels/1072614816579063828/1268470456441110568 tagging @HikariKnight as they have followed the discussion and is aware of the issue.
Possible culprit could be something to do with libinput and its interactions with libwacom/libwacom-data. For example, libinput list-devices doesn't list the tablet in the affected images.
Please also note that this seems to be happening on some tablets (me and another user reported the issue with huion), but Hikari's wacom works fine out of the box.
I'd say those are all our findings. Let me know if you can think of anything else I can test/help with.
Cheers!

Did we include the libwacom surface packages on main images? If so I wonder if this is conflicting here.

Happy to help with this. I'm currently using Flatpak version of OpenTabletDriver, but it would be nice if these tablets worked out of the box.
Device info - https://paste.centos.org/view/5697c3a8
Logs when connecting the tablet on Wayland Gnome session - journal.log
Tablet model Huion H950P.
It is recognized by Gnome Settings, but not input is registered

@m2Giles  it seems like no, libwacom-surface is included only if kernel flavor is "surface", see https://github.com/search?q=org%3Aublue-os+libwacom-surface&type=code . I'm on bluefin-nvidia generic laptop version.

@safonas Ideally we would be using the opentabletdriver flatpak as it will let us avoid having to rely on a distrobox for this.
sadly not all tablets are supported by default by the kernel modules hence why a userspace driver like opentabletdriver is necessary for a lot of them.
@Potajito can you check if the flatpak version of opentabletdriver works with the tablet in question.
PS: sorry for it taking so long for me to get to this issue, been recovering from my hospitalization up until now.

O no, hope you're all better? Taking time off to recover is important ✨
I rebased in to Bazzite again for a hot second, was hoping that it might work out of the box now with the cool new tablet features from Plasma 6.2, but no cake, unfortunately.
Open Tablet Driver (Flatpak, I think) did recognise my tablet now (no idea why), but I could not get it to work. The cursor (sometimes multiple of them) where nowhere near the pen, the mapping is super weird. I rebased to Kinoite for the time being again where it keeps on working out of the box like a charm (fingers crossed) …
Why would you need to use Distrobox for supporting the tablet in Bazzite when it works without it on Kinoite for some reason?
I could rebase to Bazzite again at some point if you want me to try out some things.

we have been installing opentabletdriver inside distrobox since its a userspace driver and covers tablets that the kernel drivers do not cover, that is why.
Bit unsure how  we can start figure out where the difference is since i have 0 affected hardware to test with.

Mmmh, ok, if you can think of something I'd be happy to test stuff out. I'm glad that you're doing better ^__^

Not sure if my experience would be directly useful, but I thought I'd share some notes here since I have affected hardware, even if the underlying causes might be different for me:

I have a Huion Kamvas 13 which I use with a laptop running a custom image based on Aurora:stable-dx (which as of right now is on F40 with KDE Plasma 6.2).
I used to use it with OpenTabletDriver installed via rpm-ostree in a custom image. I had to set some very wild numbers in the OpenTableDriver manual calibration/remapping of the stylus's input range to the display in order to make it usable.
Around 10 days ago, I did a reboot of my laptop and I stopped being able to get OpenTabletDriver to correctly detect my tablet. I tried replacing the rpm-ostree package with the Flatpak, but both had the same problem (the one which is supposed to be solved by OTD's troubleshooting instructions , even though I already followed the instructions there). I eventually gave up on trying to make OTD work again, and instead decided to try to make KDE Plasma's tablet support work.
I was able to get KDE Plasma to detect my tablet by 1) ensuring that the wacom and uclogic kernel modules were loaded and not blacklisted; 2) adding a .tablet file in /usr/share/libwacom based on https://github.com/linuxwacom/libwacom/blob/master/data/huion-kamvas-13.tablet , since the version of that file provided by libwacom in F40 is older and not comprehensive enough to detect my tablet; and then 3) adding a udev rule in /etc/udev/rules.d to override the OTD-related udev rules (at /usr/lib/udev/rules.d/71-opentabletdriver-ublue.rules, which normally sets LIBINPUT_IGNORE_DEVICE to 1) to instead set LIBINPUT_IGNORE_DEVICE to 0 so that libinput would stop ignoring my model of tablet.  I am sure that step 3 was necessary; I'm not sure if step 1 was necessary, but I tried it in order to completely undo the things needed for OpenTabletDriver which I suspected might interfere with KDE Plasma's tablet support.
The UX on KDE Plasma is much better than with OTD - everything "Just works" without any manual calibration/remapping needed, and now I can even have the stylus move the cursor in whichever display currently has the cursor (which is something I could not achieve on OTD).

@ethanjli Oh, that's so interesting! I'll give that a try if I can find the time. I'm not sure I understand step one: sudo rmmod wacom hid_uclogic from the OTD wiki you linked removes the kernel module (or am I mistaken?), how do you check that they are present / loaded?
(I also prefer Plasma's tablet settings over OTD, it would be cool if it worked with that on Bazzite).

To check whether those two kernel modules are loaded, you can do something like lsmod | grep hid_uclogic. I believe the two ways to disable them (to make OTD work) are 1) to add some kernel arguments (e.g. via sudo rpm-ostree kargs --editor) or 2) to blacklist them via drop-in config files in /etc/modprobe.d - so if you had previously disabled them somehow and you want to un-disable them, then you would need to undo any changes made in either of those two ways for hid_uclogic and wacom.

Not sure if my experience would be directly useful, but I thought I'd share some notes here since I have affected hardware, even if the underlying causes might be different for me:

I have a Huion Kamvas 13 which I use with a laptop running a custom image based on aurora-dx:stable (which as of right now is on F40 with KDE Plasma 6.2).
I used to use it with OpenTabletDriver installed via rpm-ostree in a custom image. I had to set some very wild numbers in the OpenTabletDriver manual calibration/remapping of the stylus's input range to the display in order to make it usable.
Around 10 days ago, I did a reboot of my laptop and I stopped being able to get OpenTabletDriver to correctly detect my tablet - when I tried to make OTD detect the tablet, the tablet would go into a several-cycle reset loop and OTD would report permissions errors accessing /dev/hidraw* (even though, after following OTD's troubleshooting instructions, all those devices show up with +rw perms for owner & group & other). I tried replacing the rpm-ostree package with the Flatpak, but both had the same problem. I eventually gave up on trying to make OTD work again, and instead decided to try to make KDE Plasma's tablet support work.
I was able to get KDE Plasma to detect my tablet by 1) ensuring that the wacom and uclogic kernel modules were loaded and not blacklisted; 2) adding a .tablet file in /usr/share/libwacom based on https://github.com/linuxwacom/libwacom/blob/master/data/huion-kamvas-13.tablet , since the version of that file provided by libwacom in F40 is older and not comprehensive enough to detect my tablet; and then 3) adding a udev rule in /etc/udev/rules.d to override the OTD-related udev rules (at /usr/lib/udev/rules.d/71-opentabletdriver-ublue.rules, which normally sets LIBINPUT_IGNORE_DEVICE to 1) to instead set LIBINPUT_IGNORE_DEVICE to 0 so that libinput would stop ignoring my model of tablet.  I am sure that step 3 was necessary; I'm not sure if step 1 was necessary, but I tried it first in order to completely undo the things needed for OpenTabletDriver which I suspected might interfere with KDE Plasma's tablet support; and I'm not sure if step 2 was necessary, but making my tablet show up in libwacom-list-local-devices was at least useful for troubleshooting.
The UX on KDE Plasma is much better than with OTD - everything "Just works" without any manual calibration/remapping needed, and now I can even have the stylus move the cursor in whichever display currently has the cursor (which is something I could not achieve on OTD).

This is lots of useful information and i believe all of this can be tested using sudo rpm-ostree usroverlay

Not sure if my experience would be directly useful, but I thought I'd share some notes here since I have affected hardware, even if the underlying causes might be different for me:

I have a Huion Kamvas 13 which I use with a laptop running a custom image based on aurora-dx:stable (which as of right now is on F40 with KDE Plasma 6.2).
I used to use it with OpenTabletDriver installed via rpm-ostree in a custom image. I had to set some very wild numbers in the OpenTabletDriver manual calibration/remapping of the stylus's input range to the display in order to make it usable.
Around 10 days ago, I did a reboot of my laptop and I stopped being able to get OpenTabletDriver to correctly detect my tablet - when I tried to make OTD detect the tablet, the tablet would go into a several-cycle reset loop and OTD would report permissions errors accessing /dev/hidraw* (even though, after following OTD's troubleshooting instructions, all those devices show up with +rw perms for owner & group & other). I tried replacing the rpm-ostree package with the Flatpak, but both had the same problem. I eventually gave up on trying to make OTD work again, and instead decided to try to make KDE Plasma's tablet support work.
I was able to get KDE Plasma to detect my tablet by 1) ensuring that the wacom and uclogic kernel modules were loaded and not blacklisted; 2) adding a .tablet file in /usr/share/libwacom based on https://github.com/linuxwacom/libwacom/blob/master/data/huion-kamvas-13.tablet , since the version of that file provided by libwacom in F40 is older and not comprehensive enough to detect my tablet; and then 3) adding a udev rule in /etc/udev/rules.d to override the OTD-related udev rules (at /usr/lib/udev/rules.d/71-opentabletdriver-ublue.rules, which normally sets LIBINPUT_IGNORE_DEVICE to 1) to instead set LIBINPUT_IGNORE_DEVICE to 0 so that libinput would stop ignoring my model of tablet.  I am sure that step 3 was necessary; I'm not sure if step 1 was necessary, but I tried it first in order to completely undo the things needed for OpenTabletDriver which I suspected might interfere with KDE Plasma's tablet support; and I'm not sure if step 2 was necessary, but making my tablet show up in libwacom-list-local-devices was at least useful for troubleshooting.
The UX on KDE Plasma is much better than with OTD - everything "Just works" without any manual calibration/remapping needed, and now I can even have the stylus move the cursor in whichever display currently has the cursor (which is something I could not achieve on OTD).

Some details to make it easier to follow for people in the future (I am new to Bazzite but not Linux, but detailed instructions never hurt). To uninstall the Open Tablet driver (at least in Bazzite):

Run sudo systemctl stop arch-opentabletdriver.service  to be sure it has stopped
distrobox enter arch
distrobox-export --app otd-gui --delete
paru --remove opentablet driver
Then exit to exit the distrobox.

Ensure hid_uclogic is running lsmod | grep uclogic, if that returns nothing sudo modprobe hid_uclogic.
Also if that returns nothing check 'ls /etc/modprobe.d/ if it has a file with a name containing hid_uclogic, if so delete that specific file with rm. Not sure if that undoes --append=modprobe.blacklist=hid_uclogic as it wouldn't work for me with rmmod so if necessary/possible someone correct me on this.
Now to overwrite the opentablet udev rules.

find the vendor:device id by running lsusb  (for my Kamvas 16 and it seems a lot of other Kamvas models this was 256c:006d)
Copy the udev rules file to /etc/udev/rules.d with sudo cp /usr/lib/udev/rules.d/71-opentabletdriver-ublue.rules /etc/udev/rules.d/
Edit with sudo vim /etc/udev/rules.d/71-opentabletdriver-ublue.rules and look for your vendor id, you can use / followed by your vendorid then the 2 characters .* followed by the deviceid to search for it in vim, for example for the Kamvas 16 I would use /265c.*006d, the combinations are shared across multiple devices so the comment above might not directly reference your device but it will be using those rules (for me it said "HUION RTM-500" but way further up it mentions the Kamvas 16).
Change the ENV{LIBINPUT_IGNORE_DEVICE}="1" to ENV{LIBINPUT_IGNORE_DEVICE}="0"
Restart your system and watch the Huion tablet and pen now be listed in the System Settings > Drawing Tablet

Someone on the discord managed to get it running under the opentablet driver by blacklisting hid_uclogic with rmmod, but that didn't seem to work for me. However it is possible they used the flatpak version instead of the distrobox one that is installed by Bazzite when using bazzite-portal. Regardless I agree with @ethanjli  in that I have a preference for the regular KDE settings integration and would argue in favor of the udev rules to be set up so it works in this manner by default.

Last week I had to install my custom OS image onto a new SSD because my previous SSD suddenly failed, and through that process I confirmed that on F41 all I needed to do on a fresh OS install for my Kamvas 13 tablet to show up in the Plasma Settings was override the opentablet udev rules. It is now part of my custom image build workflow:

Containerfile: https://github.com/ethanjli/lutho-os/blob/638921fd5463ceaabf2d6e3ce11cce40b336b0f6/Containerfile#L11
udev rule override: https://github.com/ethanjli/lutho-os/blob/638921fd5463ceaabf2d6e3ce11cce40b336b0f6/72-opentabletdriver-disable.rules (strictly speaking, I probably only need to include the last line of the file)

Not sure if my experience would be directly useful, but I thought I'd share some notes here since I have affected hardware, even if the underlying causes might be different for me:

I have a Huion Kamvas 13 which I use with a laptop running a custom image based on aurora-dx:stable (which as of right now is on F40 with KDE Plasma 6.2).
I used to use it with OpenTabletDriver installed via rpm-ostree in a custom image. I had to set some very wild numbers in the OpenTabletDriver manual calibration/remapping of the stylus's input range to the display in order to make it usable.
Around 10 days ago, I did a reboot of my laptop and I stopped being able to get OpenTabletDriver to correctly detect my tablet - when I tried to make OTD detect the tablet, the tablet would go into a several-cycle reset loop and OTD would report permissions errors accessing /dev/hidraw* (even though, after following OTD's troubleshooting instructions, all those devices show up with +rw perms for owner & group & other). I tried replacing the rpm-ostree package with the Flatpak, but both had the same problem. I eventually gave up on trying to make OTD work again, and instead decided to try to make KDE Plasma's tablet support work.
I was able to get KDE Plasma to detect my tablet by 1) ensuring that the wacom and uclogic kernel modules were loaded and not blacklisted; 2) adding a .tablet file in /usr/share/libwacom based on https://github.com/linuxwacom/libwacom/blob/master/data/huion-kamvas-13.tablet , since the version of that file provided by libwacom in F40 is older and not comprehensive enough to detect my tablet; and then 3) adding a udev rule in /etc/udev/rules.d to override the OTD-related udev rules (at /usr/lib/udev/rules.d/71-opentabletdriver-ublue.rules, which normally sets LIBINPUT_IGNORE_DEVICE to 1) to instead set LIBINPUT_IGNORE_DEVICE to 0 so that libinput would stop ignoring my model of tablet.  I am sure that step 3 was necessary; I'm not sure if step 1 was necessary, but I tried it first in order to completely undo the things needed for OpenTabletDriver which I suspected might interfere with KDE Plasma's tablet support; and I'm not sure if step 2 was necessary, but making my tablet show up in libwacom-list-local-devices was at least useful for troubleshooting.
The UX on KDE Plasma is much better than with OTD - everything "Just works" without any manual calibration/remapping needed, and now I can even have the stylus move the cursor in whichever display currently has the cursor (which is something I could not achieve on OTD).

 Some details to make it easier to follow for people in the future (I am new to Bazzite but not Linux, but detailed instructions never hurt). To uninstall the Open Tablet driver (at least in Bazzite):

Run sudo systemctl stop arch-opentabletdriver.service  to be sure it has stopped
distrobox enter arch
distrobox-export --app otd-gui --delete
paru --remove opentablet driver
Then exit to exit the distrobox.

Ensure hid_uclogic is running lsmod | grep uclogic, if that returns nothing sudo modprobe hid_uclogic. Also if that returns nothing check 'ls /etc/modprobe.d/ if it has a file with a name containing hid_uclogic, if so delete that specific file with rm. Not sure if that undoes --append=modprobe.blacklist=hid_uclogic as it wouldn't work for me with rmmod so if necessary/possible someone correct me on this.
Now to overwrite the opentablet udev rules.

find the vendor:device id by running lsusb  (for my Kamvas 16 and it seems a lot of other Kamvas models this was 256c:006d)
Copy the udev rules file to /etc/udev/rules.d with
sudo cp /usr/lib/udev/rules.d/71-opentabletdriver-ublue.rules /etc/udev/rules.d/
Edit with sudo vim /etc/udev/rules.d/71-opentabletdriver-ublue.rules and look for your vendor id, you can use / followed by your vendorid then the 2 characters .* followed by the deviceid to search for it in vim, for example for the Kamvas 16 I would use /265c.*006d, the combinations are shared across multiple devices so the comment above might not directly reference your device but it will be using those rules (for me it said "HUION RTM-500" but way further up it mentions the Kamvas 16).
Change the ENV{LIBINPUT_IGNORE_DEVICE}="1" to ENV{LIBINPUT_IGNORE_DEVICE}="0"
Restart your system and watch the Huion tablet and pen now be listed in the System Settings > Drawing Tablet

Someone on the discord managed to get it running under the opentablet driver by blacklisting hid_uclogic with rmmod, but that didn't seem to work for me. However it is possible they used the flatpak version instead of the distrobox one that is installed by Bazzite when using bazzite-portal. Regardless I agree with @ethanjli in that I have a preference for the regular KDE settings integration and would argue in favor of the udev rules to be set up so it works in this manner by default.

The reason its set up with the OTD driver rules is because originally the kde and gnome settings did not support the tablet (there is still many they do not support)
Hence the need for OTD.
the change needed to the udev rules (for tablets that no longer need OTD) however can be PRed into the repository, not quite sure which one. im sure @KyleGospo would know which as i couldnt find it at first glance with a search before going to work.

adding
/etc/udev/rules.d/72-undo-opentabletdriver-ublue.rules
KERNEL=="hidraw*", ATTRS{idVendor}=="256c", ATTRS{idProduct}=="006d", TAG+="uaccess", TAG+="udev-acl"
SUBSYSTEM=="usb", ATTRS{idVendor}=="256c", ATTRS{idProduct}=="006d", TAG+="uaccess", TAG+="udev-acl"
SUBSYSTEM=="input", ATTRS{idVendor}=="256c", ATTRS{idProduct}=="006d", ENV{LIBINPUT_IGNORE_DEVICE}="0"

and reloading udev fixed the issue for me  - H950P now works and is configurable using standard Gnome tools - thanks @ethanjli !
Originally these rules are picked up from /lib/udev/rules.d/71-opentabletdriver-ublue.rules  which are installed from upstream OpenTabletDriver package here - https://github.com/ublue-os/config/blob/main/Containerfile#L11-L19
@HikariKnight As it stands now, uBlue disables libinput  for the all the tablets that OpenTabletDriver supports, whereas ideally AFAIU it should be disabled only for those not supported by libinput. These are distinct sets which overlap and change often, I wonder if it makes sense to maintain our own rules file or just make OTD rules optional.. say by ujust command?

yeah and those rules are just grabbed from the OTD project, we would need to find a list of devices supported by libinput and remove them automatically or have to move grabbing the otd udev rule through the otd ujust 🤔
the latter would be a lot easier to implement though


Koa2 update

updated to update to koa2 (ctx, next) middleware style
Can we push an alpha version like for the other middleware (e.g https://github.com/koajs/compress)

oups wrong branch target let me do it again

this should be merged into a v2.x branch actually

@pgherveou I'll review the below PRs first. And then rebase&merge this PR! :smile:
https://github.com/koajs/error/pull/14
https://github.com/koajs/error/pull/13

@pgherveou can you rebase with master again? 😢

https://github.com/koajs/error/pull/24


Default status code for queries is now 200

Reworking the default status code to be 200 OK.

I'm up for this. Documentation will need to be updated.
@gunnaraasen

Rebased. Will merge on green.


add ToStruct method to go sdk

move ToStruct methods from lookout to sdk.
It's easy to work with protobuf structs in other languages, for example python. But a lot of pain in go.
Analyzers need this method for unit testing.

package name


Support variety of shell such as fish and xonsh

reasons below

fish performs much better with preview info available
xonsh performs like zsh, but has an advantage on programming custom completions (https://xon.sh/tutorial_completers.html)

benchmarks:
for sh in zsh fish xonsh; do echo ">> $sh" && perf stat $sh bin/capture.$sh "git ch"; done
>> zsh
checkout
cherry-pick
checkout-index
cherry
check-attr
check-ignore
check-mailmap
check-ref-format

 Performance counter stats for 'zsh bin/capture.zsh git ch':

            183.20 msec task-clock:u                     #    1.001 CPUs utilized
                 0      context-switches:u               #    0.000 /sec
                 0      cpu-migrations:u                 #    0.000 /sec
              4227      page-faults:u                    #   23.073 K/sec
         722753876      cycles:u                         #    3.945 GHz
         518998522      instructions:u                   #    0.72  insn per cycle
         102920505      branches:u                       #  561.792 M/sec
            833572      branch-misses:u                  #    0.81% of all branches
<PHONE_NUMBER>      slots:u                          #   18.725 G/sec
         433515097      topdown-retiring:u               #     12.4% Retiring
         226964235      topdown-bad-spec:u               #      6.5% Bad Speculation
         167571466      topdown-fe-bound:u               #      4.8% Frontend Bound
<PHONE_NUMBER>      topdown-be-bound:u               #     76.3% Backend Bound

       0.182987969 seconds time elapsed

       0.173521000 seconds user
       0.007821000 seconds sys

>> fish
checkout        Checkout and switch to a branch
cherry  Find commits yet to be applied to upstream
cherry-pick     Reapply a commit on another branch

 Performance counter stats for 'fish bin/capture.fish git ch':

             53.83 msec task-clock:u                     #    1.012 CPUs utilized
                 0      context-switches:u               #    0.000 /sec
                 0      cpu-migrations:u                 #    0.000 /sec
              2925      page-faults:u                    #   54.339 K/sec
         161542274      cycles:u                         #    3.001 GHz
         337004025      instructions:u                   #    2.09  insn per cycle
          78997256      branches:u                       #    1.468 G/sec
            944733      branch-misses:u                  #    1.20% of all branches
         778914060      slots:u                          #   14.470 G/sec
         277164567      topdown-retiring:u               #     31.8% Retiring
         273597256      topdown-bad-spec:u               #     31.4% Bad Speculation
         240883326      topdown-fe-bound:u               #     27.6% Frontend Bound
          80964112      topdown-be-bound:u               #      9.3% Backend Bound

       0.053184473 seconds time elapsed

       0.046438000 seconds user
       0.010207000 seconds sys

>> xonsh
checkout
cherry
cherry-pick

 Performance counter stats for 'xonsh bin/capture.xonsh git ch':

            170.55 msec task-clock:u                     #    0.997 CPUs utilized
                 0      context-switches:u               #    0.000 /sec
                 0      cpu-migrations:u                 #    0.000 /sec
              8914      page-faults:u                    #   52.268 K/sec
         587026058      cycles:u                         #    3.442 GHz
<PHONE_NUMBER>      instructions:u                   #    1.74  insn per cycle
         199533073      branches:u                       #    1.170 G/sec
           4193248      branch-misses:u                  #    2.10% of all branches
<PHONE_NUMBER>      slots:u                          #   16.530 G/sec
         945703165      topdown-retiring:u               #     31.4% Retiring
         755144631      topdown-bad-spec:u               #     25.0% Bad Speculation
         773587341      topdown-fe-bound:u               #     25.6% Frontend Bound
         541812014      topdown-be-bound:u               #     18.0% Backend Bound

       0.171043233 seconds time elapsed

       0.135293000 seconds user
       0.036275000 seconds sys

Please fix the conflict.
And the documentation must be updated.
ddc-source-zsh must be renamed.
ddc-source-capture is better.

The shell should be switched by source param instead of source name.

thanks. all done


document /version endpoint

@mstemm

updated to document endpoint at /api/v0/version-info as implemented in https://github.com/juttle/juttle-service/pull/62

lgtm.


Verification, GDS as artifact

@jasminabrar
If you submit a Python file, the artifact is the lyrbd file, but the GDS/OAS is not included. Can we add the resulting layout binary file as part of the artifact?
thank you

This has now been added. The GDS/OAS are uploaded as an artifact in the 'Run Python Files' action. I think it makes most sense to upload them in this action (instead of the in the verification action) since this action is solely responsible for running the python files and generating the oas/gds file. It also allowed me to get rid of the python_to_oas_gds.txt file that was previously accessed in the verification action in the case when the verification action is triggered by the python action. Instead of reading the generated oas/gds names from the txt file, now I simply get the oas/gds files from the artifact.

This issue can now be closed.


Webhook Certificate not generated during OLM installation

Description
I encountered an issue while installing using OLM: not generate the Webhook server certificate.
DevWorkspace Operator: v0.26.0
CatalogSource:
apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  name: devworkspace-operator-catalog
  namespace: olm
spec:
  displayName: DevWorkspace Operator Catalog
  image: 'quay.io/devfile/devworkspace-operator-index:release'
  publisher: Red Hat
  sourceType: grpc
  updateStrategy:
    registryPoll:
      interval: 5m

update:
the generated certificate file name does not correspond to the file configured in the environment variable. The generated secret name is devworkspace-controller-manager-service-cert, while the environment variable is devworkspace-webhookserver-tls.

@stringang thank you for reporting this issue. Do you recall which version of OpenShift this occurred for you on?

Is there a reason why the catalog source you provided is in the olm namespace instead of openshift-operators? I wasn't actually able to install DWO with your catalog source, it resulted in an error about not being able to find the catalog source (and I had to manually create the olm namespace):
This operator cannot be updated. The health of CatalogSource "devworkspace-operator-catalog" is unknown. It may have been disabled or removed from the cluster.

I would suggest trying to see if things work as expected for you when adding the CatalogSource to the openshift-operators namespce instead:
apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  name: devworkspace-operator-catalog
  namespace: openshift-operators
spec:
  displayName: DevWorkspace Operator Catalog
  image: 'quay.io/devfile/devworkspace-operator-index:release'
  publisher: Red Hat
  sourceType: grpc
  updateStrategy:
    registryPoll:
      interval: 5m

When installing DWO from this CatalogSource, I saw that the devworkspace-webhookserver-tls secret was created and owned by the devworkspace-webhookserver service. Note that there is also a devworkspace-controller-manager-service-cert that is owned by the devworkspace-operator.v0.26.0 ClusterServiceVersion.

@AObuchow
I'm using native Kubernetes. Installing it in the openshift-operators namespace still presents the same issue.

kind: OperatorGroup
apiVersion: operators.coreos.com/v1
metadata:
  name: og-test
  namespace: openshift-operators
spec:
  targetNamespaces:
  - openshift-operators

subscription:
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: devworkspace-operator
  namespace: openshift-operators
spec:
  channel: fast
  installPlanApproval: Automatic
  name: devworkspace-operator
  source: devworkspace-operator-catalog
  sourceNamespace: openshift-operators
  startingCSV: devworkspace-operator.v0.26.0

The webhook certificate should be automatically injected by cert-manager or service-ca.


D415-why the roof is seen in depth image on the left side of the wall?

Hello,
The distance for visualization was set between 80-100cm, the camera was 90cm from the wall. The high accuracy preset was set, also the edge filtering was on (according to the Intel's whitepaper). The roof is about 6-7 meters far from the camera. What is wrong here? Is it possible to separate correctly the wall from the window and the background with D415 (like I have separated the shape from the wall in the image)?

Thank you in advance.
Best regards

Is it possible that "yellow" in this case is infinity, or beyond 100cm?
The problem then would not be the background and roof, but why parts of the wall is showing up at much farther away. This may happen if the camera is over exposed or there are no features on the wall.
If you look at the "left image" it will help to see whether the imagers are saturated or simply don't see texture.

Same as issue #3962 I believe.
https://github.com/IntelRealSense/librealsense/issues/3962
Please try to reduce the exposure and gain manually and see if it helps.

Dear Anders,
I have tried to reduce the exposure and the gain, but without significant results.
Yes, in most cases there are no features on the wall and will not be any features.
Hence, it is not possible to extract the wall with the D415 camera reliably? The solution should be universal for all walls, to separate the wall based on the depth information from the window or from the
ornament.

Dear Anders,
Accordingly, with D415 I can't solve this problem? Without a great depth image I can't extract the specified walls (not only the wall from the image). Do you have any suggestion? Maybe another camera or some other equipment?
Thank you,
Best regards.

Have you tried the D435?
From your image it looks like there should be enough texture to get very good depth.

Hi @TDVL,
Please double check and perhaps to try to adjust the depth visualization range as @agrunnet suggested:

Is it possible that "yellow" in this case is infinity, or beyond 100cm?

It seems that all the depth points that are beyond 100cm are represented in yellow.

Hello Support Team,
The depth visualization range was between 0,8-1m, the camera was on 0,9m from the wall. The setting was not infinity. This is the problem. I tried to set the exposure, but without improvements.
I don't know what is the problem, the camera setting or the camera itself?
I need the wall surface in one, unique color in depth image, or I can not detect the wall after the binarization and processing (the multicolored wall surface in depth image produces big losses from the wall and these losses later are not recoverable).
Any suggestion? Maybe you can try it outdoor on your wall and window?
Thank you.
Kind regards.

Hi TDVl,
With the RealSense viewer and the stereo module stream, could you please check the depth (distance) from the wall vs the roof? Move the mouse cursor inside the depth stream display and the distance will be shown at the bottom of the

Hi TDVl,
With the RealSense viewer and the stereo module stream, could you please check the depth (distance) from the wall vs the roof? You can move the mouse cursor inside the depth stream display and the distance will be shown at the bottom of the display window. Please see the attachment.
https://intel.sendsafely.com/receive/?thread=RAB1-PFUT&packageCode=gd7CVh2xt1jL7zpWN189XlWZ99Yh7BMnjSgDyyfaiAk#keyCode=FAKmI7askUsYqy33MeZQgxI2kQAL2lQ3dIx2y5jyOHs
Attachment(s):
depth_dist.png - https://realsensesupport.intel.com/attachments/token/2xfpOvnxLDn5DDL89SahJIjTg/?name=depth_dist.png

Closing this issue for now. Please feel free to reopen if issue is still relevant. Thank you.


chore(test): improve locale test coverage

Related Ticket(s)
Refs #2080
Description
Improved test coverage of the Analytics API.
Changelog
Changed

Added tests for Locale service

@asudoh I'm not importing my dependencies at the top of the file.  I'm using jest.doMock to create my mocks in a beforeEach clause.  (doMock prevents the mock from being auto-hoisted to the top scope of the file.)
This is a specific strategy that I like to employ with my unit testing.  I like to reduce possible test order dependencies by avoiding variables scoped for the whole file and using beforeEach and the this context to establish all my mocks and test data.  And then each individual test can adjust the test data or the mock behavior for whatever it needs to do.  This way I can be sure that each tests starts with the same initial state that resets itself in beforeEach.
If this doesn't match the team convention, I can change things out.

@ccwilson-us-ibm-com Thank you very much trying to explain the background of your pattern. Do you want to elaborate this with some actual code examples and explain why the existing pattern makes the test flaky? Especially I imagine that other Jest users may have hit the same problem given how populate Jest is and the pattern is about very basic mocking strategy. Thanks!

@asudoh @ccwilson-us-ibm-com just checking on this PR as it looks like conversations on this has stopped a few days ago. Seeing that this is a low priority issue, will move to the next release regardless.

Let's say I mock my module in the file scope:
jest.mock('../module');

But that's not very useful on it's own for a module that is being imported by the file I'm testing, but not by the test file itself.  So I should provide a mock as well:
jest.mock('../module', { ...mockObject });

And that works fine, as long as every test needs the same behavior from the mock object.  The moment I need to change how that mock behaves on a per test basis, I need to make some changes.  I need to store the mock in a variable that can be referenced in the test scopes:
let mockModule = {....};
jest.mock('../module', mockModule);

describe(function() {
  it('test1', function() {
     mockModule.propertyOrSpy = '...';
     ... do your test
  });

  it('test2', function() {
     ... do your test
  });
});

We now have a potential test run order dependency.  If test2 depends on the original behavior of the mock, it may fail when test1 runs first and modifies that behavior.  Ok then... Let's use beforeEach then:
let mockModule = {....};
jest.mock('../module', mockModule);

describe(function() {
  beforeEach(function() {
     mockModule.propertyOrSpy = ...;
  });

  it('test1', function() {
     mockModule.propertyOrSpy = '...';
     ... do your test
  });

  it('test2', function() {
     ... do your test
  });
});

But now I've introduced a bit of extra cognitive effort.  The mock is defined up top in the file scope, but that definition will never be used, because the before each will overwrite that behavior on every test run.  We could just declare the variable in the file scope (let mockModule;), but we're only doing that because the jest.mock call is also at the file scope.  This next step is almost entirely personal preference, but is rooted in the old coding principals of avoiding global-ish scopes and defining variables/properties at the lowest scope necessary.  We don't have to split the declaration of the variable from the initialization of the variable, by using the this context object within the beforeEach, but that also requires using the jest.doMock function since jest.mock automatically scopes up to the file:
describe(function() {
  beforeEach(function() {
     this.mockModule = {};
     jest.doMock('../module', this.mockModule);
  });

  it('test1', function() {
     this.mockModule.propertyOrSpy = '...';
     ... do your test
  });

  it('test2', function() {
     ... do your test
  });
});

This reduces the amount of vertical space in the file between variable declaration and initialization.  The same this context object is passed to each it test.  And the whole state of mocks and data initialized in the beforeEach is guaranteed to reset itself before each test.  This keeps test order dependencies from creeping in. (Some test frameworks encourage randomizing the test order to help catch this type of order dependency).  And helps me organize my test data and mock objects.

Thanks @ccwilson-us-ibm-com very much for explaining the problem you are tacking, it's 💯 what I wanted as an explanation. And great to see that you are trying to solve the problem space, it (clean-ups before or after test) is something I see lacking in React codebase in several places.
Another goal in this problem space would be having people, especially new people coming to the codebase, easily understand what we do. From that standpoint, I recommend the following:
let mockModule = {....};
jest.mock('../module', mockModule);

// Alternative: Keeping a deep-copy of `mockModule`
const origProperty = mockModule.property;

describe(function() {
  beforeEach(function() {
     mockModule.property = origProperty;
  });

  it('test1', function() {
     mockModule.property = jest.fn();
     ... do your test
  });

  it('test2', function() {
     ... do your test
  });
});

Another approach we can take, which seems to be applicable to several (or all?) mocks you added in this change, is leveraging jest.mock()'s "turning every function property to mocks" feature and Jest's "auto-resetting all spies/stubs after each test" feature. This allows us to define stubs without having to replace properties or having to manually reset the stub, for example: https://github.com/carbon-design-system/ibm-dotcom-library/blob/2864816/packages/web-components/src/globals/services-store/actions/tests/localeAPI.test.ts#L82
Please don't hesitate to let me know if I'm missing something. Thanks!

A couple of thoughts...
Proposal 1 feels a little boiler platey.  So if we're mock 6 different items, we'll have to make 6 deep copies?  And each new item to be mocked will need to be added.
Proposal 2: That could work.  But on the subject of 'new devs', I don't know if that strategy reduces friction uniformly for new devs since the 'auto-mock' and 'mock reset' features of jest are not uniform across testing/mocking frameworks.  But my current PR isn't using anything that shouldn't already exist in any test/mock solution.

Thank you for your additional thoughts @ccwilson-us-ibm-com!

So if we're mock 6 different items, we'll have to make 6 deep copies?

No, you can keep one deep copy the mock module and the merge it back to the mock module for re-setting it to the original (that takes care of all properties you replace for specific tests).

the 'auto-mock' and 'mock reset' features of jest are not uniform across testing/mocking frameworks.

Actually this comes from Jest out-of-the-box:
https://jestjs.io/docs/en/mock-functions#mocking-modules
https://jestjs.io/docs/en/configuration#resetmocks-boolean

Right.  They do come out of the box in Jest... but they don't in other testing/mocking frameworks... Jasmine, Sinon, etc.  As popular as it is right now, not every developer uses Jest.

I see your point. Due to other reasons I have brought up, I'm for not introducing our own additional layer to our codebase for the sake of neutralizing the differences in testing libraries. Jest is popular and well documented, and utilizing its ecosystem and documentation looks more preferable for this problem space.

Going forward as-is for now as discussed with @jeffchew. @jeffchew Does the visual difference in footer in Percy look OK to you? Thanks!

Going forward as-is for now as discussed with @jeffchew. @jeffchew Does the visual difference in footer in Percy look OK to you? Thanks!

Thanks @asudoh , I'm actually going to update the branch and rebuild and see what the new percy builds give us.


Segmentation fault when running run_finetune.py

Hi,
I just installed your DNABERT and downloaded the DNABERT6 model.
I create the conda env following all the step.
Finally, I tried to run the fine tune example, but the code ends with Segmentation fault. The error log is below. Can you please help ?
Thanks
11/30/2020 15:16:01 - WARNING - main -   Process rank: -1, device: cuda, n_gpu: 4, distributed training: False, 16-bits training: False
11/30/2020 15:16:01 - INFO - transformers.configuration_utils -   loading configuration file DNABERT/pretrained/6-new-12w-0/config.json
11/30/2020 15:16:01 - INFO - transformers.configuration_utils -   Model config BertConfig {
"architectures": [
"BertForMaskedLM"
],
"attention_probs_dropout_prob": 0.1,
"bos_token_id": 0,
"do_sample": false,
"eos_token_ids": 0,
"finetuning_task": "dnaprom",
"hidden_act": "gelu",
"hidden_dropout_prob": 0.1,
"hidden_size": 768,
"id2label": {
"0": "LABEL_0",
"1": "LABEL_1"
},
"initializer_range": 0.02,
"intermediate_size": 3072,
"is_decoder": false,
"label2id": {
"LABEL_0": 0,
"LABEL_1": 1
},
"layer_norm_eps": 1e-12,
"length_penalty": 1.0,
"max_length": 20,
"max_position_embeddings": 512,
"model_type": "bert",
"num_attention_heads": 12,
"num_beams": 1,
"num_hidden_layers": 12,
"num_labels": 2,
"num_return_sequences": 1,
"num_rnn_layer": 1,
"output_attentions": false,
"output_hidden_states": false,
"output_past": true,
"pad_token_id": 0,
"pruned_heads": {},
"repetition_penalty": 1.0,
"rnn": "lstm",
"rnn_dropout": 0.0,
"rnn_hidden": 768,
"split": 10,
"temperature": 1.0,
"top_k": 50,
"top_p": 1.0,
"torchscript": false,
"type_vocab_size": 2,
"use_bfloat16": false,
"vocab_size": 4101
}
11/30/2020 15:16:01 - INFO - transformers.tokenization_utils -   loading file https://raw.githubusercontent.com/jerryji1993/DNABERT/master/src/transformers/dnabert-config/bert-config-6/vocab.txt from cache at /home/gc223/.cache/torch/transformers/ea1474aad40c1c8ed4e1cb7c11345ddda6df27a857fb29e1d4c901d9b900d32d.26f8bd5a32e49c2a8271a46950754a4a767726709b7741c68723bc1db840a87e
11/30/2020 15:16:01 - INFO - transformers.modeling_utils -   loading weights file DNABERT/pretrained/6-new-12w-0/pytorch_model.bin
/var/spool/slurmd/job44157571/slurm_script: line 46:  9764 Segmentation fault      python DNABERT/examples/run_finetune.py --model_type dna --tokenizer_name=dna$KMER --model_name_or_path $MODEL_PATH --task_name dnaprom --do_train --do_eval --data_dir $DATA_PATH --max_seq_length 75 --per_gpu_eval_batch_size=16 --per_gpu_train_batch_size=16 --learning_rate 2e-4 --num_train_epochs 3.0 --output_dir $OUTPUT_PATH --evaluate_during_training --logging_steps 100 --save_steps 4000 --warmup_percent 0.1 --hidden_dropout_prob 0.1 --overwrite_output --weight_decay 0.01 --n_process 8

This issue seems to result from the 'slurm_script'. We do not include this component in this repo. Do you use it to run experiments on a cluster? Could you please try to run our code on a single machine first?

Hi,
thanks for the prompt reply!
I tried it by running it directly from the compute node and running the
script directly, without submitting it to the queue.
I get the same result
Best
Gianfilippo
On Mon, Nov 30, 2020 at 3:41 PM Zhihan Zhou<EMAIL_ADDRESS>wrote:

This issue seems to result from the 'slurm_script'. We do not include this
component in this repo. Do you use it to run experiments on a cluster?
Could you please try to run our code on a single machine first?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/jerryji1993/DNABERT/issues/4#issuecomment-736030355,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACPSFVARHYXWGTWYVKYXB2DSSP7PLANCNFSM4UICAHLA
.

Hi,
I will try and reinstall then environment. My default CUDA is 10.1, but for some reason, it loaded CUDA 9.2. I will post an update soon
Thanks

Hi,
ok, I reinstalled and now it is running on the compute node, if I directly
run the script. But it fails if I submit it as a job to the queue (see
below).
What do you think?
Thanks
Gianfilippo
11/30/2020 19:15:55 - WARNING - main -   Process rank: -1, device:
cuda, n_gpu: 4, distributed training: False, 16-bits training: False
11/30/2020 19:15:55 - INFO - transformers.configuration_utils -   loading
configuration file DNABERT/pretrained/6-new-12w-0/config.json
11/30/2020 19:15:55 - INFO - transformers.configuration_utils -   Model
config BertConfig {
"architectures": [
"BertForMaskedLM"

],
"attention_probs_dropout_prob": 0.1,
"bos_token_id": 0,
"do_sample": false,
"eos_token_ids": 0,
"finetuning_task": "dnaprom",
"hidden_act": "gelu",
"hidden_dropout_prob": 0.1,
"hidden_size": 768,
"id2label": {
"0": "LABEL_0",

"1": "LABEL_1"

},
"initializer_range": 0.02,
"intermediate_size": 3072,
"is_decoder": false,
"label2id": {
"LABEL_0": 0,

"LABEL_1": 1

},
"layer_norm_eps": 1e-12,
"length_penalty": 1.0,
"max_length": 20,
"max_position_embeddings": 512,
"model_type": "bert",
"num_attention_heads": 12,
"num_beams": 1,
"num_hidden_layers": 12,
"num_labels": 2,
"num_return_sequences": 1,
"num_rnn_layer": 1,
"output_attentions": false,
"output_hidden_states": false,
"output_past": true,
"pad_token_id": 0,
"pruned_heads": {},
"repetition_penalty": 1.0,
"rnn": "lstm",
"rnn_dropout": 0.0,
"rnn_hidden": 768,
"split": 10,
"temperature": 1.0,
"top_k": 50,
"top_p": 1.0,
"torchscript": false,
"type_vocab_size": 2,
"use_bfloat16": false,
"vocab_size": 4101
}
11/30/2020 19:15:55 - INFO - transformers.tokenization_utils -   loading
file
https://raw.githubusercontent.com/jerryji1993/DNABERT/master/src/transformers/dnabert-config/bert-config-6/vocab.txt
from cache at
/home/gc223/.cache/torch/transformers/ea1474aad40c1c8ed4e1cb7c11345ddda6df27a857fb29e1d4c901d9b900d32d.26f8bd5a32e49c2a8271a46950754a4a767726709b7741c68723bc1db840a87e
11/30/2020 19:15:56 - INFO - transformers.modeling_utils -   loading
weights file DNABERT/pretrained/6-new-12w-0/pytorch_model.bin
11/30/2020 19:15:58 - INFO - transformers.modeling_utils -   Weights of
BertForSequenceClassification not initialized from pretrained model:
['classifier.weight', 'classifier.bias']
11/30/2020 19:15:58 - INFO - transformers.modeling_utils -   Weights from
pretrained model not used in BertForSequenceClassification:
['cls.predictions.bias', 'cls.predictions.transform.dense.weight',
'cls.predictions.transform.dense.bias',
'cls.predictions.transform.LayerNorm.weight',
'cls.predictions.transform.LayerNorm.bias',
'cls.predictions.decoder.weight', 'cls.predictions.decoder.bias']
11/30/2020 19:16:11 - INFO - main -   Training/evaluation parameters
Namespace(adam_epsilon=1e-08, attention_probs_dropout_prob=0.1, beta1=0.9,
beta2=0.999, cache_dir='', config_name='',
data_dir='sample_data/ft/prom-core/6', device=device(type='cuda'),
do_ensemble_pred=False, do_eval=True, do_lower_case=False,
do_predict=False, do_train=True, do_visualize=False, early_stop=0,
eval_all_checkpoints=False, evaluate_during_training=True, fp16=False,
fp16_opt_level='O1', gradient_accumulation_steps=1,
hidden_dropout_prob=0.1, learning_rate=0.0002, local_rank=-1,
logging_steps=100, max_grad_norm=1.0, max_seq_length=75, max_steps=-1,
model_name_or_path='DNABERT/pretrained/6-new-12w-0', model_type='dna',
n_gpu=4, n_process=8, no_cuda=False, num_rnn_layer=2, num_train_epochs=3.0,
output_dir='./ft/prom-core/6', output_mode='classification',
overwrite_cache=False, overwrite_output_dir=True,
per_gpu_eval_batch_size=16, per_gpu_pred_batch_size=8,
per_gpu_train_batch_size=16, predict_dir=None, predict_scan_size=1,
result_dir=None, rnn='lstm', rnn_dropout=0.0, rnn_hidden=768,
save_steps=4000, save_total_limit=None, seed=42, server_ip='',
server_port='', should_continue=False, task_name='dnaprom',
tokenizer_name='dna6', visualize_data_dir=None, visualize_models=None,
visualize_train=False, warmup_percent=0.1, warmup_steps=0,
weight_decay=0.01)
11/30/2020 19:16:11 - INFO - main -   Loading features from cached file
sample_data/ft/prom-core/6/cached_train_6-new-12w-0_75_dnaprom
11/30/2020 19:16:14 - INFO - main -   ***** Running training *****
11/30/2020 19:16:14 - INFO - main -     Num examples = 53277
11/30/2020 19:16:14 - INFO - main -     Num Epochs = 3
11/30/2020 19:16:14 - INFO - main -     Instantaneous batch size per
GPU = 16
11/30/2020 19:16:14 - INFO - main -     Total train batch size (w.
parallel, distributed & accumulation) = 64
11/30/2020 19:16:14 - INFO - main -     Gradient Accumulation steps = 1
11/30/2020 19:16:14 - INFO - main -     Total optimization steps = 2499
11/30/2020 19:16:14 - INFO - main -     Continuing training from
checkpoint, will skip to saved global_step
11/30/2020 19:16:14 - INFO - main -     Continuing training from epoch 0
11/30/2020 19:16:14 - INFO - main -     Continuing training from global
step 0
11/30/2020 19:16:14 - INFO - main -     Will skip the first 0 steps in
the first epoch
Iteration:   0%|          | 0/833 [00:04<?, ?it/s]
Epoch:   0%|          | 0/3 [00:04<?, ?it/s]?it/s]
Traceback (most recent call last):
File "DNABERT/examples/run_finetune.py", line 1280, in
main()

File "DNABERT/examples/run_finetune.py", line 1095, in main
global_step, tr_loss = train(args, train_dataset, model, tokenizer)

File "DNABERT/examples/run_finetune.py", line 272, in train
outputs = model(**inputs)

File
"/user/conda_envs/dnabert/lib/python3.6/site-packages/torch/nn/modules/module.py",
line 727, in _call_impl
result = self.forward(*input, **kwargs)

File
"/user/conda_envs/dnabert/lib/python3.6/site-packages/torch/nn/parallel/data_parallel.py",
line 161, in forward
outputs = self.parallel_apply(replicas, inputs, kwargs)

File
"/user/conda_envs/dnabert/lib/python3.6/site-packages/torch/nn/parallel/data_parallel.py",
line 171, in parallel_apply
return parallel_apply(replicas, inputs, kwargs,

self.device_ids[:len(replicas)])
File
"/user/conda_envs/dnabert/lib/python3.6/site-packages/torch/nn/parallel/parallel_apply.py",
line 86, in parallel_apply
output.reraise()

File
"/user/conda_envs/dnabert/lib/python3.6/site-packages/torch/_utils.py",
line 428, in reraise
raise self.exc_type(msg)

StopIteration: Caught StopIteration in replica 0 on device 0.
Original Traceback (most recent call last):
File
"/user/conda_envs/dnabert/lib/python3.6/site-packages/torch/nn/parallel/parallel_apply.py",
line 61, in _worker
output = module(*input, **kwargs)

File
"/user/conda_envs/dnabert/lib/python3.6/site-packages/torch/nn/modules/module.py",
line 727, in _call_impl
result = self.forward(*input, **kwargs)

File "/user/Chris/DNABERT/src/transformers/modeling_bert.py", line 1187,
in forward
inputs_embeds=inputs_embeds,

File
"/user/conda_envs/dnabert/lib/python3.6/site-packages/torch/nn/modules/module.py",
line 727, in _call_impl
result = self.forward(*input, **kwargs)

File "/user/Chris/DNABERT/src/transformers/modeling_bert.py", line 745,
in forward
extended_attention_mask = extended_attention_mask.to

(dtype=next(self.parameters()).dtype)  # fp16 compatibility
StopIteration
On Mon, Nov 30, 2020 at 4:59 PM Zhihan Zhou<EMAIL_ADDRESS>wrote:

Hi,
It is hard to locate the problem since there are too many possible things
that more result in the Segmentation fault. From the output log, the
program seems to break at line 1088, which is model.to(args.device). I
suspect it results from cuda/pytorch/nvidia-driver. What are the versions
of them?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/jerryji1993/DNABERT/issues/4#issuecomment-736081426,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACPSFVFFLMVY7XVVAGTGCI3SSQISPANCNFSM4UICAHLA
.

Hi,
This looks like a problem of Dataparallel. When you submit it to a queue, does it run on a single machine or run on multiple nodes distributedly?

Hi,
I submit to run on a single gpu enabled node
Gianfilippo
On Mon, Nov 30, 2020 at 10:09 PM Zhihan Zhou<EMAIL_ADDRESS>wrote:

Hi,
This looks like a problem of Dataparallel. When you submit it to a queue,
does it run on a single machine or run on multiple nodes distributedly?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/jerryji1993/DNABERT/issues/4#issuecomment-736188172,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACPSFVBRVO5YEXEJM2WIABTSSRM75ANCNFSM4UICAHLA
.

Hi,
Does the machine you running on has multiple gpus? If yes, this may result from the multi-gpu issue. In our code(line 1013), we calculate the n_gpu with torch.cuda.device_count(). If n_gpu is larger than 1, we use Dataparallel to run the model on multiple gpus. Maybe you should manually set the arg.n_gpu to 1.

Hi,
you are right, the issue is related to multi-gpu usage. I submitted to a single GPU and it seems to be ok.
What do you think the problem is with multi-gpu ? as far as I know Dataparallel should work.

Hi,
I think this may be related to the accessibility of GPUs. The code utilizes all the available GPUs by default. In most cases, all the available GPUs should be able to access. However, in your case, it can see multiple GPUs but can only access one of them. This may result in the problem. So maybe you should somehow specify the ID of GPUs that you want this model to use.

Hi,
it seems reasonable. I will need to find time to look into this
Thanks for your help

@gianfilippo did you end up resolve this issue? We are having the exact same problem, and any help would be greatly appreciated!

Hi,
I did not solve the issue within the code, as I have to move forward with the project.
I simply specify a single GPU when I submit the job. This is good enough for me, at this point
Best


How to add spaces in the app name?

If I create a new app via react-native init MyTestApp, I wouldn't want the actual app name to be "MyTestApp," but rather "My Test App." When I go into Build Settings in Xcode and go to Packaging > Product Name, I can change it to "My Test App," but when I try to build the app, I get an error:
ld: warning: directory not found for option '-F/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator9.2.sdk/Developer/Library/Frameworks'
ld: file not found: /Users/samh/Library/Developer/Xcode/DerivedData/MyTestApp-aomfrqfmwrvikjdpidmyuvhkqdrg/Build/Products/Debug-iphonesimulator/MyTestApp.app/MyTestApp
clang: error: linker command failed with exit code 1 (use -v to see invocation)

This fails because the actual file being built is Debug-iphonesimulator/My Test App.app/My Test App. Am I doing something wrong here? Xcode is like a labyrinth of settings.

To update the name shown on the home screen under the app icon you need to change the Bundle display name property in the info.plist file for the project in xcode.If it is not present then add a new key for it

There's an awesome place to post code / ask question first before filing an issue: StackOverflow. It's the best system for Q&A. Many people from the community hang out there and will be able to see and answer your question. This lets us use the github bug tracker for bugs.
I'm posting this here because github issues haven't been working very well for us and because StackOverflow is so much better. Thanks for reading! :)


Add an option to not show update version box every time when the tool is opened

Add a checkbox option to not show an update version dialog box every time the user opens the tool.

Please refer to commit number c82bb331fe11150f920406a53f83c99b07b02a7e and df6be8319e17de32006c15c2be1ffc1d8f7c5d1e.


Laravel 11.x Shift

This pull request includes the changes for upgrading to Laravel 11.x. Feel free to commit any additional changes to the shift-117569 branch.
Before merging, you need to:

Checkout the shift-117569 branch
Review all pull request comments for additional changes
Run composer update (if the scripts fail, try with --no-scripts)
Clear any config, route, or view cache
Thoroughly test your application (no tests?, no CI?)

If you need help with your upgrade, check out the Human Shifts.

:information_source: To slim down the Laravel installation, Laravel 11 no longer has most of the core files previously included in the default Laravel application. While you are welcome to publish and customize these files, they are no longer required.
Shift takes an iterative approach to removing core files which are not customized or where its customizations may be done elsewhere in a modern Laravel 11 application. As such, you may see some commits removing files and others re-registering your customizations.

:x: Shift could not upgrade the following files since they differed from the default Laravel version. You will need to compare these files against the default Laravel 11 versions and merge any changes:

[ ] lang/en/validation.php

:information_source: Laravel 11 no longer requires you to maintain the default configuration files. Your configuration now merges with framework defaults.
Shift streamlined your configuration files by removing options that matched the Laravel defaults and preserving your true customizations. These are values which are not changeable through ENV variables.
If you wish to keep the full set of configuration files, Shift recommends running artisan config:publish --all --force to get the latest configuration files from Laravel 11, then reapplying the customizations Shift streamlined.

:information_source: Shift detected customized options within your configuration files which may be set with an ENV variable. To help keep your configuration files streamlined, you may set the following variables. Be sure adjust any values per environment.
APP_NAME=Apiary
APP_TIMEZONE=America/New_York
ARGON_MEMORY=1024
ARGON_THREADS=2
ARGON_TIME=2
AUTH_PASSWORD_RESET_TOKEN_TABLE=password_resets
BCRYPT_ROUNDS=13
CACHE_STORE=file
DB_CONNECTION=mysql
LOG_STACK=stderr
MAIL_MAILER=smtp
QUEUE_CONNECTION=sync
SESSION_DRIVER=file

Note: some of these may simply be values which changed between Laravel 10 and Laravel 11. You may ignore any ENV variables you do not need to customize.

:warning: Laravel 11 automatically discovers policies scanning your application's Policies directory at or above the directory containing your models.
Shift detected policies registered with the policies property of your AuthServiceProvider. If any of these policies can not be automatically discovered, you may register them manually using Gate::policy() in your AppServiceProvider.

:x: The bootstrap/app.php file has been completely rewritten in Laravel 11 to allow configuring your Laravel application in a single location. Shift overwrote your file, but detected it may have contained customizations. You should review the diff to see if any of your customizations are still needed.

:warning: Laravel 10 has added a return type of array to the Event broadcastOn and Notification via methods. However, you may still return a single channel from these methods.
Shift added the array return type to these methods in the following classes. You should review them to ensure you are returning an array, or remove the return type.

[ ] app/Notifications/Dues/PackageExpirationReminder.php
[ ] app/Notifications/Dues/PaymentReminder.php
[ ] app/Notifications/Dues/SummaryNotification.php
[ ] app/Notifications/Dues/TransactionReminder.php
[ ] app/Notifications/ExpiringPersonalAccessTokenNotification.php
[ ] app/Notifications/GlobalAttendanceNotification.php
[ ] app/Notifications/MembershipAgreementDocuSignEnvelopeReceived.php
[ ] app/Notifications/PaymentReceipt.php
[ ] app/Notifications/TeamAttendanceNotification.php
[ ] app/Notifications/Travel/AllTravelAssignmentsComplete.php
[ ] app/Notifications/Travel/DocuSignEnvelopeReceived.php
[ ] app/Notifications/Travel/TravelAssignmentCreated.php
[ ] app/Notifications/Travel/TravelAssignmentReminder.php

:x: The app/Console/Kernel.php file has been removed in Laravel 11. Shift overwrote your file, but detected it may have contained customizations. You should review the diff to see if any of your customizations are still needed. If so, you may re-apply them to the routes/console.php file or the new bootstrap/app.php file. Review the documentation for additional details.

:information_source: Shift updated your dependencies for Laravel 11. While many of the popular packages are reviewed, you may have to update additional packages in order for your application to be compatible with Laravel 11. Watch dealing with dependencies for tips on handling any Composer issues.
The following dependencies were updated by a major version and may have their own changes. You may check their changelog for any additional upgrade steps.

[ ] barryvdh/laravel-ide-helper
[ ] beyondcode/laravel-dump-server
[ ] chelout/laravel-relationship-events
[ ] laravel/passport
[ ] subfission/cas

:information_source: The base Controller class has been marked as abstract in Laravel 11, with its traits and inheritance removed. This is to prevent using this base controller directly and to use facades instead of the trait methods.
Shift detected your base controller did not have any public methods, so it was safe to mark as abstract. However, since you may be using trait methods within your controllers, Shift did not remove them. If you know you are not using any trait methods or want to refactor to facades, you may remove them manually.

:information_source: Starting with Laravel 10, PHP type hints were added within classes included in a Laravel application. In an effort to modernize your code, Shift automated this change where Laravel strictly specifies a type. If you prefer not to type hint your code you may revert this commit by running: git revert b7dd401f

:x: Laravel 11 has removed its dependency on doctrine/dbal. As such, all of Laravel's classes and methods related Doctrine DBAL have been removed.
Shift detected potential uses of these within the following files. You should review these instances and, if they are still needed, reference the Upgrade Guide for native alternatives.

[ ] database/migrations/2023_01_15_141511_remove_autodesk_and_middle_name_from_users.php

:warning: In Laravel 11, changing a column now requires you to include all the modifiers you want to keep on the column definition after it is changed. Any missing attributes will be dropped. This change may cause unexpected behavior if you were to run pending or old migrations.
Shift detected potential uses of the change method within your migrations. While you may go back and update these migrations, you may wish to simply squash your old migrations. This will not only avoid rework, but may also improve the performance of your test suite.

:warning: The CreatesApplication testing trait has been removed in Laravel 11. Its createApplication method is now defined in the TestCase class. To avoid a conflict, Shift removed this method from your CreatesApplication trait. You should review this change to see if you need any code from the original method.

:warning: Many first-party Laravel packages, as well as community packages, removed their ignoreMigrations method since they no longer load migrations automatically. Shift detected calls to this method in the following files. You should review these instances to see if they may be removed.

[ ] app/Providers/AppServiceProvider.php

:warning: Many first-party Laravel packages no longer load their migrations automatically. Instead, you may need to publish their migrations to your application if you have not already done so. Shift detected you are using Passport. You may run the following command to publish their migrations:
php artisan vendor:publish --tag=passport-migrations

:warning: Previously, Laravel would append a colon (:) to any cache key prefix for DynamoDB, Memcache, or Redis. Laravel 11 no longer appends a colon to your cache key prefix. If you are using one of these stores, you should append a colon to your prefix to avoid invalidating your cache.

:information_source: Laravel 11 now updates the timestamp when publishing vendor migrations. This may cause problems in existing applications when these migrations were previously published and ran with their default timestamp.
To preserve the original behavior, Shift disabled this feature in your database.php configuration file. If you do not have any vendor migrations or have squashed all of your existing migrations, you may re-enable the update_date_on_publish option. If this is the only customization within database.php, you may remove this configuration file.

:warning: Many of the default drivers changed in Laravel 11. For example, the default database driver is sqlite and the default cache store is database. If you experience errors setting up your environment, be sure you have properly set your ENV variables for these drivers. If you wish to adopt the new defaults, you may follow the documentation to set them up for your application.

:information_source: All of the underlying Symfony components used by Laravel have been upgraded to Symfony 7.0. Shift detected references to Symfony classes within your application. These are most likely type hints and can safely be ignored. If you are using Symfony classes directly or experience issues relating to Symfony, you should review the Symfony change log for any additional changes.

:warning: Laravel 11 now includes a database driver for MariaDB. Previously the MySQL driver offered parity with MariaDB. However, with MariaDB 10.1, there are more database specific features available. If you are using MariaDB, you may want to evaluate this new mariadb driver after completing your upgrade to Laravel 11.

:warning: Shift detected you are using a Laravel package like Horizon or Nova which may need to have its published assets regenerated after upgrading. Be sure to use artisan to republish these assets as well as php artisan view:clear to avoid any errors.

:warning: Laravel 11 has a nesbot/carbon dependency of ^2.72|^3.0.  Shift detected you are using these methods within your application. While you may try to downgrade to Carbon 2, Shift recommends you review the Carbon migration notes and complete the upgrade to Carbon 3.0.

:tada: Congratulations, you're now running the latest version of Laravel!
Next, you may optionally run the following Shifts to ensure your application is fully upgraded, adopts the latest Laravel conventions, and easier to maintain in the future:

Laravel Fixer automatically updates your code to the latest Laravel conventions.
Tests Generator intelligently generates model factories, HTTP Tests, and configuration for your application.
CI Generator intelligently generates CI jobs to lint PHP, check code style, and run tests, including Dusk.

You may also use the Shift Workbench to automate common tasks for maintaining your Laravel application.

:x: PHP syntax errors were detected after running your Shift. Often these are simply differences between the PHP version on the Shift server (8.2) and your project. Occasionally they are misplaced lines or duplicate import statements.
You may quickly check the PHP syntax locally by running php -l on the following files:

[ ] routes/console.php


Able to wrap the byte array or ByteBuffer without copying in the new Buffer API in the Netty 5

In Netty 4, there are Unpooled.wrappedBuffer APIs below which could wrap the byte[] or ByteBuffer without copying.
In Netty 5, it seems we need to use the DefaultBufferAllocators.xxxAllocator().copyOf() now which copies the data once.
I have some direct ByteBuffers and some byte arrays and now I need to copy them once when using the Buffer API, which is not needed in Netty 4.
public static ByteBuf wrappedBuffer(byte[] array)
public static ByteBuf wrappedBuffer(byte[] array, int offset, int length)
public static ByteBuf wrappedBuffer(ByteBuffer buffer)
...

Would it be possible to add similar APIs in the Netty 5 with the new Buffer API?
In this case, the API can require the user that they are transferring the ownership of these byte arrays or ByteBuffers data and won't edit them anymore.
I feel this is needed because

Without a way to warp it and need to always copy it once, it hurts performance.
There is a Buffer#forEachReadable which could get the underhood byte[] or ByteBuffer but there is no counterpart to wrap them into Buffer which seems odd.
In some cases, we can guarantee that we won't edit these byte[] or the ByteBuffer anymore and would like to transfer the ownership into the Netty framework and there is no need to copy.

Example use case:
In some high-level framework that uses the Netty 5 under the hood. The framework API or the user code might use/provide the byte[] or direct ByteBuffer data (because these types are common in other Java libraries), and now I need to copy them once when using Netty 5 to send them.
Expected behavior
Wrap the byte array or ByteBuffer in Buffer without copying.
Actual behavior
Need to use DefaultBufferAllocators.offHeapAllocator().copyOf(byteBuffer) which need copy once.
Netty version
5.0.0.Alpha4

It's available but hidden, because it's unsafe in the sense that we'll have to take the programmers word that the array won't be shared.
What you need is in MemoryManager.instance().unsafeWrap(byte[]). That will create an unpooled buffer with the given array inside.

@chrisvest Thanks for the info.
May I ask one more question? Is there any way to wrap a direct ByteBuffer too? So when sending, it only needs to copy the ByteBuffer to the kernel once. Otherwise, I need to copy this into the off-heap Buffer, and then it needs to copy into the kernel which uses two copies here.

@floating-cat No, there's no way to wrap a direct ByteBuffer. You can allocate off-heap netty buffers from the start, and get direct buffers from them.

@chrisvest imho we should provide one..

@chrisvest Unfortunately, this way doesn't solve my use case. I have a framework that uses Netty and it gets all buffers produced from the Netty and wraps it in some byte[] and ByteBuffer or a composite wrapper (wrap multi byte[], ByteBuffer) to provide a high-level API (because these types are more common to use with other libraries and in JVM ecosystem). Then we could check these bytes data, produce new data (e.g. a new direct ByteBuffer), or just forward the original bytes data into Netty 5.
Now:

If we provide a direct ByteBuffer, it needs to copy into off-heap Buffer in Netty 5, which use one more copy.
If I just forward the original ByteBuffer (got from Buffer.forEachWritable before), I need to copy them.
If I produce a new byte[] with a offset, the MemoryManager.instance().unsafeWrap(byte[]) doesn't help and I need to copy them too.

I could just provide a wrapper of the Buffer as a high-level API but if force everyone to learn how to use Buffer or a new API and unable to work with other libraries well.
I suspect I am not the only one have this use case because nowadays a lot of frameworks use Netty under the hood which provides high-level APIs and need to refeed these data type back to Netty. Or maybe there is a better way to solve this issue instead of using the wrapper?
In the old API, we could wrap them in several ways or can even warp the array of the byte[] and ByteBuf (let the user indirect use the feature provided from CompositeBuffer/CompositeByteBuf) which are really flexible:
static ByteBuf | wrappedBuffer(byte[]... arrays)
static ByteBuf | wrappedBuffer(byte[] array)
static ByteBuf | wrappedBuffer(byte[] array, int offset, int length)
static ByteBuf | wrappedBuffer(ByteBuf... buffers)
static ByteBuf | wrappedBuffer(ByteBuf buffer)
static ByteBuf | wrappedBuffer(ByteBuffer... buffers)
static ByteBuf | wrappedBuffer(ByteBuffer buffer)
static ByteBuf | wrappedBuffer(int maxNumComponents, byte[]... arrays)
static ByteBuf | wrappedBuffer(int maxNumComponents, ByteBuf... buffers)
static ByteBuf | wrappedBuffer(int maxNumComponents, ByteBuffer... buffers)
static ByteBuf | wrappedBuffer(long memoryAddress, int size, boolean doFree)

Just found it is easy to just wrap Buffer via an adapter pattern in my code and expose it into a high-level API so I don't need to wrap/extract the baked btyte[] and ByteBuffer to/from Buffer anymore and I also don't need to care the Buffer backed implementation (or even MemorySegment in the future) which is more elegant. Thanks for all your's help!


sbcl: enable linkable runtime on aarch64-linux

Linkable runtime seems to be working fine on aarch64-linux too, therefore I think it would be wise to enable it.
I also ran nixpkgs-fmt on the file.
Motivation for this change
Things done

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.05 Release notes)

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

[ ] Fits CONTRIBUTING.md.

OfBorg says that SBCL says that linkable runtime is not supported on this arch…

Hmm, I see. Will investigate this further, but closing this atm.
Seems like this feature is working on aarch64, but SBCL have to be patched in order to make it compile. The best approach is probably to wait for this to be fixed upstream. Patching it here would probably just result in a lot of future headache etc.


Will you provide extrinsics parameters of cameras?

Hi, thanks for providing this dataset. Besides intrinsics parameters, will you also provide the extrinsics parameters of the cameras?

the camera and lidar are coaxial so no extrinsic calibration necessary. For a given scan, the frames are all taken from the same point, so translation is zero, and the camera rotation can be obtained from file names (azimuth/elevation)


Added duplicate initialization check for plugins.

Fixes the issue in #6413:

Under certain conditions a channel could be initialized twice leading to double free issues.
Prevent this by checking the device has not been initialized yet.

@mfleisz I don´t think so (at least not in a manner we can backport to 2.0)

@akallabeth That is true ...


Reduce server hits with JS history API

This patch aims to speed up page loads by removing the extra hit required by a 301 redirect.
The patch loads the requested page/post on the shortlink, the JavaScript history.replaceState function is used to display the canonical URL to the visitor.
Individual results may vary but on my server it looks like it will save around 500ms.

I think an action to replace the default redirect still makes sense. There are two options:

add a hum_pre_redirect action before the wp_redirect
replace the wp_redirect with a hum_process_redirect and move the wp_redirect to a default handler

What do you think?

Yeah. I haven't had a chance to work on this but coincidently going on a WP dev weekend this weekend so will add it to the list :)

I'm fine with either of @pfefferle's options (you guys pick).  I would also note however that the overhead of returning a 301 redirect and making a second HTTP request should be completely negligible with HTTP/2.


Use Extractor for Location Extraction

Currently there are some classes that are parsing the locations by the coordinates field(for example geoTimePeriodController of the restService). These classes should be updated to use the Extractor instead.
The Unit tests of these classes should be updated as well.
@ChrizZz110
@MrBlaTi
@loewenzahm
Especally for your current projects this could be interesting.

Done in GeoTemporalKey and GeoTemporalKeyTest.

what if the coordinates are located in the "geo" field? as I recall, that was a possibility as well

Geo was deprecated by Twitter. See issue 34

Done in areacalc


Make sure both 'settings' and 'builders' are in the YAML.

That is, don't fall back to empty defaults for them.  This
is important in case users provide their own YAML configuration,
but have a typo in them (like 'biulders' instead of 'builders').
With the default of an empty dict, the builders would just be
skipped completely, and could lead to hard-to-debug issues.
At least with this PR it would be louder.
Signed-off-by: Chris Lalancette<EMAIL_ADDRESS>@wjwwood @tfoote This seems fairly harmless to me, but an opinion on whether this is the right way to go is appreciated.

The biggest question is at some point do we see the default builder(s) changing at some point down the line. If so having everyone hardcoded with the current defaults will make that transition much harder. On the flip side, they will keep working if the new builders need a migration. I agree that we should have an error the extra key rejection could cover that case, in which case I'd probably lean towards suggesting that approach instead of adding more required things that might need migrating in the future. We should probably also make sure that the "default builders (x y z) selected due to no config element in the yaml" message be printed promenantly for visibility/discoverability.

Just to be clear, this PR doesn't change anything about the default behavior, just the behavior when the user specifies a config file.  Some examples:

Scenario
Before this PR
after this PR

No rosdoc2.yaml specified
Use default builders (doxygen and sphinx)
Use default builders (doxygen and sphinx)

rosdoc2.yaml specified with 'settings' and 'builders'
Use builders specified by user
Use builders specified by user

rosdoc2.yaml specified with no 'builders' and no 'settings'
Use default settings, don't run any builders
Error

rosdoc2.yaml specified with 'builders' but no 'settings'
Use builders specified by user, and default for settings
Error

rosdoc2.yaml specified with 'settings' but no 'builders'
Don't run any builders
Error

Because of that, I think it is still easy to change the default set of builders in the future.  The only thing this PR makes is so that once you specify something in rosdoc2.yaml, you have to specify everything.  We could think about making this a little less explicit, but I feel like that is easy enough to do later.  So I'm going to go ahead and merge this for now, thanks for the conversation.


Please invite me to the GitHub Community Organization

Name
victorpreston
Discord Username (if applicable)
victorpreston
Additional Context
I would like to be part of this incredible community.
I met JD Studio on GitHub.

It's great having you contribute to this project
If you would like to continue contributing to open source and would like to do it with an awesome inclusive community, you should join our Discord Server and our GitHub Organisation - we help and encourage each other to contribute to open source little and often 🤓 . Any questions let us know.

Please check your email or organisation page 🙏


Update sbt to 1.5.5

Updates org.scala-sbt:sbt from 1.5.4 to 1.5.5.
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.scala-sbt", artifactId = "sbt" } ]

labels: library-update, semver-patch

Codecov Report

Merging #121 (7ab2f49) into master (8ddb6c1) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##            master      #121   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files            2         2
  Lines           35        35
  Branches         2         4    +2
=========================================
  Hits            35        35

Continue to review full report at Codecov.

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


The “left” “right” “center” label in Open Editors take too much space

If you split your editor (which is common when using a wide screen), two rows are used.
Maybe you can replace text labels with a horizontal line.

UX meeting notes
We will address this issue in a future overhaul of how we handle global commands throughout the product, as well as some refinements to our debugging experience.
Please see UX meeting notes in #9506 for more info.

This feature request will not be considered in the next 6-12 months roadmap and as such will be closed to keep the number of issues we have to maintain actionable. Thanks for understanding and happy coding!


Consent management

This request is based on my reading the ReadMe for this project and the functions offered. I've been using this solution for a year, and need to implement consent management. Maybe I simply haven't found the already existing solution, in which case I'm sorry, please let me know where I can find docs about it.
Is your feature request related to a problem? Please describe.
I can't find in the documentation how to use the Analytics param ANALYTICS_STORAGE
The objective is to manage consent, but still send anonymized data when consent is denied.
Describe the solution you'd like
Ideally: the whole consent management could be integrated
Describe alternatives you've considered
Realistically: access to set, read and update consent params such as

AD_PERSONALIZATION | Sets consent for personalized advertising.
AD_STORAGE | Enables storage (such as device identifiers) related to advertising.
AD_USER_DATA | Sets consent for sending user data to Google for advertising purposes.
ANALYTICS_STORAGE | Enables storage (such as app identifiers) related to analytics, e.g. visit duration.

Additional context
The objective is to manage consent, but still send anonymized data when consent is denied. This is already possible on the web with GA4 and GTM, but GTM is not available on Ionic/Capacitor/React (i haven't found any solution anyway)
The web solution sends "pings" with limited data when consent was denied, so the data is still usable.
Docs: https://firebase.google.com/docs/reference/kotlin/com/google/firebase/analytics/FirebaseAnalytics.ConsentType
Thank you for reading me!

@robingenz Thank you!

I will release this feature for @capacitor-firebase/analytics in the next weeks.

Has this been pushed to production builds yet? I can´t find it in the documentation.

@piotrblasiak Not for this plugin but for @capacitor-firebase/analytics.


Add support to vagrant-proxyconf plugin

This PR allows users to configure proxy with the help of a .zulip-vagrant-config file so that there is no need to maintain a patched vagrant file.
More details on https://github.com/zulip/zulip/pull/642

Automated message from Dropbox CLA bot
@hackerkid, it looks like you've already signed the Dropbox CLA. Thanks!

@timabbott What do you think about this :smile: ?

Generally looks good; I posted a few comments.  @lfaraone do you have any thoughts on what config file format we should use?

@timabbott I have fixed the merge conflicts.

Thanks @hackerkid !  I merged this after making a few small tweaks to the docs, comments, etc.


Sponsoring support

Great work!
What is the best way to support the project economically? Have you considered applying for Github's sponsor program?

Oh thats very kind of you :)
I just applied for the sponsorship program.

Just got approved, but no pressure, just because you asked <3


Added node aligning options for selected nodes & shortcuts

I re-added the functionality from the latest master and refactored it and also added shortcuts.
I deleted the other PR.

 Here is an overview of what got changed by this pull request:

Issues
======
- Added 2

Complexity increasing per file
==============================
- Assets/com.alelievr.NodeGraphProcessor/Editor/Views/BaseNodeView.cs  3

See the complete overview on Codacy

All good, thanks !


refactor: update maintainers list, introduce isTscMember key, and remove tsc_member.json file

Description
This PR updates the  maintainers list by introducing a new file called Maintainers.json and removing the old tsc_member.json file. The new Maintainers.json file contains the same data as the previous tsc_member.json, but with the addition of a new boolean key called isTscMember. This key indicates whether a maintainer is a member of the TSC or not.
To reflect this change on the website, the Maintainers.json file is called in a React component and filtered so that only maintainers whose isTscMember value is true are displayed.

I think this PR can come hand in hand with changes from community repo
so remove tsc members doc, and operate already on maintainers file, just in UI code you will need to make sure that from maintainers.yml you read only the ones that are marked as maintainers

I would like to clarify a few points regarding the comment :

Please provide more information about the changes you are referring to from the community repo.
The maintainers.yml file could be modified to only include maintainers' information or a new key such as "IsMaintainer" could be added.
How should the decision be made regarding who will be the maintainer of the repository?

@14Richa there is a merge conflict that you need to address
since you remove tsc member json, but it was just updated in master, you need to confirm removal basically

/rtm

/rtm


Fix DocumentDB imports

Changed import of DocumentDB classes and namespaces, because the actual imports does not match those on the Typescript typings, and provokes build errors.

Pull Request Test Coverage Report for Build 684

1 of 2 (50.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 70.183%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

libraries/botbuilder-azure/src/cosmosDbStorage.ts
1
2
50.0%

Totals

Change from base Build 681:
0.0%

Covered Lines:
2018

Relevant Lines:
2752

💛  - Coveralls


[Python] How to get the depth images

Hi, I'm a beginner.
I'm trying to get both RGB and depth images during simulation. Here is my way:
I use the function mjr_readPixels similar to the render_test.py.
 self.context = mujoco.MjrContext(self.model, mujoco.mjtFontScale.mjFONTSCALE_100)
mujoco.mjr_render(self.viewport, self.scene, self.context)
upside_down_image = np.empty((self.image_height, self.image_width, 3), dtype=np.uint8)
upside_down_depth = np.empty((self.image_height, self.image_width, 1))
mujoco.mjr_readPixels(rgb=upside_down_image, depth=upside_down_depth, viewport=self.viewport, con=self.context)

The RGB images can be well obtained but the depth images can not.
Is there something wrong with my usage? Is it because of the python bindings? Any help would be appreciated.

Check out our tutorial in the dm_control repo. Depth rendering is covered there, I believe.

这是系统自动回复邮件。我已经收到了您的邮件并会尽快回复。麻烦您耐心等待。

Hi, you can obtain both images changeing the mode='human' to 'depth_array' on the render() function. You will receive a tuple with both arrays

Hi, you can obtain both images changeing the mode='human' to 'depth_array' on the render() function. You will receive a tuple with both arrays
Did you mean the function in mujoco-py?

@Zialo Did you mean the function in mujoco-py?

That's it. The function within mujoco_env.py

Thanks! I use the render() function in dm_control right now, which can also obtain both arrays


fix: :bug: documentation not working in attribute

Before:

The hint for the attribute is Custom Vue component property .

After

Show correct documentation generated by Unocss.

Reason

After debugging, I found that there are multiple targetPointer here, but only the first one is used, which is WebSymbolDocumentationTarget , so changing the order of UnocssDocumentTargetProvider can solve this problem.

thanks


Multilayer Decoding Support

FFMS2 is about to get support Multilayer Decoding Support. If it does this will no longer be the best source unless also implemented here.
Implement it as a selection of which layer to decode instead of the cluttered mess proposed for FFMS2.

Done, if the view ids aren't 0..N discovering is hard but this is good enough until someone complains


Date is shown in UTC in the status bar

Title says it all

Hopefully fixed, needs to be tested.

Everything seems hunky-doory!


base64 decode fail.

while i try to run genpac,  the wrong messages is "base64 decode fail."
maybe the problem happned in core.py where try to decode the content, but i don't know how to solve it.

gfwlist maybe downloads fail.

I run wget https://raw.githubusercontent.com/gfwlist/gfwlist/master/gfwlist.txt and download the file to local and it also says base64 decode fail..

same problem.
ubuntu 17.10
genpac 1.4.1
run following command
$ genpac --proxy="SOCKS5 <IP_ADDRESS>:1080" --gfwlist-proxy="SOCKS5 <IP_ADDRESS>:1080" -o autoproxy.pac --gfwlist-url="https://raw.githubusercontent.com/gfwlist/gfwlist/master/gfwlist.txt" base64 decode fail.
I can download gfwlist manually.

base64 decode fail， ubuntu 17.04,  genpac 1.4.1

Same problem.
Ubuntu 16.04
genpac 1.4.1
python2.7.12
$ genpac -p "SOCKS5 <IP_ADDRESS>:1080"
base64 decode fail.

Download gfwlist.txt manually but get the same result.
$ genpac -p "SOCKS5 <IP_ADDRESS>:1080" --gfwlist-local=gfwlist.txt
base64 decode fail.

Change genpac to latest development version by running
pip install https://github.com/JinnLynn/genpac/archive/master.zip
solved my problem.


Labels and Selectors

Labels give you a way to associate free form metadata with Pachyderm objects, labels are simple key value pair associations. i.e. foo=bar. For example you could tag commits that are known to represent a good state as state=good. Or tag files with a particular trait, i.e. content=cat. You can then perform selections on these labels, for example list commit <repo> -l state=good would list only commits that are tagged as being in a good state. Fortunately we wouldn't need to develop the semantics for this because it already exists in Kubernetes, so we can just borrow it from them. Read more about it here: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/

@gg do you feel like this would cover the use case described in #3598? I feel like these are more flexible and you can do mostly the same stuff with them. For example if you want to tag a commit you can tag it by adding a label tag=good-commit, the only thing that's different from what you describe is that the tag isn't unique, so if you tag another commit with tag=good-commit it won't take away the other tag. However I think in most cases that's more useful, because then you can easily list out all of the commits that were tagged as good and pick the one you want, normally that'll be the most recent one.

Thinking about this some more, I think file labels are going to be a really powerful feature. They allow us to augment globbing a very natural way because selectors are basically an alternative to globbing that gives you more explicitly control. Globbing is essentially a way to define a predicate over filenames using a string, we apply that predicate to each file in a repo and the ones that match make up the datums for the job. Selectors are analogous in that they let you define a predicate over files using a string. For example if we could allow people to pass something like content=cat in place of their glob pattern and have their datums be only the files which contain a cat. To unify the 2 concepts I think it probably makes sense to think of the name as just a special label (literally called name) which every object has to have. That means that a glob pattern of /* would be equivalent to a selector of name=/*. Getting this to work would require extending label selectors to accept globs instead of just strings, but that should be a fairly natural extension.