Unable to use the HAC's integration. "Cannot connect error"

Version of the custom_component
2.2.0

Configuration

detectors:
  cpu1:
    type: cpu
    num_threads: 3
  cpu2:
    type: cpu
    num_threads: 3

mqtt:
  host: <IP_ADDRESS>
  user: mqtt-user
  password: password

birdseye:
  # Optional: Enable birdseye view (default: shown below)
  enabled: True
  # Optional: Width of the output resolution (default: shown below)
  width: 1920
  # Optional: Height of the output resolution (default: shown below)
  height: 1080
  # Optional: Encoding quality of the mpeg1 feed (default: shown below)
  # 1 is the highest quality, and 31 is the lowest. Lower quality feeds utilize less CPU resources.
  quality: 8
  # Optional: Mode of the view. Available options are: objects, motion, and continuous
  #   objects - cameras are included if they have had a tracked object within the last 30 seconds
  #   motion - cameras are included if motion was detected in the last 30 seconds
  #   continuous - all cameras are included always
  mode: continuous

objects:
  # Optional: list of objects to track from labelmap.txt (default: shown below)
  track:
    - person
    - dog
    - cat

  # Optional: mask to prevent all object types from being detected in certain areas (default: no mask)
  # Checks based on the bottom center of the bounding box of the object.
  # NOTE: This mask is COMBINED with the object type specific mask below
  mask: 0,0,1000,0,1000,200,0,200
  # Optional: filters to reduce false positives for specific object types
  filters:
    person:
      # Optional: minimum width*height of the bounding box for the detected object (default: 0)
      min_area: 5000
      # Optional: maximum width*height of the bounding box for the detected object (default: 24000000)
      max_area: 100000
      # Optional: minimum score for the object to initiate tracking (default: shown below)
      min_score: 0.5
      # Optional: minimum decimal percentage for tracked object's computed score to be considered a true positive (default: shown below)
      threshold: 0.7
      # Optional: mask to prevent this object type from being detected in certain areas (default: no mask)
      # Checks based on the bottom center of the bounding box of the object
      mask: 0,0,1000,0,1000,200,0,200

# Optional: Motion configuration
# NOTE: Can be overridden at the camera level
motion:
  # Optional: The threshold passed to cv2.threshold to determine if a pixel is different enough to be counted as motion. (default: shown below)
  # Increasing this value will make motion detection less sensitive and decreasing it will make motion detection more sensitive.
  # The value should be between 1 and 255.
  threshold: 25
  # Optional: Minimum size in pixels in the resized motion image that counts as motion (default: ~0.17% of the motion frame area)
  # Increasing this value will prevent smaller areas of motion from being detected. Decreasing will make motion detection more sensitive to smaller
  # moving objects.
  contour_area: 100
  # Optional: Alpha value passed to cv2.accumulateWeighted when averaging the motion delta across multiple frames (default: shown below)
  # Higher values mean the current frame impacts the delta a lot, and a single raindrop may register as motion.
  # Too low and a fast moving person wont be detected as motion.
  delta_alpha: 0.2
  # Optional: Alpha value passed to cv2.accumulateWeighted when averaging frames to determine the background (default: shown below)
  # Higher values mean the current frame impacts the average a lot, and a new object will be averaged into the background faster.
  # Low values will cause things like moving shadows to be detected as motion for longer.
  # https://www.geeksforgeeks.org/background-subtraction-in-an-image-using-concept-of-running-average/
  frame_alpha: 0.2
  # Optional: Height of the resized motion frame  (default: 1/6th of the original frame height, but no less than 180)
  # This operates as an efficient blur alternative. Higher values will result in more granular motion detection at the expense of higher CPU usage.
  # Lower values result in less CPU, but small changes may not register as motion.
  frame_height: 180
  # Optional: motion mask
  # NOTE: see docs for more detailed info on creating masks
  mask: 0,900,1080,900,1080,1920,0,1920

# Optional: Record configuration
# NOTE: Can be overridden at the camera level
record:
  # Optional: Enable recording (default: shown below)
  enabled: True
  # Optional: Number of days to retain recordings regardless of events (default: shown below)
  # NOTE: This should be set to 0 and retention should be defined in events section below
  #       if you only want to retain recordings of events.
  retain_days: 0
  # Optional: Event recording settings
  events:
    # Optional: Maximum length of time to retain video during long events. (default: shown below)
    # NOTE: If an object is being tracked for longer than this amount of time, the retained recordings
    #       will be the last x seconds of the event unless retain_days under record is > 0.
    max_seconds: 300
    # Optional: Number of seconds before the event to include (default: shown below)
    pre_capture: 5
    # Optional: Number of seconds after the event to include (default: shown below)
    post_capture: 5
    # Optional: Objects to save recordings for. (default: all tracked objects)
    objects:
      - person
    # Optional: Restrict recordings to objects that entered any of the listed zones (default: no required zones)
    required_zones: []
    # Optional: Retention settings for recordings of events
    retain:
      # Required: Default retention days (default: shown below)
      default: 10
      # Optional: Per object retention days
      objects:
        person: 15

# Optional: Configuration for the jpg snapshots written to the clips directory for each event
# NOTE: Can be overridden at the camera level
snapshots:
  # Optional: Enable writing jpg snapshot to /media/frigate/clips (default: shown below)
  # This value can be set via MQTT and will be updated in startup based on retained value
  enabled: False
  # Optional: print a timestamp on the snapshots (default: shown below)
  timestamp: False
  # Optional: draw bounding box on the snapshots (default: shown below)
  bounding_box: False
  # Optional: crop the snapshot (default: shown below)
  crop: False
  # Optional: height to resize the snapshot to (default: original size)
  height: 175
  # Optional: Restrict snapshots to objects that entered any of the listed zones (default: no required zones)
  required_zones: []
  # Optional: Camera override for retention settings (default: global values)
  retain:
    # Required: Default retention days (default: shown below)
    default: 10
    # Optional: Per object retention days
    objects:
      person: 15

cameras:
  Kitchen: # <------ Name the camera
    ffmpeg:
      inputs:
        - path: rtsp://camera:camera@<IP_ADDRESS>:554/stream2 # <----- Update for your camera
          roles:
            - detect
            - rtmp
    detect:
      width: 640 # <---- update for your camera's resolution
      height: 368 # <---- update for your camera's resolution

Describe the bug
I am unable to connect to Frigate using the provided integration from HAC's.
Debug log

Add your logs here.

This is a very common error, that can be caused by numerous things. Did you install Frigate (the server / addon, not the integration)? Can you visit the Frigate UI and it loads ok? If not make sure you've read/followed the installation instructions: https://docs.frigate.video/installation .

Thanks for replying, I do indeed have access to the Frigate UI so I am pretty confident frigate is working ok. Just seems to be an issue with the frigate integration via hac's.
I have also checked the steps and nothing stands out that I have missed. Will see if I can find anything else missing.

My mistake, the URL for the beta build is http://ccab4aaf-frigate-fa-beta:5000/

My mistake, the URL for the beta build is http://ccab4aaf-frigate-fa-beta:5000/


Add Sonatype helm charts

New 'official' Sonatype helm charts for both the Nexus IQ Server and Nexus repository Manager

The Artifact Hub is another place you can list your repos. To do that, you login (or create an account), create an organization, and list your repository. You can link it to a user or organization.

@CMYanko The Artifact Hub is another place you can list your repos. To do that, you login (or create an account), create an organization, and list your repository. You can link it to a user or organization.


Support running on OSX

OSX bash shell doesn't have a timeout command, but often (at least dev OSX machines) will have perl.  Can do:
function timeout() { perl -e 'alarm shift; exec @ARGV' "$@"; }

Simply install gtimeout. See http://stackoverflow.com/questions/3504945/timeout-command-on-mac-os-x :) and set an alias.

I do like the gtimeout approach - not as a prerequisite, but I could easily change PR #17 to use that instead where it is available.

If you are looking for an approach that does not depend on third party tools (curl, wget) and has cross platform support. Please take a look on this other tool https://github.com/maxcnunes/waitforit.


v2.9.4 won't run

Previous version worked.  But this one had error on start.
vmware@vmware-virtual-machine ~ $ Downloads/electrum/electron-cash
Traceback (most recent call last):
  File "Downloads/electrum/electron-cash", line 95, in <module>
    imp.load_module('electroncash', *imp.find_module('lib'))
  File "/home/vmware/Downloads/electrum/lib/__init__.py", line 3, in <module>
    from wallet import Synchronizer, Wallet, Imported_Wallet
  File "/home/vmware/Downloads/electrum/lib/wallet.py", line 65, in <module>
    import paymentrequest
  File "/home/vmware/Downloads/electrum/lib/paymentrequest.py", line 39, in <module>
    import paymentrequest_pb2 as pb2
  File "/home/vmware/Downloads/electrum/lib/paymentrequest_pb2.py", line 9, in <module>
    from google.protobuf import symbol_database as _symbol_database
  File "/home/vmware/Downloads/electrum/packages/google/protobuf/symbol_database.py", line 184, in <module>
    _DEFAULT = SymbolDatabase(pool=descriptor_pool.Default())
AttributeError: 'module' object has no attribute 'Default'
vmware@vmware-virtual-machine ~ $

2fa wallet?

nope.  plain wallet secured by a regular seed.

something wrong with google.protobuf lib
can you do the following?
#> **cd ~/Downloads/electrum/packages**
#> **python2.7**
Python 2.7.14 (default, Sep 20 2017, 01:25:59)
[GCC 7.2.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> **from google.protobuf import descriptor_pool**
>>> **descriptor_pool**
<module 'google.protobuf.descriptor_pool' from 'google/protobuf/descriptor_pool.pyc'>

The last line might shed some light about where that descriptor_pool is being loaded from.

@molecular Thanks!  That was it!!  After running "sudo pip2 install --upgrad protobuf" it worked!
`vmware@vmware-virtual-machine ~ $ cd ~/Downloads/electrum/packages/
vmware@vmware-virtual-machine ~/Downloads/electrum/packages $ python2
Python 2.7.6 (default, Oct 26 2016, 20:30:19)
[GCC 4.8.4] on linux2
Type "help", "copyright", "credits" or "license" for more information.

from google.protobuf import descriptor_pool
descriptor_pool
<module 'google.protobuf.descriptor_pool' from '/usr/lib/python2.7/dist-packages/google/protobuf/descriptor_pool.pyc'>

vmware@vmware-virtual-machine ~/Downloads/electrum/packages $ sudo pip2 install --upgrad protobuf
[sudo] password for vmware:
Downloading/unpacking protobuf from https://pypi.python.org/packages/4b/01/d6d8536d27d0619ff0e132ae8ec9c8c4738caa7e9ab6eb868d40e26fafb7/protobuf-3.5.0-py2.py3-none-any.whl#md5=1adddde919d3e676545505c27bdc9857
Downloading protobuf-3.5.0-py2.py3-none-any.whl (388kB): 388kB downloaded
Downloading/unpacking six>=1.9 (from protobuf)
Downloading six-1.11.0-py2.py3-none-any.whl
Downloading/unpacking setuptools from https://pypi.python.org/packages/d1/56/fe971f02e075c9e712f23d1fe5c427f573fce178c368deebf5794f80b7c9/setuptools-36.7.2-py2.py3-none-any.whl#md5=cb2de0d103f578273c61f7ff640cf697 (from protobuf)
Downloading setuptools-36.7.2-py2.py3-none-any.whl (482kB): 482kB downloaded
Installing collected packages: protobuf, six, setuptools
Found existing installation: protobuf 2.5.0
Not uninstalling protobuf at /usr/lib/python2.7/dist-packages, owned by OS
Found existing installation: six 1.5.2
Not uninstalling six at /usr/lib/python2.7/dist-packages, owned by OS
Found existing installation: setuptools 3.3
Not uninstalling setuptools at /usr/lib/python2.7/dist-packages, owned by OS
Successfully installed protobuf six setuptools
Cleaning up...
vmware@vmware-virtual-machine ~/Downloads/electrum/packages $ python --version
Python 2.7.6`

I would like to say this issue can be closed, but there are still a bunch of warnings/errors that doesn't prevent the GUI from launching, and otherwise appears to be working.
vmware@vmware-virtual-machine ~/Downloads/electrum $ ./electron-cash
"sni-qt/26066" WARN  09:02:49.866 void StatusNotifierItemFactory::connectToSnw() Invalid interface to SNW_SERVICE
Traceback (most recent call last):
  File "/home/vmware/Downloads/electrum/gui/qt/main_window.py", line 295, in on_network_qt
    self.history_list.update_item(*args)
TypeError: update_item() takes exactly 5 arguments (65 given)
Traceback (most recent call last):
  File "/home/vmware/Downloads/electrum/gui/qt/main_window.py", line 295, in on_network_qt
    self.history_list.update_item(*args)
TypeError: update_item() takes exactly 5 arguments (65 given)
Traceback (most recent call last):
  File "/home/vmware/Downloads/electrum/gui/qt/main_window.py", line 295, in on_network_qt
    self.history_list.update_item(*args)
TypeError: update_item() takes exactly 5 arguments (65 given)
Traceback (most recent call last):
  File "/home/vmware/Downloads/electrum/gui/qt/main_window.py", line 295, in on_network_qt
    self.history_list.update_item(*args)
TypeError: update_item() takes exactly 5 arguments (65 given)
Traceback (most recent call last):
  File "/home/vmware/Downloads/electrum/gui/qt/main_window.py", line 295, in on_network_qt
    self.history_list.update_item(*args)
TypeError: update_item() takes exactly 5 arguments (65 given)

if you can run from source, can you try pyqt4 head?

@fyookball , it works now (see my answer above)

clone pyqt4 branch and run it.


Update Travis CI build settings

Test latest point releases of Go 1.8 and 1.9 (without the .x suffix,
1.8.0 and 1.9.0 are used instead of the latest releases)
Test with Go tip but allow failures
Mark the build as failed immediately if any jobs fail

Remarks:

gofmt is failing on tip (golang 1.10) and the diff output is difficult to read
We're building with Go 1.7.4 instead of 1.7.x (latest fix release is 1.7.6); is this intentional?
I believe only the last two versions (1.8 and 1.9) are supported by Go upstream; is 1.7 support still required?

Signed-off-by: Jonathan Yu<EMAIL_ADDRESS>

We're building with Go 1.7.4 instead of 1.7.x (latest fix release is 1.7.6); is this intentional?

Yes it is intentional @jawnsy we don't want to build with latest for 1.7 we want to build from 1.7.4 minimum.

gofmt is failing on tip (golang 1.10) and the diff output is difficult to read

Looks like a bug in gofmt perhaps can be reported.

I believe only the last two versions (1.8 and 1.9) are supported by Go upstream; is 1.7 support still required?

Yes it is required until restic says its moving to latest 1.8, 1.9 as default.


Adding tests for state next() function and reversing commit ecf3c54

After trying to replicate the error pointed out on commit ecf3c54 and not being able to do so, I have added a test to cover the next() function of the states object.
The test adds two states to a layer and iterates through them, changing some positioning and rotation values, and finally calls 'next()' one more time to go back to default. After every state transition it verifies that the values are correct.
The PR includes the reverse commit for ecf3c54 and the mentioned test to cover it.

Thanks so much @jchavarri !


Repeat track on queue

Is there a way to repeat one track on queue of at least 4 tracks?
If no, have you guys a plan to implement it?

Duplicate of #122

Unfortunetly it doesn't help me...

I'm unifying each suggestion in a single issue, it's supposed to help the project stay organized. If you want this feature, you should 👍 that issue instead.


feat: add group/endgroup for time analysis

I was intending this to be a PR to my own main, but whatever...
This would add some more info in the logs on how long the various dpkg, apt-get update, and apt-get install steps take. The idea is that there may be benefits from adding some caching support in this action if there are benefits, time-wise.

The groups don't actually give better timing info.
But in terms of setup we have ~20s in apt-get update, nearly ~40s on actual apt-get install, for a total overhead time of around 1min30s.

Well, this is nice in any case. If the overhead is a concern for you, I recently noticed that github actions actually allows running containers in privileged mode, so one could use a container image that has cvmfs installed without installing it on the host. This could remove some of the setup time (at the expense of a larger container image?).

If the overhead is a concern for you

We're used to running many small jobs (literally hundreds), probably on average taking 1 or 2 minutes. In our persistent environment on gitlab (and self-hosted runnres) where we don't need to reinstall cvmfs every time, that adds maybe 10s of overhead per job just for starting the container. With github-action-cvmfs that starts to add up to result in pipelines taking twice as long as they would otherwise.

one could use a container image that has cvmfs installed without installing it on the host

I've been thinking about a container approach, but that's not how this action is used (so it would break the workflows for a lot of people). Compare with AIDAsoft/run-lcg-view does with what this cvmfs-contrib/github-action-cvmfs does (*):

run-lcg-view is similar to what you suggest: you run inside a container, so everything that you want to run inside that container must be in the run parameter of that single step; the next step is back on the host outside of the LCG view,
github-action-cvmfs sets up the environment for future steps too; the next step can still use the cvmfs installs.

(*) ignoring for a second that run-lcg-view needs github-action-cvmfs.
Maybe what can be combined with this action is a container on ghcr.io, such that we can run the following:
jobs:
  run-on-cvmfs:
    runs-on: ubuntu-latest
    container:
      image: ghcr.io/cvmfs-contrib/github-action-cvmfs:latest
      env:
        cvmfs_repositories: 'sft.cern.ch'
    steps:
    - uses: actions/checkout@v2
    - name: Test CernVM-FS
      run: |
        ls /cvmfs/sft.cern.ch

In this approach (which would be complimentary), the env section would be used to pass the same set of options that we support in the github action approach.
Brief tests indicate that ghcr.io container pulls are taking on the order of ~10s.

It's probably not a good idea to download from ghcr.io in hundreds of jobs every minute or two.  A local cache is called for.

With some more aggressive GitHub actions caching of apt downloads and caches, I can now get the overhead of the current approach (installing from deb inside ubuntu-latest etc) to under 30s (payload of a few ls /cvmfs dirs is 15s). That's down from 1m30s on the same ubuntu-latest for the first invocation (which requires a curl to CERN, apt-get update sync, and the apt-get install downloads).
Main benefit (and maybe the more important reason for doing this) is that the action doesn't hit the cvmfs deb distribution server on every subsequent run. That alone probably makes this a sensible thing to implement.
PR likely tomorrow... Still figuring out a cache expiration strategy so users aren't stuck on old cvmfs versions that won't leave the GitHub actions cache as long as they are regularly used...


Question

Hello guys my project using https://github.com/RealmTeam/django-rest-framework-social-oauth2
for my project that include stripe on mobile
I’m converting them to django native code
Is this the one I should use > https://github.com/jazzband/django-oauth-toolkit/issues
sorry new to coding

I don't get the gist of your question. Sorry.
This repository is not maintained anymore. Do, i stead, you may use https://github.com/wagnerdelima/drf-social-oauth2 for authenticating.
All the best.

If I'm not using social auth
Is this the one I should use ?
https://github.com/jazzband/django-oauth-toolkit/issues

django oauth toolkit will lead you to the same path: social authentication.

But I'm not using any social
On my login
I'm using just Django API

Right, then you don't need django-oauth-toolkit at all.
Does your django project not have any sort of authentication, authorization?

My stripe payment needs
Client_secret

You will have to take from stripe itself. You should see it in your stripe dashboard. Stripe has nothing to do with social authentication.

It required client_secret

Your code is not even in Python. You definitely don't need this library.

I bought this from some online course it use Facebook
That why I'm trying to convert them into Django


Incorrect CI_BUILD_REF_NAME when merging to master

If I open a merge request in gitlab, and either:

accept the merge request in gitlab
merge the branch manually into master and push

The associated gitlab ci build does not see that as a change to the master branch, but the source branch that wanted to merge. This causes any build commands for the master branch in the build script to not run. The only workaround is to push a fresh commit to the master branch.
Is there an easy way or setting so a merge to master shows as a master branch change, not a branch change?

Thank you for you report. This bug was fixed in master and will be available in 7.10 release.
related #546


Emojis autocompletion

As a low-priority feature, it's quite nice to have this emojis autocompletion feature eventually implemented:

This is very handy when composing texts, maybe I can also give a hand on this.

Yes I agree, feel free to send a PR for that 🙂

Yes I agree, feel free to send a PR for that 🙂

Feature addded in https://github.com/antoine92190/vue-advanced-chat/releases/tag/0.7.4


pReLU eta must be between -1 and 1

We can enforce this constraint by parameterizing eta, for example:
eta = tanh(xi)

where now xi is unbounded.
We can use something faster than tanh. Here are some examples:

This suggests that the faster alternative is:
eta = xi / (1 + abs(xi))

We don't have to parameterize eta. Rather, we can use a different parameter. So, instead of using

which is required to be between -1 and 1, we can use:

which is unbounded.
The relation between the two is:

Closed in https://github.com/cossio/RestrictedBoltzmannMachines.jl/commit/e774670e59889803b483f9da25f734d78d3936c7


cambie el nombre del repo

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 100.0%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
4

Relevant Lines:
4

💛  - Coveralls


BED-4540/toolapi: Expose live datapipe status

Enables the remote inspection of the datapipe status through the toolapi.  This allows external infrastructure tooling to quickly understand the current live workload of BloodHound instances, and make informed decisions.

Description
Exposes the overall datapipe status via the toolapi
Motivation and Context
This PR addresses: BED-4540
With the availability of the datapipe quickly available via API, workloads can be balanced with greater care to try and delay/prevent disruptions to active workloads.
How Has This Been Tested?
just bhe-api-only
curl -s http://<IP_ADDRESS>:2112/datapipe/status | jq
Screenshots (optional):
Types of changes

Chore (a change that does not modify the application functionality)
Bug fix (non-breaking change which fixes an issue)
New feature (non-breaking change which adds functionality)
Breaking change (fix or feature that would cause existing functionality to change)
Database Migrations

Checklist:

[ ] I have met the contributing prerequisites

Assigned myself to this PR
Added the appropriate labels
Associated an issue: https://github.com/SpecterOps/BloodHound/issues/672
Read the Contributing guide: https://github.com/SpecterOps/BloodHound/wiki/Contributing

[ ] I have ensured that related documentation is up-to-date

Open API docs
Code comments (GoDocs / JSDocs)

[ ] I have followed proper test practices

Added/updated tests to cover my changes
All new and existing tests passed

$ curl -s http://<IP_ADDRESS>:2112/datapipe/status | jq
{
  "status": "idle",
  "updated_at": "2024-07-11T14:29:36.197322Z",
  "last_complete_analysis_at": "2024-07-11T14:09:25.526094Z"
}

I left an alternative method of just showing { state: "idle" } if exposing all of the DatapipeStatus is too much for the toolapi.
TODO: Drop commented code if the data above is alright to expose unsecured via the toolapi

I have read the CLA Document and I hereby sign the CLA


Bug - Pock not visible on latest Catalina Beta (5)

Describe the bug
Pock is not showing up in the Touchbar after latest Catalina Beta (5) update
I'd prioritize waiting to fix this issue if it makes sense to tackle other ones; being a Beta OS and all...
How to reproduce
1. Update to Catalina B5,
2. Start Pock (which appears in the Menubar)
3. Normal Touchbar is shown
4. Using the Ctrl shortcut makes the Esc key flash, but does not change Touchbar

Expected behavior

Upon Starting Pock, Pock should change to be Touchbar
Using the Ctrl Key should switch the Touchbar between normal and Pock

Screenshots
Not applicable, just shows normal Touchbar
Crashlog
Not applicable, app does not crash
Versions:

macOS version: 10.15 B5
Pock version:  0.5.3

Additional context
Esc key flashing on Ctrl key shortcut is the only indication that Pock is probably working, might be working, just not visible.

Update: Seems to occur when Expanded Control Strip is set as the default Touchbar in settings. I just wiped my laptop and Pock is working as expected; until I change the default Touchbar.

This is expected behavior if Hide Control Strip option is disabled in Pock settings since Expanded Control Strip prevent other apps from showing custom content on Touch Bar.

Coming across the same bug. Unable to get pock working at all since upgrading to catalina


Add IP based starting location and restore state

Initial marker on unanswered questions set to geolocated IP location.
Browsing back to an answered question did not restore marker location. This sets marker location based on existing question value.

Browsing back to restore marker location has been included in the 2.0 rewrite. I do see some benefit in allowing location-based initial map centering/marker placement. Since the re-write, this would require a new PR.


Update _dosh.aiml

And let's add this too

Filename: _dosh.aiml
Message:[in Sax parser] expecting an end tag for category got an end tag for aiml filename cache/manage/files/bb/bbcf924b76e9c7778cbb37a4f545af24376b2570, position near character 13,017

Missing category.


Reproduction of the model

Hi,thanks your nice work.
I reproduce the model based on Occluded_DukeMTMC, and the result is much beterr than the result posted on paper, and I did not adjust any relevant hyperparameters

That is exciting. After we optimize the source codes and make it open, the performance on Occluded_dukeMTMC is indeed higher than that posted on paper.  But the performance you reproduced is much higher than I expected. Maybe the environment also affects the performance.

This is an amazing result!

Thank you. Welcome to pay attention to our new work https://github.com/CASIA-IVA-Lab/PASS-reID.

Thank you. Welcome to pay attention to our new work https://github.com/CASIA-IVA-Lab/PASS-reID.

AAformer will it be open sourced? I have been following the related papers you published recently.

Recently I am interesting in occluded and partial reID and judging from the recent SOAT, transfer has better local integration and perception capabilities, and reID seems to be another promising direction for transformer.
AAformer and PASS-reID are nice work！

Thank you, but AAformer may not be open. The main reasons are (1) its performance is really not that outstanding. (2) PASS with ''part tokens'', one of the main ideas of AAformer, obtains quite good performance. (3) it's been a long time since we proposed it, but it is still not published now. I have an idea to improve it, and maybe we will propose AAformer_v2 later.
You can also try PASS on Occluded-DukeMTMC. According to the privacy policy, we did not conduct experiments on DukeMTMC and its related datasets, but we believe PASS is also effective on occluded datasets.

Thank you, but AAformer may not be open. The main reasons are (1) its performance is really not that outstanding. (2) PASS with ''part tokens'', one of the main ideas of AAformer, obtains quite good performance. (3) it's been a long time since we proposed it, but it is still not published now. I have an idea to improve it, and maybe we will propose AAformer_v2 later.
You can also try PASS on Occluded-DukeMTMC. According to the privacy policy, we did not conduct experiments on DukeMTMC and its related datasets, but we believe PASS is also effective on occluded datasets.

Thank you. I will try it.

Hi,thanks your nice work. I reproduce the model based on Occluded_DukeMTMC, and the result is much beterr than the result posted on paper, and I did not adjust any relevant hyperparameters

Amazing result! I wonder what changes you made to achieve higher results than the paper. Could you please share your modifications and insights? Also, I noticed that you tried to use multiprocessing for clustering. Did you succeed in that? Thank you.😊


Update the build and unit testing status check workflows

Update both the build-status-check.yml and unit-tests-status-check.yml status check workflows to use the organization level reusable workflows.
Refer to the BranchValidator project for reference.
Acceptance Criteria:

[ ] Build status check workflow updated
[ ] Unit testing status check workflow updated

Removed dependency below.   It was not required.

#26


refactor: Make test supporter less surprising

Overview
This renames our test modules to follow more expected conventions with the file structures they belong in.
After some discussion, going to pull these into a top level Support module as we continue to clean up these coupled test helpers.
Changes

Rename modules to match file directory paths
Follower module naming convention, re: not plural
use aliases to truncate long running module names.
remove use of import for our own modules (still remaining items in code base)
rename modules to not collide with test_helper.exs and give it a better name.

Testing
mix test

Coverage remained the same at 84.671% when pulling 1733af7bffd418ff00553aac03b86d7e3a3f03ec on achiurizo/test-cleanups into f3eb68198072485909b2949abccafe7ab03930d9 on master.

IMHO removing manual_service_startup is premature

oh, I haven't noticed this. Yeah, agreed, this is the guide to run things on bare metal, which I suppose supported still, even I'm still sometimes using it (i.e. the commands inside) for convenience. Why remove?

I hear you on the "misleading" part. Still, it is useful to be able to spin up the services on bare metal using mix, for the purpose of debugging and experimentation. I suppose releases would not be enough, if you do something in the code and then restart the services. This is very useful to have.
If we perhaps rephrase the docs to be clear about that it is intended only for elixir-omg development process and is not the way the services should be started normally? We can leave all the explanations out and be explicit about what it is. What do you say?

On the other hand, using mix to startup the release is discouraged and is not supported and having documentation for that is misleading.

Honestly I'm totally missing the point in above statement. This is part of development documentation in code repository. In what part development tools such as mix are discourage to use with source code? What is misleading in documenting service startup steps in development environment? What does release mean in regards to development branch?
manual service startup is useful for developers and documents how to start the service from the codebase. What's wrong with it?

On the other hand, using mix to startup the release is discouraged and is not supported and having documentation for that is misleading.

Honestly I'm totally missing the point in above statement. This is part of development documentation in code repository. In what part development tools such as mix are discouraged to use with source code? What is misleading in documenting service startup steps in development environment? What does release mean in regards to development branch?
manual service startup is useful for developers and documents how to start the service from the codebase. What's wrong with it?

It’s like this, if you provide documentation, you need to support it. Our repo has been suffering from excessive documentation that got outdated already. If your development cycle is to manually start supervision trees, it most definitely can be, but it is not something I would provide as part of official OmiseGO documentation. It serves no purpose. The development cycle are tests and end2end tests tbd.
Every elixir and erlang developer understands the concept of applications because thats the architecture of beam systems. So what is the purpose of this doc? To educate developers on erlang and elixir? This isn’t the right place for that.
These applications are not microservice components of a larger system (they could be-same as we’re forming watcher and child chain) but individually they don’t make sense.

Running services baremetal with releases is supported

I must be missing something, can you link doc with describe preparing a distillery release?

Running services baremetal with releases is supported

I must be missing something, can you link doc with describe preparing a distillery release?

https://github.com/omisego/elixir-omg/blob/master/docs/deployment_configuration.md
+
Makefile ... ‘make help’

So what is the purpose of this doc?

In my opinion this doc describes the steps needed to start a service from the codebase. Unfortunately it requires not only mix run or even mix xomg... but some preliminaries like running geth, contract deployment and so. Therefore I think it is useful.

So what is the purpose of this doc?

In my opinion this doc describes the steps needed to start a service from the codebase. Unfortunately it requires not only mix run or even mix xomg... but some preliminaries like running geth, contract deployment and so. Therefore I think it is useful.
Also this are required steps to run the demos... once we haven't yet rewritten them to use some other method.

but it is not something I would provide as part of official OmiseGO documentation.

I agree and this is OK, because it isn't a part of the official OmiseGO documentation. It's documenting the codebase and is required to run demos locally.

The docs for this are already broken. If you want to rewrite them, go ahead and we might consider adding them back. Note that documentation here presumes one can set environment variables and they'll be read if you run things via mix .... It's not the case because we use config providers that are assembled at the release startup.
Also, please double check what you're fighting for. The docs point to old contracts that we've abandoned and moved to ALD.
In my opinion this doc describes the steps needed to start a service from the codebase.
The doc describes how to start the underlying services in an unconventional.
Which demos docs? We need to delete those as well.

If you want to rewrite them, go ahead and we might consider adding them back.
The docs point to old contracts that we've abandoned and moved to ALD.

I'll try to make it work for ALD.

Which demos docs? We need to delete those as well.

I'll happily remove them once we have an alternative. Specs?

If you want to rewrite them, go ahead and we might consider adding them back.
The docs point to old contracts that we've abandoned and moved to ALD.

I'll try to make it work for ALD.

Which demos docs? We need to delete those as well.

I'll happily remove them once we have an alternative. Specs?

Specs repo is end 2 end testing. If we want to have demos on live systems we should implement mix tasks or custom commands.

The docs for this are already broken.

@InoMurko not so much. Regarding manual_service_startup.md only missing part is prepare_env step, because DevHelpers are not compiled now on MIX_ENV=dev
so it's sufficient to replace with:
MIX_ENV=test mix run --no-start -e \ ...
also it supports ALD contracts already - I've just run ch-ch following the steps.
So I'm opting to preserve the file with applying only above fix, it's still relevant.
What do you think?

I don’t think the file is relevant or that it adds anything meaningful.

@InoMurko not so much. Regarding manual_service_startup.md only missing part is prepare_env step, because DevHelpers are not compiled now on MIX_ENV=dev

@pnowosie doesn't this mean the doc is still broken, regardless if it's not so much? I think that's the point being made here. the documentation isn't being well maintained. if this PR had not brought this to attention, the document would have continued being broken.
While I can appreciate the particular use-case and desire to do it this way, it's going to cause more problems in the long run as it exposes another way to build the project which is not being well maintained.

@achiurizo you may consider to rescue the doc, it's still useful for PL team.
here fix included

doesn't this mean the doc is still broken,

@achiurizo no, there was small fix required, it's OK here fix included

it's going to cause more problems in the long run as it exposes another way to build the project

As @pdobacz noticed it is "for the purpose of debugging and experimentation" on development environment. This is how we test things that require full setup. I'd be happy to retire the file once we'd have an alternative approach - but IMHO discussion with @InoMurko shows there is none.

Is it common Elixir practice to alias everything? I think the alias might make sense for a long namespace like OMG.Watcher.HttpRPC.Client (if we need to use it a lot), but seems less useful for something like Support.Deployer. It isn't painful to write the full module name and makes the code more readable and easier to search.

@chrishunt I think you make a good point here. I'm okay with that usage, but I think we need to be at least consistent with how we decide to call out other modules.  If we decide to alias, we should fully alias the name. If there's one off cases where its un-necessary, sure let's just use the full qualified name in the code.

doesn't this mean the doc is still broken,

@achiurizo no, there was small fix required, it's OK here fix included

it's going to cause more problems in the long run as it exposes another way to build the project

As @pdobacz noticed it is "for the purpose of debugging and experimentation" on development environment. This is how we test things that require full setup. I'd be happy to retire the file once we'd have an alternative approach - but IMHO discussion with @InoMurko shows there is none.

Ok. So let's go through the docs and check line by line how wrong they are.
This process is intended for users who wish to start services manually, perhaps
as part of a non-Docker deployment on a Linux host.

Our umbrella applications are not meant as a separate service you can deploy, because of the amount of coupling. Deploying them on a Linux host without releases is exactly what I've been working the last 6 months to get us away from. Remember launcher.py>
 1. (**Child chain server only**) Prepare the authority address and deploy `RootChain.sol`, see [Contracts section](#contracts).

Please point to me where does trunk of plasma-contracts contain RootChain.sol?
 1. Produce a configuration file for `omg_eth` with the contract address, authority address and hash of contract-deploying transaction.

Are you sure this still stands for truffle deploys and ALD?
- configuring with an environment variable `CHILD_CHAIN_URL=desired_childchain_url`

You cannot configure mix tasks with environment variables anymore because of config providers we use in releases.
```bash
MIX_ENV=test mix compile
MIX_ENV=test mix run --no-start -e \
 '
   contents = Support.DevHelper.prepare_env!() |> Support.DevHelper.create_conf_file()
   "~/config.exs" |> Path.expand() |> File.write!(contents)
 '

Wrong approach to deploy using releases or truffle.

Start it up!

The whole section start it up is against everything elixir community has been working against with distillery and releases.

doesn't this mean the doc is still broken,

@achiurizo no, there was small fix required, it's OK here fix included

it's going to cause more problems in the long run as it exposes another way to build the project

As @pdobacz noticed it is "for the purpose of debugging and experimentation" on development environment. This is how we test things that require full setup. I'd be happy to retire the file once we'd have an alternative approach - but IMHO discussion with @InoMurko shows there is none.

You now need to decide. Is this for development or deployment? The documentation is clear, it’s meant for deployment to production. Look at the first paragraph.
Also, please check the Makefile on root of the project. I don’t know how you can say that there’s no alternative approach since you can deploy a full local service with docker, docker compose, baremetal releases prod or dev.

@pnowosie @InoMurko Considering there's quite a bit of discussion surrounding this document and I not wanting to prolong this PR any further, can we consider a separate PR where we decide if we want to re-introduce the document? 🙏


False negative on valid-expect

We use wait-for-expect package, which gives false negative for the valid-expect rule on this code
import waitForExpect from 'wait-for-expect';

waitForExpect(() => {
    ...
})

That package is unnecessary. You can use expect.poll instead which is builtin to Playwright.
https://playwright.dev/docs/test-assertions#expectpoll

@mskelton What do you mean?
The bug is still there, the rule should not fail my linting if I use that package. I'm not gonna refactor our tests just make that rule pass, right?

This package is built with the assumption that you are using Playwright and Playwright Test fairly conventionally.  Lint rules that check page methods will check both page as well as ...Page to account for custom page objects. Similarly with expect we also check ...Expect to account for custom expect via expect.configure.
It's obviously a trade off, if we were stricter about only checking page and expect, we would have less false negatives for use cases like yours, but we would also have more false positives for the other instances I mentioned which are significantly more common.
I'm sorry you are experiencing this issue, but I do believe the direction we've gone with this plugin is the best for the community at large.


[SPARK-10304][SQL] Partition discovery should throw an exception if the dir structure is invalid

JIRA: https://issues.apache.org/jira/browse/SPARK-10304
This patch detects if the structure of partition directories is not valid.
The test cases are from #8547. Thanks @zhzhan.
cc @liancheng

Merged build triggered.

Merged build started.

Test build #42708 has started for   PR 8840 at commit 2d13156.

Test build #42708 has finished for   PR 8840 at commit 2d13156.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder/42708/
Test FAILed.

retest this please.

Merged build triggered.

Merged build started.

Test build #42718 has started for   PR 8840 at commit 2d13156.

Test build #42718 has finished for   PR 8840 at commit 2d13156.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder/42718/
Test PASSed.

Merged build finished. Test PASSed.

Jenkins, retest this please.

Merged build triggered.

Merged build started.

@chenghao-intel, it looks like this PR's error message improvements are similar to the ones that you added as part of #8026. @viirya, could you take a look at @chenghao-intel's PR to see which approach you like better?

Test build #44001 has started for PR 8840 at commit 2d13156.

Test build #44001 has finished for PR 8840 at commit 2d13156.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder/44001/
Test PASSed.

Merged build finished. Test PASSed.

@JoshRosen ok, I will take a look at it.

Merged build triggered.

Merged build started.

Test build #44295 has started for PR 8840 at commit 779fbd2.

Test build #44295 has finished for PR 8840 at commit 779fbd2.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder/44295/
Test PASSed.

Merged build finished. Test PASSed.

Merged build triggered.

Merged build started.

Test build #44316 has started for PR 8840 at commit cdf6dc4.

Test build #44316 has finished for PR 8840 at commit cdf6dc4.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder/44316/
Test PASSed.

Merged build triggered.

Merged build started.

Test build #44888 has started for PR 8840 at commit 3db4226.

LGTM

Test build #44888 has finished for PR 8840 at commit 3db4226.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder/44888/
Test FAILed.

Merged build finished. Test FAILed.

retest this please.

Merged build triggered.

Merged build started.

Test build #44906 has started for PR 8840 at commit 3db4226.

Test build #44906 has finished for PR 8840 at commit 3db4226.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder/44906/
Test PASSed.

Should this one be backported to branch-1.5?
cc @liancheng @yhuai

@rxin I think it is find to not backport it. Without this, a user will get the DataFrame and when he/she queries it, it will fail (and the error message does not say what's the cause). Since, it does not really let users make any real progress, I think we do not really need to backport it.

OK great. @viirya can you submit a followup pr to address @yhuai's feedback.

@rxin @yhuai OK. Submitted a following pr at #9459.


Remove all CRLF's

Many of the source files in this repo contain Windows-style CRLF's. For consistency's sake I want to convert all sources to Unix-style LF before we do the v0.3 release. This will conflict with other pull requests so it should be done all at once while other pull requests are not pending.
One reason to not do this is git blame will be useless. The entire codebase needs refactoring though so this isn't a good reason to not do it.

Maybe clean everything later, not important for now


Fix GeoJsonClientSource multi geometries

Tested with the case in https://github.com/tangrams/tangram-es/issues/1499
http://geojson.io/#id=gist:anonymous/d00b5090e73256d284444cadb5b0f0bc&map=18/52.27367/20.84775

Testing this now, this might have also resolved #1500

Looks like this is also fixing #1500, just tried this with StreetComplete master.

@tallytalwar updated


Pass through snowpack log colors and show stats during production builds

Describe the solution
Upgraded snowpack and enabled the new --stat option for production builds.
Also improved snowpack logging by enabling colors to be passed through to stdio.

Running into issues with snowpack 1.5.0...
Reported here https://www.pika.dev/npm/snowpack/discuss/86
Just waiting on a fix


Vite plugin not working with monorepo on Windows

Describe the bug
<EMAIL_ADDRESS>not working in monorepo setup.
Oldest version 3.1.4 works.
It seems that
  const getAbsoluteVirtualFileId = (source: string) => normalizePath(path.join(config.root, source));

not working in a right way on windows os.
Fast change to:
  const getAbsoluteVirtualFileId = (source: string) => source.startsWith('..')
    ? normalizePath(path.join(config.root, source))
    : source.startsWith('/@id/') ? source.substring(5) : source

fixes build but breaks HMR.
Reproduction
https://github.com/mc-petry/vanilla-extract-monorepo/tree/vite-plugin-regression
System Info
System:
    OS: Windows 10 10.0.22000
    CPU: (8) x64 AMD Ryzen 3 5300U with Radeon Graphics
    Memory: 2.24 GB / 15.35 GB
  Binaries:
    Node: 16.14.2 - C:\Program Files\nodejs\node.EXE
    npm: 8.5.0 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Edge: Spartan (44.22000.120.0), Chromium (103.0.1264.77)
    Internet Explorer: 11.0.22000.120
  npmPackages:
    @vanilla-extract/vite-plugin: 3.3.0 => 3.3.0
    vite: ^3.0.5 => 3.0.5

Used Package Manager
pnpm
Logs
No response
Validations

[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] The provided reproduction is a minimal reproducible example of the bug.

I have the same issue, still not updating since 3.1.4 is the latest version that works when you have to bundle .css.ts files from the app side.
Is the /@id/ check related of how pnpm resolve the packages paths 🤔?

I had the same problem running 3.2.7.
Just upgraded to the latest version and it seems fixed :)

This seems to be fixed as of<EMAIL_ADDRESS>It even works with v3.2.0 of the VE vite plugin.


Update all packages

Required small changes to implemented ProcessManager type signatures
Required update to Glob.listSync -> Glob.listFileSystemSync in customer_tests

I had to remove the const UUID with an ignore since g3 is not yet updated


TagBot trigger issue

This issue is used to trigger TagBot; feel free to unsubscribe.
If you haven't already, you should update your TagBot.yml to include issue comment triggers.
Please see this post on Discourse for instructions and more details.
If you'd like for me to do this for you, comment TagBot fix on this issue.
I'll open a PR within a few hours, please be patient!

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/78031

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/88769

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/88892

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/88898

Triggering TagBot for merged registry pull request
This extra notification is being sent because I expected a tag to exist by now, but it doesn't.
You may want to check your TagBot configuration to ensure that it's running, and if it is, check the logs to make sure that there are no errors.

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/103881

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/109337


Talos config assumes gateway is on .1 address

Had to do some debugging on this one.... Looking at:
https://github.com/onedr0p/cluster-template/raw/main/bootstrap/templates/kubernetes/talos/talconfig.yaml.j2
        routes:
          - network: <IP_ADDRESS>/0
            gateway: "{{ nodes.host_network | nthhost(1) }}"

Assumes the gateway is on the .1 of the CIDR, which in my case is on .254.
Would maybe be nicer to put this as variable in the config.yaml?

Interesting... mostly everywhere I look the default gateway on subnets is set to .1

I also use the .1 as the gateway on most of my VLANs/subnets. But ironically on my k8s VLANs I like the esthetic of having my nodes on the .1-.6 range.
It's just that your code isn't universally applicable to everyone.

My nodes are .10 thru .15, I honestly never considered changing the default gateway as it's really common that's on .1

It's just that your code isn't universally applicable to everyone.

Yeah I get that but I'm trying to keep the configuration light as I can to make maintenance easier and less options people need to read over when they go to use this project.

Whatever you prefer. You can close this issue or I can draft a PR to add it as an optional config item. There are also options for VLAN and BGP in there, which are edge as well IMHO.

I am fine with a PR if you want to add an option to set the default gateway IP, I would just make sure to update all the references where nthhost is used.


Cannot upload photo 7/23/2018

I think instagram is blocking something.
This is my code:
Client.Session.create(device,storage,"username","passward")
.then(function(session){

return [session,Client.Upload.photo(session,'woo.jpg')]

})
.spread(function(session,upload){
    return Client.Media.configurePhoto(session, upload.params.uploadId, 'akward caption');
})
.then(function(medium){
    console.log(medium.params)
})

Did you got an error message?

What is the success message you get?

I ended up using a different api.

its still working I have an app on production with this API and work fine

It works perfectly fine for me


Kick ghosts (mod_pinger)

Looks like the mod_pinger should do the job to kick ghost users

this should be working


Fixed refesh typos

Replaced refesh typos with refresh to help with IDE usage.

Cheers for the PR.


Bicubic Lightmap Filtering Fails to Engage Under DX12

Tested versions
Tested in v4.4.dev (47bc374ed), built locally.
System information
Godot v4.4.dev (47bc374ed) - Windows 10.0.19045 - Direct3D 12 (Forward+) - dedicated Radeon RX 5500 XT (Advanced Micro Devices, Inc.; 32.0.11027.1003) - AMD Ryzen 7 5800X 8-Core Processor (16 threads)
Issue description
When using the DX12 backend, lightmaps never receive bicubic filtering even with the Use Bicubic Filter setting enabled. This is not an issue when using Vulkan, where the filtering switches to bicubic as expected.

Vulkan
DirectX 12

Additionally, I was able to force bicubic filtering by changing line 1653 in scene_forward_clustered.glsl from
if (sc_use_lightmap_bicubic_filter()) {
to
if (sc_use_lightmap_bicubic_filter() || true) {
so I believe this is an issue of the relevant flag somehow not being set.
When starting up the test project, the console also prints drivers/d3d12/rendering_device_driver_d3d12.cpp:2873 - Condition "int_value & (1 << 31)" is true. Returning: 0 eight times, then does so again whenever Use Bicubic Filter is toggled on or off.
I also noticed in scene_forward_clustered_inc.glsl that this flag, along with several others, is pulled conditionally from either a push constant or a specialization constant based on whether ubershaders are being used, which may be relevant, but I didn't see anything else suspicious following the trail back to where Use Bicubic Filter is read from the project settings.
Steps to reproduce
Create a 3D scene, add some MeshInstances to receive lightmaps and a light source to be baked, add a LightmapGI node and bake it.
In Project Settings, under Rendering/Rendering Device set Driver to d3d12, and under Rendering/Lightmapping ensure Use Bicubic Filter is toggled on.
Minimal reproduction project (MRP)
bicubic-lightmap-bug-mrp.zip

A bit unrelated, sorry, but still worth pointing out imo since people with knowledge about the bicubic lightmap filtering will have a look: the Vulkan one has some light leaking while the DX12 does not. Not sure if it's due to the filtering or some bug/unwanted behaviour.

A bit unrelated, sorry, but still worth pointing out imo since people with knowledge about the bicubic lightmap filtering will have a look: the Vulkan one has some light leaking while the DX12 does not. Not sure if it's due to the filtering or some bug/unwanted behaviour.

That's just due to the bicubic filtering. This scene is very simplistic, just a bunch of cubes I slapped together, so there's a bit of floor geometry inside the walls, the pixels of which leak outside the wall due to bicubic's wider footprint. I'm actually considering making a pull request to address this automatically during baking by detecting when one surface is inside another, but until then it's nothing to worry about.

It sounds like the D3D12 driver can't handle spec constants using the last bit in a uint32_t.
CC @RandomShaper It looks like we are only allowed to use up to 30 bits for spec constants in the D3D12 backend, is that right? Or is this an off by one error?
https://github.com/godotengine/godot/blob/aa8d9b83f66488dbb2c9c918e9016ef80f821fb4/drivers/d3d12/rendering_device_driver_d3d12.cpp#L2871-L2873
https://github.com/godotengine/godot/blob/aa8d9b83f66488dbb2c9c918e9016ef80f821fb4/drivers/d3d12/rendering_device_driver_d3d12.cpp#L2886-L2890

A bit unrelated, sorry, but still worth pointing out imo since people with knowledge about the bicubic lightmap filtering will have a look: the Vulkan one has some light leaking while the DX12 does not. Not sure if it's due to the filtering or some bug/unwanted behaviour.

The MRP uses PrimitiveMeshes, so this is due to https://github.com/godotengine/godot/issues/98685.


Add and Delete Dags while docker-compose is running

Hello everyone
I would like to know how can i add a new dag while docker-compose is running?
How i delete a dag add while airflow is running?
i delete the file that i create before but it doesn't disappear from the web server ( see image -1 )
can you explain that on the documentation, please ?

Best regards

hi mate,

How i delete a dag add while airflow is running?
you can go to the official website where there is a detailed start-up doc.

I would like to know how can i add a new dag while docker-compose is running?

just add DAG file in the DAG folder

How i delete a dag add while airflow is running?

before airflow 1.10.1 remove DAG file from DAG folder and run CLI airflow delete_dag <DELETE_DAG_NAME>, and wait for minutes ui refresh


yarn.lock outdated

You apparently ship an outdated yarn lock file

Hi @philkunz, we will look into this. Thanks for reporting.

yarn.lock isn't used anymore.


Decoder picks only one value when array is present in query params as Array[]=x&Array[]=y

Package version v3.1.4
Issue: Decoder picks only one value when the array is present in query params as Array[]=x&Array[]=y
Code sample, to showcase or reproduce:

package main

import (
	"fmt"
	"log"
	"net/url"

	"github.com/go-playground/form/v4"
)

type PostsRequest struct {
	PostIds     []string
	Projections []string
}

var decoder *form.Decoder

func main() {
	decoder = form.NewDecoder()

	values := parseForm()

	var req PostsRequest

	err := decoder.Decode(&req, values)
	if err != nil {
		log.Panic(err)
	}

	fmt.Printf("%#v\n", req)
}

func parseForm() url.Values {
	return url.Values{
		"PostIds[]": []string{"1", "2"},
	}
}

Printed response is :
main.PostsRequest{PostIds:[]string{"1"}, Projections:[]string(nil)}

@ankitaSejal There is a mismatch with the struct field name and the url.Values name which is why it appears to not be working. It's getting a single value set by total cooincidence of how the code flows(which I will be looking into further to prevent future confusion).
The struct field name is PostIds but the url .Value name is PostIds[], hence the mismatch. The PostIds[n] syntax only works when an index is specified.
Adding the form field name like so should solve your issue OR changing the url.Value to drop the brackets []
	type PostsRequest struct {
		PostIds     []string `form:"PostIds[]"`
		Projections []string
	}

I also updated the library to surface the issue to avoid confusion like this in the future https://github.com/go-playground/form/pull/61/files


Cannot find: uncased_L-24_H-1024_A-16.zip

Hello,
I am trying to follow a tutorial about BERT however the file: uncased_L-24_H-1024_A-16.zip cannot be found anymore (and the pre-trained BERT models cannot be found either...).
Can you help me?
Thank you.

Does this link not work for you? [Link]
There is also a more recent model trained on the whole-word-masking strategy [Link]


Create skurek.is-cool.dev.json

Requirements

[x] You have completed your website.
[x] The website is reachable.
[x] The CNAME record doesn't contain https:// or /.
[x] There is sufficient information at the owner field.
[x] Your website is not hosting on the following due to SSL issues: Vercel, Netlify

Description
For games servers like minecraft or project zomboid
Link to Website

Thank you for your submission, we really appreciate it. Like many open-source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution. You can sign the CLA by just posting a Pull Request Comment same as the below format.

I have read the CLA Document and I hereby sign the CLA

You can retrigger this bot by commenting recheck in this Pull Request. Posted by the CLA Assistant Lite bot.

I have read the CLA Document and I hereby sign the CLA

I have read the CLA Document and I hereby sign the CLA


feat: filtering transaction messages by multiple conditions

Descriptions
Change to allow multiple transactional message filters.
Changes in this PR.

Receive a list of transaction message filter options.
If one of the conditions is met, the message filter options and the transaction's message list,
the message can be retrieved.

Example

We are suffering from Feature Creep on filters. Let me know what you think about https://github.com/gnolang/tx-indexer/issues/76

@ajnavarro
I'll merge this out and we can see how to have this same functionality much more elegantly


docs.rs builds failing

https://docs.rs/crate/opendp/0.9.2-nightly.20240314.1:

docs.rs failed to build opendp-0.9.2-nightly.20240314.1
Please check the build logs for more information.
See Builds for ideas on how to fix a failed build, or Metadata for how to configure docs.rs builds.
If you believe this is docs.rs' fault, open an issue.
Visit the last successful build: opendp-0.9.0-nightly.20240131.1

Looking at the log:
[INFO] running `Command { std: "docker" "start" "-a" "8ae8bda3af16bcc3d43a4dbd7cae80ecaa2f8df519d3c1b46653fd90be21c0a4", kill_on_drop: false }`
[INFO] [stderr] warning: target filter specified, but no targets matched; this is a no-op
[INFO] [stderr]    Compiling opendp v0.9.2 (/opt/rustwide/workdir)
[INFO] [stderr] error: failed to run custom build command for `opendp v0.9.2 (/opt/rustwide/workdir)`
[INFO] [stderr]
[INFO] [stderr] Caused by:
[INFO] [stderr]   process didn't exit successfully: `/opt/rustwide/target/debug/build/opendp-7e653207d04b3d6f/build-script-main` (exit status: 101)
[INFO] [stderr]   --- stdout
[INFO] [stderr]   cargo:rerun-if-env-changed=OPENDP_SPHINX_PORT
[INFO] [stderr]   cargo:rerun-if-env-changed=OPENDP_RUSTDOC_PORT
[INFO] [stderr]   cargo:rerun-if-env-changed=OPENDP_REMOTE_SPHINX_URI
[INFO] [stderr]   cargo:rerun-if-env-changed=OPENDP_REMOTE_RUSTDOC_URI
[INFO] [stderr]
[INFO] [stderr]   --- stderr
[INFO] [stderr]   thread 'main' panicked at /opt/rustwide/cargo-home/registry/src/index.crates.io-6f17d22bba15001f/cbindgen-0.20.0/src/bindgen/bindings.rs:101:43:
[INFO] [stderr]   called `Result::unwrap()` on an `Err` value: Os { code: 30, kind: ReadOnlyFilesystem, message: "Read-only file system" }

My sense is that the Read-only file system error is a red herring: It also shows up in this report, where the real problem was unrelated.
There are instructions for emulating the doc.rs build... but if we have any intuition about what's going wrong, it'd be good to try that before going too deep.

Changed my mind: Not a red herring.
https://docs.rs/about/builds#read-only-directories

Write attempt on read-only directories
Most of the sandbox is a read-only file system, including the source directory of your crate and its dependencies. If your build.rs generates files that are relevant for documentation, consider writing to the cargo output directory, passed in the environment variable OUT_DIR.

Do we write to the source directory of the crate? Yes we do, in generate_header(), which creates opendp.h
When was it introduced?
6ce2362cd (Michael Shoemate 2024-02-01 12:44:42 -0500  49) fn generate_header() {

that's the R bindings PR.
What is the last successful docs.rs build?

Visit the last successful build: opendp-0.9.0-nightly.20240131.1

ie, the day before.

Can this output file be moved over to the R directory?
Is there a code or process change that would help us catch docs.rs problems earlier?
See also #1430

The fix here is to just adjust the #[cfg(feature = "ffi")] to #[cfg(feature = "bindings")] (as well as the cfg guard on the function it decorates).
Explanation: All code-gen should be behind bindings, because Cargo.toml enables ffi for docs.rs builds.


cursor: pointer instead of href="#"?

In both master and 2.0-wip, Alerts (and probably some other components) use × for close buttons. Using href="#" to display the correct cursor can be problematic (clicking on it changes the URL and therefore adds to the tab history, scrolls the page to the top, etc), but can be replaced with cursor: pointer in CSS.
Is there any reason to not do this, or is it just a change waiting to be made? I can submit a pull request.

Resolved this—good call.


use $templateRequest from AngularJS in ui-router 0.3.2

modified $templateFactory to use $templateRequest provider of
AngularJs in case it is avalable
removed the test case which enforces the setting of request header
Accept: text/html

@christopherthielen i am not sure why that build is failing I have run all the supporting version from 1.2.x

ok ... good to go ... it was failing in Angular 1.0.8 ... fixed and tests passed.

Closing in favor of #3182


Upgrade IAVL use the latest version of iavl 1.1.x

Chore: Upgrade IAVL use the latest version of iavl 1.1.x to fix https://github.com/VolumeFi/paloma/issues/1861
Sources:
https://github.com/cosmos/cosmos-sdk/issues/20746
https://github.com/cosmos/iavl/pull/880
https://github.com/cosmos/iavl/issues/956

Fixed with https://github.com/palomachain/paloma/pull/1219


Add password manager to application

This is a very complex addition for the application

We just found the Android Autofill Framework which makes the integration of a password manager to the application viable.

Autofill service is implemented. Improvements to the service is documented through other issues.


overlapblock Creator - Web design #4

https://images01.nicepagecdn.com/page/54/40/html-template-54401.jpg Design a overlapblock like the above image
Create a file "overlapblock_NUM_by_(YourName).html" in the modules/overlapblock folder.
Use simple HTML and CSS and JAVASCRIPT to create the overlapblock animation. You can use the interface development https://kwickerhub.com/ (This project) or you can write the lines of code yourself.
Step by Step Guide.
Fork this project(Use the 'fork' button in the top right corner) and Clone your Fork.
git clone https://github.com/YOUR_USERNAME/frontend
Open your code Editor and Create a file "overlapblock_NUM_YOUR_NAME_.html" in the "modules/overlapblock" folder of this project you just cloned. No need to create head, title and body tags, Just Add a div tag with some embedded style(i.e use the style tag) and the script tag where necessary.
If you want to add an image resource, please add it in the folder ••
"modules/overlapblock/images_and_icons"
We recommend you use an svg for your image/icon.
Push your Code: You need to push your recent changes back to the cloud. Use the command below in the main directory of this Repository
git push origin dev
or use a GUI tool to avoid mistakes or complexity. LOL.
Then make you Pull Request...
Below is a example of the code structure we need:
'''

'''
For more examples:
modules->buttons
modules->cards
for examples of contributions or Pull request accepted in to the project.
And please do not wait for this issue to be assigned to you as we have limited hands but have a lot to do/cover. Please send in your PR.
Good-luck.

I am working on this issue.

@NtemKenyor Hi, I am working on this issue right now.


Add SingleStat Panel for Active Triggers based on Severity

I'm submitting a ...

[X] Feature request

Add SingleStat Panel to show amount of Triggers active based on Severity.

@MogiePete this is duplicated by #141


x/mobile/cmd/gomobile: Go1.15beta1 cannot generate Objective-c bindings if target includes amd64

What version of Go are you using (go version)?

$ go version
go version go1.15beta1 darwin/amd64

Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GOARCH="amd64"
GOOS="darwin"

What did you do?
gomobile bind -v -target=ios .
gomobile bind -v -target=ios/amd64 .
Both fail with the same error.

What did you expect to see?
Generate objective-c framework
What did you see instead?
clang: error: invalid argument '-mmacosx-version-min=10.11' not allowed with '-mios-simulator-version-min=7.0'
clang: warning: using sysroot for 'iPhoneSimulator' but targeting 'MacOSX' [-Wincompatible-sysroot]

CC @hyangah @eliasnaur @dmitshur

Confirmed the issue.
I'm not sure where -mmacosx-version-min=10.11 came from. I think this is from Go 1.15 compiler, but is that true?

$ find . -name "*.go" | xargs grep "mmacosx-version-min"
./src/crypto/x509/root_cgo_darwin_amd64.go:#cgo CFLAGS: -mmacosx-version-min=10.11

My guess is that this should be omitted when ios build tag exists.

This issue does not happen with the latest Go, then the next version of Go 1.15 has already fixed this issue.
(Probably https://github.com/golang/go/commit/72019cf3128af1b8f48f7ec5f04bc04a98c23131 fixed this?)

Go 1.15 rc1, which was released 30 minutes ago, did not cause this issue. Let me close this.

Thanks for investigating and confirming this is fixed, Hajime.


Feature - disable nhentai number in the ComicInfo.xml

Love the work you are doing here 9-FS.
I am seeing that the nhentai ID number is put in the title of the ComicInfo.xml  field.
I would like to disable this, it would make the books look more tidy in a library if it didn't have the number (and also allow more room to display long titles). You wouldn't loose sorting either, because upload date is included in ComicInfo.xml.
-Thank you

Gude MrHakisak, I agree that having the ID in the <Title> field is not ideal. Better would be to use a proper field for the ID only like the <Number> field for example. But nHentai Archivist's created library is currently optimised to be hosted by Komga (simply because that's what I use and I don't know a better option) and I couldn't figure out how to search by <Number> using Komga.
I'm not a big fan of introducing another setting for edge cases, adding more complexity and potentially library inconsistencies. So if I'm going to make a change to the ComicInfo.xml, I'd like to do it only once to keep breaking changes to a minimum and fixing the situation altogether.
So if you have a suggestion on where to put the nhentai ID instead and still be able to search by it using Komga, I'm very open to that change.
I am currently using Komga and have every work categorised as a oneshot, so each work's individual tags are used and no tags grouped in series. As I've said, putting nHentai ID in <Number> does not allow for searching. Another possibility, that has been proposed before, would be to add the ID as a tag, but that would literally create hundreds of thousands of individual tags with 1 entry making the filter by tag sidebar completely unusable. And it wouldn't allow for easily searching by tag either.

I am new to Komga and cbz files, but I spent a few hours.
I have tried to run a few tests by modifying the ComicInfo.xml, I have tried replacing the number from the title and put it into different fields: Number, Count, Volume, AlternateNumber, AlternateCount, Summary (which shows on komga but can't be searched), Notes, GTIN.
Some things that do work:
Putting the ID at the end of the title.
Adding the ID as an aditional Writer.
or any of these fields:
Penciller, Letterer, Inker, Editor, Cover, Colorist
This is what a oneshot would look like if some of those fields are filled in:

You would search for them here like this:

Do with this information how you wish (but let me know if you decide against doing any of these changes so I can just start scraping). Also unless there is a software out there that can batch rename every book (let me know if there is), it would mean you would have to re-scrape everything again.

Okay I didn't know <Writer> had its own search field. This is pretty cool.
I am currently inclined to add the ID in <Writer> and add a setting to enable having ID additionally in the title just like now, but defaulted to off.

Please don't add the ID into Writer.  I have Writer mapped to artist in LANraragi right now and I already modified the file to account for it.  As it stands I already have a mini patch that changes how nhentai_archivist writes out the Web field because the nHentai metadata plugin over on LANraragi doesn't expect it to have a protocol set at the start.
As it stands the ComicInfo plugin over there isn't able to get the tags from your ComicInfo file.  It's probably a bug.  One that I have not gone through the trouble to fix so I just pull from nHentai in batches.
With all that said I know you are targeting Komga so if you do make a change then I'll adjust depending on the change (if any).

Hmm you're making a good point though. <Writer> is already being used by artists and mixing the field with ID is probably not a good idea.
Komga also offers the fields "pencillers", "inkers", "letterers", "cover", "editors", and "translators". Except for "translators", I'm currently using none of the other fields which could then be used to save the ID. This feels pretty random and unexpected though... I wish they would just allow searching by <Number>.

I opened a feature request on komga git. They seem kinda active so let's see what they do

I'm getting crazy bot vibes from the Komga developer to be honest, I think it's time to prepare a plan B in case he's not going to make any changes.

Komga also offers the fields "pencillers", "inkers", "letterers", "cover", "editors", and "translators".

We could still do this, but this feels more like a hack than a solution.

I was watching, it was strange and unfortunate.
Thank you so much for trying. It's not the end of the world.
I am okay with putting the ID in any of those fields, I agree it feels like a hack. That is okay with me, whatever you are comfortable with. Thank you for trying to be accommodating.

Yeah he just closed and locked the discussion after I pointed out that his suggestions aren't helpful and he even said so himself; certified bot behaviour.
I'm thinking about migrating to LANragi altogether as Komga is generally incredibly slow and unreliable. @shinji257 Any tips?

Here are the points I'm hitting.  Currently working with it as it stands myself but doesn't mean that others want to.

LANraragi has long load times with large libraries.  I dunno.  Probably 25k+ or something.
ComicInfo plugin needs work to be able to pull in all the metadata from your program.  Currently my version is half baked as it doesn't do tags but I managed to patch some of the other stuff to align.

Once it does load the library it is generally pretty snappy imo.

Oof no tags are a problem.

adding my two cents here since you mentioned LANraragi.
I'm currently archiving nhentai with your tool + LANraragi. Some comicinfo.xml files do indeed not get read, can't say if that is because I run the plugin at import or because of some other reason.
What I noticed is like shinji257 mentioned, it does take a while to load, especially at startup. In my case, I am also unable to tag archives using the built in batch operations, as the application stops the process. While I have not yet opened an issue about that it is somewhat annoying that the tagging is not that reliable

This is the main reason why I use the nhentai plugin to tag the archives.  I made some adjustments in my ComicInfo.  Specifically the following alterations were made partially to accomidate the nhentai plugin.  The other accomidation was the edit I did in this program so that the URL format is what that plugin expects.
ComicInfo is set to give the Genre the category metadata prefix
artist is defined by the Writer ComicInfo tag
group is defined by the Publisher ComicInfo tag
The tag import code is completely disabled in my copy since it is unreliable/broken right now.
All of this prevents duplicate tags like the artist ending up in both the artist and group tag thanks to the default ComicInfo code.
I know that per the ComicInfo definition that Komga has it is pretty flexible on this.

I was thinking about creating a small script that interacts with the db and the api from lanraragi to get untagged files and query the db to get the tags. Will see how that goes, otherwise I'll have to re-tag my library

Proposal for Komga as I was mucking with the ComicInfo.xml import for it.
Move the source id to a tag.  Make it source: {id} or nhentai: {id}.  This is searchable by Komga by doing tag: {id} and it will locate it.

Got a test implentation done.  Probably not the best way as I'm very much a beginner on Rust but I'll still have it on my branch to be looked at.

Oof no tags are a problem. I'll try it out myself as soon as I have the time.

I'm incorrect on this.  I thought tags were not working but they are working just fine.  The only thing is that categories do not have a category prefix but eh.  At least it is there.  I want the upload timestamp and I can't figure out how to convert the Month/Day/Year back to epoch for LANraragi to handle so I went into your code and did a non-standard Timestamp field and have LANraragi's ComicInfo plugin referencing it in my edits.  It also doesn't set titles so I changed that too... I think.


nice: cannot set niceness: Permission denied

From homebrew-core: https://github.com/Linuxbrew/homebrew-core/issues/7404
Please always follow these steps:

[X] Confirmed this is a problem with brew installing one, specific formula and not every time you run brew? If it's a general brew problem please file this issue at https://github.com/Linuxbrew/brew/issues/new.

[X] If you have a macOS system and can replicate the problem on macOS with Homebrew, please report the issue to Homebrew/core and follow their issue template from your macOS system. If you are unsure, please report the issue to Linuxbrew.

I'm running WSL (Ubuntu 16.04.4 LTS) on Win 10 Pro 1709.

[X] ran brew update and can still reproduce the problem?

[X] ran brew doctor, fixed all issues and can still reproduce the problem?

[X] Ran brew gist-logs <formula> (where <formula> is the name of the formula that failed) and included the output link?

stuart@desktop:~$ brew gist-logs hello
Error: No logs.
stuart@desktop:~$ brew gist-logs p7zip
Error: No logs.

[X] If brew gist-logs didn't work: ran brew config and brew doctor and included their output with your issue?

NB: I built Ruby outside of linuxbrew before installing linuxbrew.

stuart@desktop:~$ brew doctor
Please note that these warnings are just used to help the Homebrew maintainers
with debugging if you file an issue. If everything you use Homebrew for is
working fine: please don't worry or file an issue; just ignore this. Thanks!

Warning: Unbrewed header files were found in /usr/local/include.
If you didn't put them there on purpose they could cause problems when
building Homebrew formulae, and may need to be deleted.

Unexpected header files:
  /usr/local/include/ruby-2.5.0/ruby.h
  /usr/local/include/ruby-2.5.0/ruby/backward.h
  /usr/local/include/ruby-2.5.0/ruby/backward/classext.h
  /usr/local/include/ruby-2.5.0/ruby/backward/rubyio.h
  /usr/local/include/ruby-2.5.0/ruby/backward/rubysig.h
  /usr/local/include/ruby-2.5.0/ruby/backward/st.h
  /usr/local/include/ruby-2.5.0/ruby/backward/util.h
  /usr/local/include/ruby-2.5.0/ruby/debug.h
  /usr/local/include/ruby-2.5.0/ruby/defines.h
  /usr/local/include/ruby-2.5.0/ruby/digest.h
  /usr/local/include/ruby-2.5.0/ruby/encoding.h
  /usr/local/include/ruby-2.5.0/ruby/intern.h
  /usr/local/include/ruby-2.5.0/ruby/io.h
  /usr/local/include/ruby-2.5.0/ruby/missing.h
  /usr/local/include/ruby-2.5.0/ruby/onigmo.h
  /usr/local/include/ruby-2.5.0/ruby/oniguruma.h
  /usr/local/include/ruby-2.5.0/ruby/re.h
  /usr/local/include/ruby-2.5.0/ruby/regex.h
  /usr/local/include/ruby-2.5.0/ruby/ruby.h
  /usr/local/include/ruby-2.5.0/ruby/st.h
  /usr/local/include/ruby-2.5.0/ruby/subst.h
  /usr/local/include/ruby-2.5.0/ruby/thread.h
  /usr/local/include/ruby-2.5.0/ruby/thread_native.h
  /usr/local/include/ruby-2.5.0/ruby/util.h
  /usr/local/include/ruby-2.5.0/ruby/version.h
  /usr/local/include/ruby-2.5.0/ruby/vm.h
  /usr/local/include/ruby-2.5.0/x86_64-linux/ruby/config.h

Warning: Unbrewed .pc files were found in /usr/local/lib/pkgconfig.
If you didn't put them there on purpose they could cause problems when
building Homebrew formulae, and may need to be deleted.

Unexpected .pc files:
  /usr/local/lib/pkgconfig/ruby-2.5.pc

Warning: Unbrewed static libraries were found in /usr/local/lib.
If you didn't put them there on purpose they could cause problems when
building Homebrew formulae, and may need to be deleted.

Unexpected static libraries:
  /usr/local/lib/libruby-static.a
stuart@desktop:~$ brew config
HOMEBREW_VERSION: 1.6.2
ORIGIN: https://github.com/Linuxbrew/brew
HEAD: 64d5cb51032e4f303bea33d88d02cad0f7327d33
Last commit: 7 days ago
Core tap ORIGIN: https://github.com/Linuxbrew/homebrew-core
Core tap HEAD: 33de5ecc134c491f7ba1223cfece1b737e0ab9aa
Core tap last commit: 3 hours ago
HOMEBREW_PREFIX: /home/linuxbrew/.linuxbrew
HOMEBREW_REPOSITORY: /home/linuxbrew/.linuxbrew/Homebrew
HOMEBREW_CELLAR: /home/linuxbrew/.linuxbrew/Cellar
HOMEBREW_CACHE: /home/smorris/.cache/Homebrew
HOMEBREW_DEV_CMD_RUN: 1
CPU: octa-core 64-bit 0x69e
Homebrew Ruby: 2.3.3 => /home/linuxbrew/.linuxbrew/Homebrew/Library/Homebrew/vendor/portable-ruby/2.3.3/bin/ruby
Clang: N/A
Git: 2.7.4 => /usr/bin/git
Curl: 7.47.0 => /usr/bin/curl
Java: N/A
Kernel: Linux 4.4.0-43-Microsoft x86_64 GNU/Linux
OS: Ubuntu 16.04.4 LTS (xenial)
Host glibc: 2.23
/usr/bin/gcc: 5.4.0
glibc: N/A
gcc: N/A
xorg: N/A

To help us debug your issue please explain:

What you were trying to do (and why)

(Re)install a formula

stuart@desktop:~$ brew reinstall hello
==> Reinstalling hello
==> Downloading https://linuxbrew.bintray.com/bottles/hello-2.10.x86_64_linux.bottle.tar.gz
Already downloaded: /home/stuart/.cache/Homebrew/hello-2.10.x86_64_linux.bottle.tar.gz
==> Pouring hello-2.10.x86_64_linux.bottle.tar.gz
nice: cannot set niceness: Permission denied
🍺  /home/linuxbrew/.linuxbrew/Cellar/hello/2.10: 52 files, 277KB
stuart@desktop:~$ brew install p7zip
Updating Homebrew...
==> Auto-updated Homebrew!
Updated 1 tap (homebrew/core).
==> Updated Formulae
armor            coffeescript     kotlin           netpbm           numpy            pdfgrep          tj
bit              emscripten       nethack          notmuch          pc6001vx         rclone

==> Downloading https://linuxbrew.bintray.com/bottles/p7zip-16.02_1.x86_64_linux.bottle.tar.gz
######################################################################## 100.0%
==> Pouring p7zip-16.02_1.x86_64_linux.bottle.tar.gz
nice: cannot set niceness: Permission denied
🍺  /home/linuxbrew/.linuxbrew/Cellar/p7zip/16.02_1: 103 files, 5.6MB

What you expected to happen

(Re)install formula without error

Step-by-step reproduction instructions (by running brew commands)

brew reinstall hello
brew install p7zip

nice: cannot set niceness: Permission denied

You can safely ignore this warning. It's an upstream bug in Microsoft Windows. See the upstream issue at https://github.com/Microsoft/WSL/issues/1838


Split API Call Block into Separate Pre/Post Call Blocks

The current capture behavior us to record both the input and output/return values for an API call in single packet, which is written to the capture file after the API call has returned.  This behavior could be modified to split the input and output values into separate packets, with inputs written before the API call and outputs written after the API call.
This could be useful for capturing crashes where the crash happened in the API call due to invalid inputs.  With the current behavior of logging the packet after the API call, the packet would not be written to the file in the case of a crash.  Note that this is only true for API calls with return values and/or output parameters.  For API calls that only have input parameters, the packet is logged before the API call.
In theory, this could also be used for basic synchronization with multi-threaded replay.  Packets captured in the following order would indicate that threads 1 and 2 executed API calls at roughly the same time, while thread 3 executed its API call after thread 1 and 2 completed their calls:

Thread 1 Input
Thread 2 Input
Thread 2 Output
Thread 1 Output
Thread 3 Input
Thread 3 Output

The replay tool would interpret this to mean that the calls from threads 1 and 2 could be executed in parallel by worker threads, but thread 3's call should not be executed until the other calls complete.  Multi-threaded replay would then follow a pattern where it reads an Input packet from the file and dispatches that packet to a worker thread.  It would continue reading and dispatching Input packets until it encounters an Output packet.  When encountering an Output packet, the dispatch thread would block until the associated worker thread completes its API call and commits any resulting state changes (eg. mappings for newly created handles) before continuing to read and process packets from the capture file.
Some downsides to this approach are that every API call, even calls without return values or output parameters, would need an Output packet, and that it complicates single threaded replay.  For single threaded replay, Input packets would need to be queued until the associated Output packet is read.  To maintain the proper API call order, queue entries can only be processed when the item at the front of the queue is complete.
Edit 2023-03-30 by @andrew-lunarg
Looks like Dustin did some work on this: https://github.com/LunarG/gfxreconstruct/compare/dev...dustin-lunarg:gfxreconstruct:dustin_separate_in_out_packets

For true multi-threaded replay it would be better to read from multiple input blocks/files, one per thread, to avoid this problem entirely. When thinking about redoing packets, it would be good to split compression packets and data packets apart, as what is a good size for a compression packet is probably not a single data packet, and merging these two into a single packet type seems both conceptually wrong and inefficient.

Dustin seems to have been using the terms "packet" and "block" interchangeably (as does our code a bit), whereas you seem to be calling a per-thread trace a "block" Per. Your points are interesting but seem orthogonal to Dustin's reasons for making this issue.
Can we agree to use the term block in its dominant GFXR meaning * in this topic?
I think your points are:

Capturing separate trace files, one per thread has performance advantages.
Decoupling units of compressed data from the blocks allows higher performance and better compression ratios (I know your own vk capture tool lavatube has a compression thread and a file write thread per captured thread so I imagine you have tuned the compression buffer size to keep that pipeline flowing).

Dustin seemed concerned about:

Capturing the inputs to an API call before the call is taken so they are available in case the call crashes.
Preserving the order that calls were made into the API at capture time across all threads when a trace is replayed on multiple threads.

On the second point from Dustin, one reason for this is in the case that the application used its own thread synchronisation rather than purely Vulkan mechanisms, this order may matter for correctness. Examples might be thread one submits a bunch of work, then notifies waiting thread two when it knows that work is complete. Thread two wakes and deletes a bunch of Vulkan handles to resources that it now knows is not in flight on the GPU. If we had just blindly replayed the traces for each thread as fast as they will go, thread two can delete resources still in flight on the GPU.
I think your points are very good ones but perhaps not related to this issue directly. Please do let us know here if you've got solutions from your prototype to the problems Dustin was laying out above. We should continue the conversation about your points in the previous message elsewhere if I have understood them correctly or please let me know if I missed something you were trying to get across.
*
// framework/format/format.h
enum BlockType : uint32_t
{
    kUnknownBlock                = 0,
    kFrameMarkerBlock            = 1, // Marker to denote frame status, such as the start or end of a frame.
    kStateMarkerBlock            = 2, // Marker to denote state snapshot status, such as the start or end of a state snapshot.
    kMetaDataBlock               = 3,
    kFunctionCallBlock           = 4,
    kAnnotation                  = 5,
    kMethodCallBlock             = 6,
    kCompressedMetaDataBlock     = MakeCompressedBlockType(kMetaDataBlock),
    kCompressedFunctionCallBlock = MakeCompressedBlockType(kFunctionCallBlock),
    kCompressedMethodCallBlock   = MakeCompressedBlockType(kMethodCallBlock),
};

I don't think this is purely a matter of performance, though. Effectively replaying multi-threaded content also means being able to reproduce the original workload where things actually ran in parallel, which in turn requires a certain amount of performance. One lesson learned from implementing this in patrace was that if you don't get the basic synchronization design right, your multi-threaded replay can end up slower than single-threaded and for that reason be less parallelized when the work ends up on the GPU. But yes, should probably continue this discussion elsewhere :-)
My point is that I don't see how the above is actually solving multi-threading. I haven't thought about the debugging app crashes use case much (it is not what we do), but couldn't you instead use the signal handler here and write out all the relevant information through a callstack to the log instead?

That all makes a lot of sense, thanks :).
Given your PPA focus I'm guessing that being able to light up as much as possible of a pre-silicon (model/simulation/emulation/pick your group's favourite term) would guide a lot of what you have done. Other use cases might care more about optimising applications on released products and have a full system profiler enabled during capture and replay. There could be tradeoffs there from adding a compute thread for compression and IO thread for every application thread calling through the captured API.
But yes, it doesn't make sense to keep scattering this discussion over old issues.


change to Recommended Apps codeunit

The codeunit is named Recommended Apps, not Recommend Apps

Thanks for your contribution, much appreciated!