Documentation is not comprehensive

The documentation provided in the READ ME is not very comprehensive and is not up-to-date.
Apparently DiscordEventHandler is not in existence, so I cannot get very far.

This is in 1.5.1 btw

Allow me to notify @Vatuu.

Alright!
So I had a talk with Vatuu, send me the version of discord-rpc you're including in your project. If you are unsure show me the dependency snippet from Gradle or Maven and I can assist from there.

@AwesomeCodePerson Its DiscordEventHandlers


Error: Can't get URL for Camera

This was a previous bug report but was closed with a request to open with proper documentation. Issue still remains.
https://github.com/fuatakgun/eufy_security/issues/287
Error shows up at the top of Dashboard cards when trying to add a camera by entity ID. It seems to mostly be an issue with battery cameras, but I also see it intermittently with my plugin Eufy Indoor Cam E220 pan and tilt camera. I believe this is an issue related to the fact that battery cameras do not have a constant RTSP stream and rather only start the stream when motion is detected on the camera. I believe the error may be coming from either go2rtc or WebRTC, so it may need to be raised in one of those projects. But it also may be an integration issue, so I was hoping it could be looked into here first.
I have found that if you add the camera with the direct URL in the Dashboard card, the camera streams work fine, but this solution does not allow for previous event images to be displayed as poster images when the RTSP stream is not available.
To reproduce
Steps to reproduce the behavior:

Add a Dashboard card with the boilerplate yaml from the documentation and update the camera entity name with a battery operated camera that supports RTSP.
Notice the error at the top of the card.

Expected behavior
Stream would display for camera after camera detects motion without an error, and a poster image would be displayed from the previous event when the stream stops.
Additional information
Go to Settings -> System -> Repairs -> Click on 3 dots (...) -> System Information and get Version and Installation Type to below fields;

Home Assistant Installation Type (OS - Supvervised - Core): VM Home Assistant OS
Home Assistant Core Version: core-2023.12.3
Eufy Security Add-on Version: N/A (Deprecated)
Eufy Security Integration Version:

Hardware Information;

Camera Model: Homebase 3 and Eufy Cam 3. Has issues with other battery cameras as well including Eufy Cam 2. I have tried on Homebase 2 and issue remains.

Live Streaming Protocol (RTSP/P2P): RTSP and P2P

Debug Logs from Home Assistant - Usernames/Passwords/Serial Numbers redacted.

hass_eufy_security_log.txt

Would you share your device with me in case further debugging required? (Yes/No): Yes

Additional context
As mentioned previously, I believe the error may be coming from either go2rtc or WebRTC, so it may need to be raised in one of those projects. But it also may be an integration issue, so I was hoping it could be looked into here first.
I will be sure to buy a coffee for the help. Thanks!

I noticed that the camera entities / streams are not getting added to go2rtc unless I add the card with a manual URL. Then the RTSP URLs will show in go2rtc and I can click and view the stream. I think that may be part of the issue and I am wondering how the integration with go2rtc is supposed to work and if I should be seeing all of my camera IDs in go2rtc. Currently this is not working.

I have same problem with all my eufy camera.

Looks like @fuatakgun just dropped a major update (version 8.0.0) just a few hours ago. But it has a breaking dependency on a new version of go2rtc that has yet to be released, which hopefully will be released soon. Check out the build notes for more info. I am hoping this will be fixed in the new version once it is available.

Please get webrtc from my fork following readme. It has respective dependency

Please get webrtc from my fork following readme. It has respective dependency

Thanks. It's working better at least for RTSP cameras, but I am now having a new issue with trying to edit the configuration of Eufy Security Integration. It's throwing an error - Config flow could not be loaded: 500 Internal Server Error Server got itself in trouble
I'll log a new bug so you can close this one.

Hi, I am new to HA. I have set local Tuya, some water, temp sensors, door locks and now the Eufy cameras. I have received this error too.
I am using home base 2, dual cam doorbell and a bunch of wifi flood light cam and flood light pro. When I use stock HA camera entity card, it shows picture of the last event detected (unreliably). Also, the picture of the last event is a couple of days old sometimes (this is the stock card, not custom webrtc card).
WebRTC card does not start stream and shows Can't get URL for camera.backyard.
Is there an update or debug that I can try?

Same happening with me to.

Same problem here

got this same issue this is my code:
square: false
type: grid
columns: 1
cards:
  - type: entities
    entities:
      - entity: switch.salon_camera_enabled
        name: Camera enabled
      - entity: select.salon_guard_mode
        name: Guard Mode
      - entity: binary_sensor.salon_crying_detected
        name: Crying detected
      - entity: sensor.salon_current_mode
        name: Current Mode
      - entity: binary_sensor.salon_debug_device
        name: Debug (device)
      - entity: binary_sensor.salon_debug_station
        name: Debug (station)
      - entity: binary_sensor.salon_motion_detected
        name: Motion detected
      - entity: binary_sensor.salon_person_detected
        name: Person detected
      - entity: sensor.salon_person_name
        name: Person Name
      - entity: binary_sensor.salon_pet_detected
        name: Pet detected
      - entity: binary_sensor.salon_snooze
        name: Snooze
      - entity: sensor.salon_snooze_time
        name: Snooze Time
      - entity: binary_sensor.salon_sound_detected
        name: Sound detected
    title: Salon
  - type: alarm-panel
    entity: alarm_control_panel.salon
  - type: custom:webrtc-camera
    entity: camera.salon
    ptz:
      service: eufy_security.ptz
      data_left:
        entity_id: camera.salon
        direction: LEFT
      data_right:
        entity_id: camera.salon
        direction: RIGHT
      data_up:
        entity_id: camera.salon
        direction: UP
      data_down:
        entity_id: camera.salon
        direction: DOWN

and result:

Add-on is working, i can switch camera on and off

I had the same issue. It was fixed by setting the camera’s streaming quality to low.

I had the same issue. It was fixed by setting the camera’s streaming quality to low.

@sysofwan, did you make any other change? I tried changing stream quality to low but made no difference. My card code is below. I have tried with a simpler, first two lines from the card as well.
type: custom:webrtc-camera
entity: camera.backyard
poster: image.backyard_event_image
ui: false
shortcuts:
  - name: Play
    icon: mdi:play
    service: camera.turn_on
    service_data:
      entity_id: camera.backyard
  - name: Stop
    icon: mdi:stop
    service: camera.turn_off
    service_data:
      entity_id: camera.backyard

Make sure the recording quality is also low. Also I find that sometimes I have to reload the page for steaming to start.

Make sure the recording quality is also low. Also I find that sometimes I have to reload the page for steaming to start.

Lowest I can set is 1080p and I have set that. No luck still.

same issue here, set my quality to 720 but no lock either

Same issue. I get @fuatakgun webrtc-camera card fork, my camera have RTSP disabled (otherwise motion detection is not working), and I always have this error:
Error requesting stream: camera.xxx does not support play stream service
The poster image isn't even displayed when streaming's off.
The thing is, I don't have an option to change streaming quality for my 2C cameras.

I had the same issue. It was fixed by setting the camera’s streaming quality to low.

This works for me. I was constantly getting: Can't get URL for camera.doorbell in my dashboard while the stream would work fine on go2rtc

I'm also having this issue - Camera quality is set to low. Attached are my logs: home-assistant.log

Here the same.
I am very fresh with homeassist.
i am come from iobroker and homekit. (for years). in this i have not any problems with the integration of the eufy.doorbell. it works every time well.

Seems like the most recent error stack is:
  File "/usr/local/lib/python3.12/site-packages/aiohttp/web_protocol.py", line 462, in _handle_request
    resp = await request_handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/aiohttp/web_app.py", line 537, in _handle
    resp = await handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/aiohttp/web_middlewares.py", line 114, in impl
    return await handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/http/security_filter.py", line 92, in security_filter_middleware
    return await handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/http/forwarded.py", line 83, in forwarded_middleware
    return await handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/http/request_context.py", line 26, in request_context_middleware
    return await handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/http/ban.py", line 85, in ban_middleware
    return await handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/http/auth.py", line 242, in auth_middleware
    return await handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/http/headers.py", line 32, in headers_middleware
    response = await handler(request)
               ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/helpers/http.py", line 73, in handle
    result = await handler(request, **request.match_info)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/webrtc/__init__.py", line 256, in get
    return await ws_poster(hass, params)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/webrtc/__init__.py", line 207, in ws_poster
    image_entity = _get_image_from_entity_id(hass, poster)
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/webrtc/__init__.py", line 188, in _get_image_from_entity_id
    raise Exception("Image not found")
Exception: Image not found

I have the same issue. However I did notice something. I have a webrtc camera defined:
  - type: custom:webrtc-camera
    entity: camera.carport_2
    poster: image.carport_event_image
    ui: true
    shortcuts:
      - name: Play
        icon: mdi:play
        service: camera.turn_on
        service_data:
          entity_id: camera.carport_2
      - name: Stop
        icon: mdi:stop
        service: camera.turn_off
        service_data:
          entity_id: camera.carport_2

With the above I always have the Can't get URL issue. Now I add the same camera as follows:
  - type: picture-entity
    entity: camera.carport_2
    stream_source: rtsp://<IP_ADDRESS>:8554/T8600XXXXXXXXX
    authentication: basic
    camera_view: live
    show_state: true
    aspect_ratio: 16x9

I refresh the dashboard: I still have the error. Now I press the play button and the picture-entity eventually shows streaming, although no moving pictures. Now I refresh the dashboard again and voila the webrtc camera is running and most of the times the picture-entity also. Is this already known and/or useful?


VM "Save as Template" enhancements

Author Name: Stefan Kooman (Stefan Kooman)
Original Redmine Issue: 5506, https://dev.opennebula.org/issues/5506
Original Date: 2017-10-26

Currently only the option of doing a VM "Save as Template" when the VM has STATE "POWEROFF". Most probably because of all referenced disks being cloned when doing a "Save as Template". I would like to propose the following enhancement options:

"Save as Template" WITHOUT DISKS (extra checkbox in sunstone)
"Save as Template" --force existing_template (Overwrite the contents of an already existing Template with this one)
"Save as Template" --update (variant on above: overwrite existing template REFERENCED in this template: TEMPLATE_ID. So overwrite "TEMPLATE_ID"). --update can be considered to be "linked" to originating template.

Our use case: we have a TEMPLATE for every VM running. If, for some reason or the other, we need to re-instantiate the VM we can do so. Every Template has a fixed IP in it for example, which could be lost if VM's were just re-instantiated / delete-recreated for example.
More general use case: Keep changes in template to golden template VM's in sync with the template

Original Redmine Comment
Author Name: Stefan Kooman (Stefan Kooman)
Original Date: 2017-10-26T11:41:53Z

Javi Fontan suggested I could hack the the ruby library (mad) disabling the actions checking / cloning the DISKS in the template. This works for CLI. See attached file virtual_machine.rb. This if of course a hack and disables the ability to clone with DISKS, but shows it's possible.

Closing this an adding link into #1326 to track all the SAVE_AS changes there


issue/pup-3948/vendor-deep_merge

I think we can remove installing deep_merge too in both git and packages acceptance:
$ git grep deep_merge acceptance
acceptance/setup/git/pre-suite/000_EnvSetup.rb:    step "#{host} Install deep_merge from rubygems"
acceptance/setup/git/pre-suite/000_EnvSetup.rb:    on host, 'gem install deep_merge'
acceptance/setup/git/pre-suite/000_EnvSetup.rb:    # skip deep_merge gem on windows
acceptance/setup/git/pre-suite/000_EnvSetup.rb:    step "#{host} Install deep_merge from rubygems"
acceptance/setup/git/pre-suite/000_EnvSetup.rb:    on host, 'gem install deep_merge'
acceptance/setup/packages/pre-suite/010_Install.rb:    # skip deep_merge gem on windows
acceptance/setup/packages/pre-suite/010_Install.rb:    step "#{host} Install deep_merge from rubygems"
acceptance/setup/packages/pre-suite/010_Install.rb:    on host, 'gem install deep_merge'

Oops, forgot that bit. Fixed.

Hmm, looking at travis.


Set Volume, Area, Length props on objects that have those properties

Where possible - and where it makes sense - objects that can/have the following props should have them set in the conversion routines, in units that match:

volume
area
length

dynamo and gh/rhino part of this was merged in #203, will open a new issue for the Revit part of things.


OutboundTrafficPolicy configurable per workload

Copy of https://github.com/istio/istio/pull/12910 but at annotation level instead of a full API change

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: howardjohn
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: greghanson
If they are not already assigned, you can assign the PR to them by writing /assign @greghanson in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

pilot/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@howardjohn: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-integ-k8s-tests.sh
e5231be79e8c17bf97ab64ffd20a12c7b4099088
link
/test istio-integ-k8s-tests

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

@howardjohn: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-integ-k8s-tests.sh
e5231be79e8c17bf97ab64ffd20a12c7b4099088
link
/test istio-integ-k8s-tests

prow/istio-pilot-multicluster-e2e.sh
e5231be79e8c17bf97ab64ffd20a12c7b4099088
link
/test istio-pilot-multicluster-e2e

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

What is the point of defining an API for group of sidecars but then forcing people to do this per workload instead?

This doesn't require making an API change late in the 1.1 release that we will need to support, has not gone through API review, etc. As Costin mentioned, the change at the API level would be fine in the master branch.

And in a world where pods come and go, what is the end user experience when she wants to configure this exception rule for pods in a particular namespace? Editing the Istio YAML blobs to create custom sidecar injectors for specific namespaces is definitely not a good user experience.

You just need add the annotation to the Deployment. I am not sure what you mean about custom injectors or pods coming and going.

So what happens to non K8S environments?

adding arbitrary annotations (esp ones that allow traffic to go unchecked) poses a security issue as well. Atleast the sidecar CRDs can be gated using RBAC rules.. annotations on deployments owned by service teams cannot be gated

adding arbitrary annotations (esp ones that allow traffic to go unchecked) poses a security issue as well. Atleast the sidecar CRDs can be gated using RBAC rules.. annotations on deployments owned by service teams cannot be gated

You can already just add sidecar.istio.io/interceptionMode: NONE and disable iptables entirely. I agree its a security issue though, that is a great point, but it also isn't a new one.
We already have many (20+) annotations, what happens in non k8s environments for all of those?
From what I can tell, you are against any/most changes with annotations, and @costinm is generally in favor of annotations for turning features on/off per workload. Can we come to a general consensus of when we should and shouldn't use annotations?

Personally, I am in favor of reducing the use of annotation if we can do it in API level.

I am not in favor of adding arbitrary annotation based switches in the proxy to control the configuration generation. This has several drawbacks.. The most important of which is that its not applicable for VM based environments where the proxy and bootstrap config are baked into the base VM image. Unlike k8s, there is no concept of a deployment or the ability to dynamically edit a "pod spec" to add these annotations. We have realized this the hard way, when deploying Istio purely on VMs for some of our customers. I do agree that we already have a huge list of annotations and I am working to get rid of them one by one. But the Sidecar is an integral piece in the mesh. I dont want to fragment this feature by adding k8s-only hacks in the metadata creating a partial solution and backward compatibility issues when we introduce an API driven way of controlling the outbound traffic policy per Sidecar. We might as well push this to 1.2 and do it the proper way.

Don't think this is happening for 1.1.
Lets get a real API change for Sidecar in for 1.2 instead


changed boolean and datetime attributes to string so export can work

About this pull request
Super simple! Output from the timeseries tools analysis could not be exported to netCDF because one of the attributes was a boolean ('timeseries:anomaly : True). Another attribute was a datetime object (timeseries:reference_range), which netcdf also did not allow for export.
All I did was ensure that these values were being converted to strings when building the new attribute dictionary.
To test, simply use the export to netcdf in the timeseries_example notebook. It should work!

I noticed a broken test and realized this PR is branched from a stale main branch that is 48 commits behind. Can you checkout main please and do a git pull and then branch and make the change and submit a new PR? Thanks.

I noticed a broken test and realized this PR is branched from a stale main branch that is 48 commits behind. Can you checkout main please and do a git pull and then branch and make the change and submit a new PR? Thanks.
Well, not unless there is a reason for using an older version of main of course. To me it seems the export code should be based on the latest main branch.

This should be fixed now!

I wasn't able to figure out how to create those attributes from the timeseries tool notebook, so I created a dummy dataset with the same attributes. But, the download didn't work :(
I've attached my testing notebook as a zip file here for you to look over.
I also think it would make more sense to look for attributes by type, not by name. As in, the function looks for attributes that are booleans, and converts to string, regardless of their name. Versus, looking for an attribute named "timeseries", and then redefining it as a string.
PR84_review.ipynb.zip

I've now seen where this is in the timeseries tool notebook. This PR works, and solves this issue. But regardless, I think it should check by attribute type, not by attribute name.

yeah, initially I wasn't sure how to do that (since I wouldn't want to
override say an int with a string), but I have an idea now.
On Tue, Sep 27, 2022 at 12:46 PM Nicole Keeney @.***>
wrote:

I wasn't able to figure out how to create those attributes from the
timeseries tool notebook, so I created a dummy dataset with the same
attributes. But, the download didn't work :(
I've attached my testing notebook as a zip file here for you to look over.
I also think it would make more sense to look for attributes by type, not
by name. As in, the function looks for attributes that are booleans, and
converts to string, regardless of their name. Versus, looking for an
attribute named "timeseries", and then redefining it as a string.
PR84_review.ipynb.zip
https://github.com/cal-adapt/climakitae/files/9659129/PR84_review.ipynb.zip
I've now seen where this is in the timeseries tool notebook. This PR
works, and solves this issue. But regardless, I think it should check by
attribute type, not by attribute name.
—
Reply to this email directly, view it on GitHub
https://github.com/cal-adapt/climakitae/pull/84#issuecomment-1259972953,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AWLSEIEIQZKFRUWCID5N3ITWANFLDANCNFSM6AAAAAAQWBFTHM
.
You are receiving this because you authored the thread.Message ID:
@.***>

yeah, initially I wasn't sure how to do that (since I wouldn't want to override say an int with a string), but I have an idea now.
…
On Tue, Sep 27, 2022 at 12:46 PM Nicole Keeney @.> wrote: I wasn't able to figure out how to create those attributes from the timeseries tool notebook, so I created a dummy dataset with the same attributes. But, the download didn't work :( I've attached my testing notebook as a zip file here for you to look over. I also think it would make more sense to look for attributes by type, not by name. As in, the function looks for attributes that are booleans, and converts to string, regardless of their name. Versus, looking for an attribute named "timeseries", and then redefining it as a string. PR84_review.ipynb.zip https://github.com/cal-adapt/climakitae/files/9659129/PR84_review.ipynb.zip I've now seen where this is in the timeseries tool notebook. This PR works, and solves this issue. But regardless, I think it should check by attribute type, not by attribute name. — Reply to this email directly, view it on GitHub <#84 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AWLSEIEIQZKFRUWCID5N3ITWANFLDANCNFSM6AAAAAAQWBFTHM . You are receiving this because you authored the thread.Message ID: @.>

Could you not do something like this? :
# Convert any non-string attr to a string
for attr in da.attrs:
    if type(da.attrs[attr] != str):
        da.attrs[attr] = str(da.attrs[attr])

yeah, initially I wasn't sure how to do that (since I wouldn't want to override say an int with a string), but I have an idea now.
…
On Tue, Sep 27, 2022 at 12:46 PM Nicole Keeney @.> wrote: I wasn't able to figure out how to create those attributes from the timeseries tool notebook, so I created a dummy dataset with the same attributes. But, the download didn't work :( I've attached my testing notebook as a zip file here for you to look over. I also think it would make more sense to look for attributes by type, not by name. As in, the function looks for attributes that are booleans, and converts to string, regardless of their name. Versus, looking for an attribute named "timeseries", and then redefining it as a string. PR84_review.ipynb.zip https://github.com/cal-adapt/climakitae/files/9659129/PR84_review.ipynb.zip I've now seen where this is in the timeseries tool notebook. This PR works, and solves this issue. But regardless, I think it should check by attribute type, not by attribute name. — Reply to this email directly, view it on GitHub <#84 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AWLSEIEIQZKFRUWCID5N3ITWANFLDANCNFSM6AAAAAAQWBFTHM . You are receiving this because you authored the thread.Message ID<EMAIL_ADDRESS>
Could you not do something like this? :
# Convert any non-string attr to a string
for attr in da.attrs:
    if type(da.attrs[attr] in [datetime.datetime, bool]):
        da.attrs[attr] = str(da.attrs[attr])

Here's a (zipped) Jupyter notebook with a full code snippit for a more complete example: PR_84_suggestions.ipynb.zip

it's quite a bit more complicated than your code, unfortunately.
for one, the attribute isn't type datetime.datetime; it's a tuple which contains datetimes.
two, it's not in a pretty format like you had it, it looks like datetime.datetime(2012, 12, 31, 0, 0).
I can convert that to a string, but it will be ugly. it's strangely difficult to iterate through the tuple in a flexible way and reformat it.


Processing done to Power atlas

I am trying to incorporate some of the atlases from this package into XCP-D, by Dr. Fair's request. However, I'm a little confused about the Power atlas, which should have 264 ROIs, but only has 77 in this file. The documentation I was pointed to indicates that this should have all 264 spheres. Was there some processing done to the Power atlas that resulted in fewer ROIs? Also, does anyone know what the radius for the ROIs was set to?

@tsalo Apologies - I am just seeing this issue now. Did you get an answer to this question through other means?

Issue solved in a different way


Are you aware of SPIRV-LLVM-Translator?

Hello. I'm very excited with this project. Hope it goes well. Have you considered using SPIR-V LLVM translator instead of writing your own rustc codegen backend from scratch? https://github.com/KhronosGroup/SPIRV-LLVM-Translator
P. S. I didn't test it personally, possibly it's immature and unstable yet. Anyway, IMHO it would be easier to use existing code instead of writing from scratch.
P. P. S. Or maybe your goal is to avoid depending on LLVM/C++/C at all?

SPIRV-LLVM-Translator is explicitly targeting the use case of kernel-mode spir-v, not shaders. The primary goals of this project are to enable shaders to be written in rust, and so SPIRV-LLVM-Translator does not fit our needs. As far as I can tell (and from my own experience trying to support both), there is an enormous amount of work to be done in SPIRV-LLVM-Translator to get shaders to work and I don't expect it to be done any time soon. (To be honest, in my opinion, kernel mode spir-v and shader mode probably should have been separate specs - they are significantly different)

Thank you for the explanation. To be clear, I'm not familiar with neither kernel-mode nor shader SPIR-V. I'll investigate this topic later in my spare time.
P. S. Is there any way to donate for the project?
10 ноября 2020 г. 10:34:12 GMT+03:00, Ashley Hauck<EMAIL_ADDRESS>пишет:

SPIRV-LLVM-Translator is explicitly targeting the use case of
kernel-mode spir-v, not shaders. The primary goals of this project are
to enable shaders to be written in rust, and so SPIRV-LLVM-Translator
does not fit our needs. As far as I can tell (and from my own
experience trying to support both), there is an enormous amount of work
to be done in SPIRV-LLVM-Translator to get shaders to work and I don't
expect it to be done any time soon. (To be honest, in my opinion,
kernel mode spir-v and shader mode probably should have been separate
specs - they are significantly different)

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

P. S. Is there any way to donate for the project?

Thanks for the offer! But no that is not needed. We (Embark) are a corporation and have the funding we need to drive this project.

Thanks for the pointer! It certainly would be nice to not duplicate work, but yeah, we unfortunately need to.


Move inventory cursor only once an item have been successfuly processed

@mlefebvre @infherny
With this, the cursor is never move forward until this message (and all previous messages have been processed)
Reminder that processed -> message executed, outputs published and all the hook ran.

lgtm


How to generate doc with gb?

@gobwas do you mean "how can I run godoc on the source of a gb project" ?


Unable to Get Order Id with Async Market Orders

It would be nice if async market orders return the order id before triggering an order event.
Expected Behavior
Market orders would take 10ms to fill.
Actual Behavior
Market orders taking 0ms to fill
Potential Solution

Reproducing the Problem
#region imports
from AlgorithmImports import *
#endregion
import copy
class TrailingStopLoss(QCAlgorithm):
def Initialize(self):
    self.SetStartDate(2022, 11, 1)
    self.SetEndDate(2022, 11, 1)
    self.SetCash(100000)
    self.equity = self.AddEquity("QQQ", Resolution.Second)
    self.symbol = self.equity.Symbol
    self.Consolidate(self.symbol, timedelta(minutes=1), self.minConsolidator)

    # ignore fees for now
    self.equity.SetFeeModel(ConstantFeeModel(0))

    #self.Schedule.On(self.DateRules.EveryDay(self.symbol),
    #    self.TimeRules.Every(timedelta(seconds=1)),
    #    self.closePosition)

    self.trade_count = 0
    self.Count = 0
    self.con_count = 0
    self.last_order = 'None'
    self.ticket = None

# NOTE: consolidator event is called BEFORE the onData in case they both need to
# be called
# a TraderBar object is passed in
def minConsolidator(self, bar):
    if self.trade_count < 3:
        # buy
        self.ticket = self.MarketOrder(self.symbol, 100, True)
        self.Debug(f"{self.Time}: BUY: {bar.Price}, orderId: {self.ticket.OrderId}")
        self.last_order = 'Buy'
        self.trade_count += 1

def OnData(self, data):
    return

    if self.symbol not in data:
        return

    if not data.Bars.ContainsKey(self.symbol):
        return

    # close a previous order if there is one
    if self.Portfolio[self.symbol].Invested:
        if self.Time.second > 58:
            self.Debug(f"{self.Time}: close QQQ,{self.Securities[self.symbol].BidPrice}, {self.Securities[self.symbol].AskPrice}")
            self.Liquidate(self.symbol)
    return

def OnOrderEvent(self, orderEvent):
    if self.ticket is not None:
        self.Debug(f"{self.Time}: OnOrder: ticket.orderId: {self.ticket.OrderId}, event.orderId: {orderEvent.OrderId}, status: {orderEvent.Status}")
    else:
        self.Debug(f"{self.Time}: OnOrder: self.ticket is None, event.orderId: {orderEvent.OrderId}, status: {orderEvent.Status}")

LOGS
2022-11-01 09:31:00: OnOrder: self.ticket is None, event.orderId: 1, status: 1
2022-11-01 09:31:00: OnOrder: self.ticket is None, event.orderId: 1, status: 3
2022-11-01 09:31:00: BUY: 281.69, orderId: 1
2022-11-01 09:32:00: OnOrder: ticket.orderId: 1, event.orderId: 2, status: 1
2022-11-01 09:32:00: OnOrder: ticket.orderId: 1, event.orderId: 2, status: 3
2022-11-01 09:32:00: BUY: 281.28, orderId: 2
2022-11-01 09:33:00: OnOrder: ticket.orderId: 2, event.orderId: 3, status: 1
2022-11-01 09:33:00: OnOrder: ticket.orderId: 2, event.orderId: 3, status: 3
2022-11-01 09:33:00: BUY: 281.6, orderId: 3
Checklist

[x] I have completely filled out this template
[x] I have confirmed that this issue exists on the current master branch
[x] I have confirmed that this is not a duplicate issue by searching issues

I have encountered the same problem with limit orders in paper trading (not so much during backtesting). The ticket should at least be returned before a Filled order status enters OnOrderEvent for that ticket. In my opinion, the ticket should be available before any event for that ticket is fired in OnOrderEvent (including New, Submitted, Invalid etc).

Add OrderTicket Ticket { get; set; } to the order event to be set by the BrokerageTransactionHandler when handling order events, this way the user/algorithm does not need to worry about matching order event to ticket


Modular Content Widget

- Summary
The motivation for this pull request is so the CMS can support a front matter property containing a list of modular content or blocks to construct a custom page output.
- Test plan
Add "modular" as widget type in config.yml. This content type accepts a "types" list instead of "fields". Functionality is similar to a list widget with its valueType set to valueTypes.SINGLE. Added the functionality of a dropdown control at the top of the list which chooses the content type to be added to the modular content list. Because it is a variation of the List widget, it retains the ability to re-order child widgets via drag and drop.

Modular content configuration

Modular content widget
- Description for the changelog
Added modular Widget for saving modular content lists to frontmatter.

fixes #1066

Deploy preview for netlify-cms-www ready!
Built with commit 20c1ac5afa7c18eef7efaa57b25e341817bb441e
https://deploy-preview-1169--netlify-cms-www.netlify.com

Deploy preview for cms-demo ready!
Built with commit 20c1ac5afa7c18eef7efaa57b25e341817bb441e
https://deploy-preview-1169--cms-demo.netlify.com

@erquhart l will have a look tonight or tomorrow morning, for sure.

@erquhart What's the use case for your suggestion? Other widgets wrap the List widget for list functionality as well, and introducing this as a feature of the list widget, instead of a wrapper around it, seems kinda weird architecturally.

@Benaiah I think maybe because it is a bit of code duplication? My widget is pretty close to the list widget and can probably be merged pretty easily.

@erquhart I had a crack at this this morning. I think I've merged all the functionality in the appropriate places. Updated including moving documentation to the list component.

@Benaiah what widget wraps the List widget? The PR as it was duplicated the entire list widget's code - I'm not sure how it could have imported the List widget and wrapped it to achieve this functionality.
The list widget already does 90% of this PR's goal - it just needs to allow more than one object definition to select from, versus always adding the one single object definition.
Architecturally, sharing list logic between widgets makes sense, but that can be a future abstraction. From a product standpoint, having the List widget be a bit more robust seems better than having two separate widgets.

Hmm I am noticing one thing that I hadn't before - this isn't just selecting groups of fields, it also allows you to select a single field by name. The difference there is non-trivial.

@erquhart I think this is why I decided against merging it into the List widget in the first place. Nevertheless it was a lot of code duplication so I think your reasoning had merit as well. In any case I merged into the list component and have all the functionality back as of the latest commit to the PR.

@anthonysapp to help simplify the review, could you do the following?

Re-add dist the .gitignore and remove that directory from the PR
Remove any changes that only affect code style
Remove the hardcoded previewing of specific widgets in the preview component

Let me know if you have questions on that last one.

@erquhart Not sure I have any changes that only apply to code style? And yeah a pointer on that last one would help for sure. Thanks!

Ooh, I am very much looking forward to this. I'm pretty sure I'll be able to use it to use Netlify CMS to edit the config.yml file, specifically to make it possible to add new collections via UI.

Cool, we'll have to get some eyes on that preview component and consider an alternate approach.
There are still some points from my review that need to be addressed - if you look at the file changes, there are a number of comments still showing. Let me know if you have questions on any of them. Mostly code style changes still remaining, but also .gitignore should have no changes in this PR (currently dist is still being added), and the dist` files that were added to the PR should be removed.

@erquhart  I had fixed the .gitignore and removed the dist files before the last commit, so not sure why you were still seeing those. Apologies - I think I got to all the code style issues now.

Rebased and removed a few more code style changes.

I'm testing this widget out, and I found what I would consider to be a pretty serious issue.
tl;dr
Problem
The widget passes the full "type" config through to the Front Matter. When re-loading the widget from a file, it uses the fields config from the Front Matter to setup the widget, rather than looking up the appropriate config from the original config.yml definition.
Solution
Rendering the widget to Front Matter should pass along the actual field value, along with the "name" of the widget type the data represents. This field "name" should be sufficient to find the corresponding type from the original field list, from which the fields can be loaded.
Additional widget option
Allow customization of the "key" under which the widget type is saved. Right now, it saves it as name, but it would be nice to be able to consider a different property in the Front Matter to hold the "type" of the config, such as type or kind, being left to an option in the list field config
Full description
Given the following config.yml:
...
collections:
  - name: "kitchenSink"
    label: "Kitchen Sink"
    folder: "_sink"
    create: true
    fields:
      - label: "Modular Content Chunks"
        label_singular: "Modular Content Chunk"
        name: "components_modular"
        widget: "list"
        types:
          - {label: "Readme", name: "readme", widget: "string"}
          - label: "Component Type One"
            name: "c1"
            widget: "object"
            fields:
              - {label: "Title", name: "title", widget: "string"}
      - label: "Non-modular list"
        label_singular: "Non-modular list"
        name: "components_list"
        widget: "list"
        fields:
          - {label: "Readme", name: "readme", widget: "string"}
      - {label: "Title", name: "title", widget: "string"}
      - {label: "Body", name: "body", widget: "markdown"}

Using the widget produces the following Front Matter entry and CMS display:
components_modular:
  - label: Readme
    name: readme
    readme: Readme Value
    widget: string
  - c1:
      title: Component Type One Value
    fields:
      - label: Title
        name: title
        widget: string
    label: Component Type One
    name: c1
    widget: object
components_list:
  - readme: Readme Value

The data I need is there in the front matter, but it's mixed in with a bunch of stuff that should stay in the config.yml. In fact, the widget seems to read data for the type's fields based on the Front Matter config, not config.yml, and as such, trimming the Front Matter data to what I would expect it to be, breaks the widget:
components_modular:
  - name: readme
    readme: Readme Value
  - name: c1
    c1:
      title: Component Type One Value
components_list:
  - readme: Readme Value

Another usability suggestion while I'm thinking of it. The normal list widget allows items of either a single field widget or multiple, and it would be nice for the same type of functionality to be available from each of the type widgets.
Right now each item acts as the single field type, where the item type is the field type, which also means that the field value is at a key that is always the same as the type itself. It might make more sense to have the list of types be configurations of "widget types", each with a "field" or "fields" property just as the non-modular list has in its root config.
In this way, we could almost consider the normal list widget to just be a special case of the modular list widget when there is only one type available, where it doesn't require a "name" property on the field value to be set.

Been meaning to follow up on this - great review @cjbrooks12, we definitely only want the value being output, didn't notice the config was being passed.
I do think that simply using the name for the key should suffice, at least for the first iteration, and the built in dropdown already allows the type to be selected per item. Am I misunderstanding what you meant on that?

My thought with the name being configurable is that you could make the widget understand both the following snippets, so the widget can be adapted to whatever terminology the developer prefers or SSG requires.
components_modular:
  - name: readme
    readme: Readme Value
  - name: c1
    c1:
      title: Component Type One Value

components_modular:
  - type: readme
    readme: Readme Value
  - type: c1
    c1:
      title: Component Type One Value

The change from "name" to "type" would be controlled from the config.yml widget config like so:
collections:
  - name: "kitchenSink"
    label: "Kitchen Sink"
    folder: "_sink"
    create: true
    fields:
      - label: "Modular Content Chunks"
        label_singular: "Modular Content Chunk"
        name: "components_modular"
        widget: "list"
        typeKey: 'type' # defaults to 'name'
        types: ...

Oh duh we need a way to map values back to types on read 🤦♂
I'm with you now, agreed.

Can't wait for this!

Hey @anthonysapp just checking in - still planning to circle back on the issues raised in the latest comments?

Hey all this is some great discussion. So sorry to have been unresponsive. I'm quite busy at the moment on another project but I would indeed like to loop back to this in the next week or so, as I'd love to use it for an upcoming project myself :).
If anyone else feels the urge to help out, by all means.

Awesome work on this @anthonysapp - I need this exact feature right now. I've sort of managed to recreate it using registerEditorComponent but its not the best user experience and it also means might front end is a little heavier as I need to transform my Markdown AST to React on the client.
This PR/feature would completely solve my problem. I really hope this makes it in soon.

@erquhart @cjbrooks12 hi guys, I took a look at this last night and I'm just curious if you both think this should still be merged with the List widget, or you think it warrants its own widget with the proposed changes? Also - I'm not 100% sure I understand this comment. What is inherently wrong with using the "name" field to reference each component? I know I'm probably missing something easy :)

Technically-speaking, I would see the List widget as a special case of the Modular widget where there is only one available type. I think there is still a case for keeping the Modular widget separate for clarity of intent.
As for the practical reason for wanting to customize the field used as the key, it is simply that the consumers of these modular blocks may consume them differently than Netlify CMS does.
For example, I'm build a SSG with this kind of modularity baked into the framework itself, and Orchid reads these blocks from the type field, not name. See here for an example: the components top-level field is the modular container, and each list item is a modular block identified by its type. Orchid wouldn't be able to understand the output of this widget if it only worked with name.
Or take Forestry's Blocks, which uses template to identify the type of the modular item. If someone were to migrate to Netlify CMS from Forestry, wouldn't it be easier to tell the Netlify widget to look for the template parameter rather than finding and changing all instances of template with name and hoping you got it all right?
As far as making it happen in the code, it shouldn't be much of a change. Rather than doing
item.name

to get the modular type, it would just be one step back with a configuration value to get it instead:
// config.typeKey defaults to 'name' but is configurable by the end-user
item[config.typeKey]

@cjbrooks12 I think I'm following now. Thanks for the feedback!

Just thought I'd say that this is an extremely exciting widget and would really elevate the possibilities (custom layouts on a per page basis).
Looking forward to seeing it shipped.

FYI - I'm monitoring the status of this modular content widget as it is all I'm waiting for to jump into Netlify CMS.

Closing as stale - if someone wants to pick it up, please comment.

it would be great if we could use a group of other collections in place of types. This way, existing blocks are re-usable.
DjangoCMS and EPiServer calls these blocks.
And if you have a collection of blocks that are actually layout types with further modular widgets in them, you can do awesome things.

What will it take to get this past the finish line? Are there particular features that still need to be implemented? or tests to pass?
I'm willing to help out, but I have zero React experience.

Hey, our team is currently exploring some ideas that are very similar on our own fork. We'll give an update when we feel more confident in our approach here.

As discussed in the netlifyCMS community meeting.

I was trying to say this that it can split the .json file (each object) into different card.

This sounds awesome. I have been unable to get this pull working at all with current version of netlifycms though.

This sounds like a must have widget when it comes to customizability and I'm wondering if there has been new updates on this?

No updates, still needs a sponsor.

For those watching this issue, a new implementation just popped up courtesy of @smnh in #1857 - we need some reviewing and testing, please check it out and make comments!


Changed 6th blog title on blog-sidebar-right.html

This has conflicts. Will close now & try again next time.  Make your commits longer so you avoid this.
Combine 3-4 sentences all in 1 commit together.


KAFKA-3590: KafkaConsumer fails with "Messages are rejected since there are fewer in-sync replicas than required." when polling

This just improves the error message since it's confusing that a consumer throws a message you'd normally see for a producer.

@hachikuji is this what you had in mind on KAFKA-3766?

@cotedm I was hoping that we could convert the errors on the broker side. From a high level, my thought was that we need not necessarily expose the fact that group metadata is stored in a topic in the protocol since it is an implementation detail. We have code in GroupMetadataManager to convert produce errors to something nicer for the group protocol. See here: https://github.com/apache/kafka/blob/trunk/core/src/main/scala/kafka/coordinator/GroupMetadataManager.scala#L209.
By the way, as I was looking over the same code, I noticed that the same error seems possible for OffsetCommit requests as well, so maybe we also need to convert those errors here: https://github.com/apache/kafka/blob/trunk/core/src/main/scala/kafka/coordinator/GroupMetadataManager.scala#L307.
Also, should we go ahead and resolve KAFKA-3766 as a duplicate?

@hachikuji ah, I misunderstood what you meant.  I'll try to update this PR with that since I agree it's better to do this on the server side altogether.  Also agree that we need to write to __consumer_offsets for OffsetCommit so it needs to be handled there as well.
I think KAFKA-3766 can be resolved as a duplicate.  I don't have permission to change the status though, it's all you :)

Closing this because @hachikuji is going to work on this one from here


Upgrade bigtable version for googlebigtable tests.

@sduskis Sorry for the delay on reviewing this. Looks like the failure was a bad Cassandra run. I kicked off the travis ci job again.
There are quite a few changes in this PR. Does the current bigtable binding work right now? Do v1 and v2 work at the same time?

@sduskis - Any plans to address the questions above? Also looks like this needs to be updated based on master changes.

The v1 and v2 APIs and protobuf objects are in different cloud-bigtable-client versions.  The v1 API will be removed at some point in the future, probably measured in months.  One alternative is to have separate maven projects for the v1 and v2 APIs.
For now I'll figure out how to change this into more manageable chunks starting with changes that can be applied to the v1 version.


Malicious application blocked

I just received a notification to update Powertoys to v0.18.0 and as soon as it finished my Bitdefender Free Antivirus warned me of the following:

Injection detected as Gen:Variant.Razy.639527 was performed by C:\Program Files\PowerToys\PowerToys.exe was blocked. Your device is safe.

Is this a false positive that I can easily exclude?

Can confirm that same happened to me, Bitdefender blocked it.
I'm waiting for answer before excluding it.

same here, anyone had an update on this?

It may be a false positive, but I'm not a Bitdefender expert and I don't know if it's saying that PowerToys.exe has been infected with Gen:Variant.Razy.639527 of if it says that PowerToys.exe is a malicious software itself.
Does Bitdefender have an option to submit the report to the company for further investigation?

Could you please check if the digital signature for PowerToys.exe is OK?

I sent a ticket to Bitdefender, I'll update when they reply.
Also, the digital signature says Microsoft Corporation.

Changed title to make it easier to find using search.

I scanned PowerToys.exe today with Bitdefender and it was all good now. 👍🏻


[WIP] First pass at mesh shader debugging for SPIR-V & Vulkan

I needed to debug a mesh shader and figured someone might want this
Enabled the "Debug This Vertex" dialog for vertices in the meshlet debug view and tied that into the spirv debugger.
This is kind of messy right now, and I also had to do some work to get buffer textures read properly. Makes me think I'm doing something wrong. I also just skipped any implementation for the SetMeshOutputsEXT op. No idea if that has consequences.
Also making some pretty loose assumptions about the group/thread dimensions to use when debugging the mesh shader which are totally wrong right now
Maybe with some feedback and a little elbow grease this could be useful?

Thanks for this PR, it definitely seems promising. I think the biggest challenge is similar to compute shader debugging but magnified - I would expect the large majority of mesh shaders to rely on cross-thread communication and work sharing (since that's part of the point of using mesh shaders as I understand it) which will fail under the current debugger model. It may still be useful though in the same way that compute shader debugging can be useful.
A couple of book-keeping things:

Can you please mark this as a normal PR? I personally find draft PRs on github pointless and I rather wish I could disable them on this repository as in my view they don't add any value at all and only cause confusion/annoyance.
As in the contributing docs please squash any formatting and compile fix changes into your commits as relevant, all commits should individually be correctly formatted and compile.

I'd also ask that you split out any fix to buffer view sampling into a separate PR as it doesn't seem mesh-shader related and can then be reviewed and merged potentially sooner as a bugfix. The VK_Shader_Debug_Zoo demo already does a test of sampling from a buffer view so it would be useful to modify/add to that test to see why that demo isn't covering whatever case needs your fixes - maybe the buffer format needs to be different?
I think from looking through this it mostly looks good but the main thing that would need to change is the thread selection that you mentioned. As you implied you can't assume that thread N outputs vertex N in a meshlet, the mapping is entirely user defined and not annotated with no realistic way to try and reverse engineer it. There may even be more or less threads than vertices.
I think instead what you should do is when debugging a meshlet pop up the compute shader thread-selection dialog and pre-populate the group with the calculated group ID, but set thread ID to 0,0,0. As a related note here you are currently assuming a 1D dispatch which out can't do, but since the order of outputs in the buffer is determined by us you can reverse the output index into a group ID using the dimensions.
As a related naming issue, the API function shouldn't be DebugMeshletVertex because it's not debugging a specific vertex, it's debugging a thread in the group that emitted a meshlet.

Thank you! This was exactly the feedback I was looking for. I'll try to find some time to chip away at this over the next week


Support on hover feature

Maybe we can support on hover feature, after hover in some words, we can show some helpful information from innosetup.

Making jrsoftware/issrc as a submodule, parsing the help text in it and generating the hover tip could be a way to it.

This is what i am doing now.

Closed as it's completed in v1.9.0


Add clientSuccess and serverSuccess to BQ schema

Add clientSuccess and serverSuccess to the big query performance tables' schema.

LGTM


Keep state at URL

Using vue router history the URL should reflect state of field ppn and dbkey so we can deep-link to examples.

Questions @nichtich:

Should the records automatically loaded if they are given via URL parameters?
If the answer to 1 is yes, does it also apply if it's the default PPN?

Currently, whenever the record is loaded (via "Laden" or choosing one of the example PPNs), the URL is adjusted, and if the site is loaded with the PPN given, it will be loaded automatically.

Yes to 1 and remove the Default PPN/recordText


SysWMEvent member 'msg' not accessible

Presently, there is no way to access a part of SysWMEvent, which is necessary for winapi menu bars.
https://github.com/veandco/go-sdl2/blob/1bad6977f9fe18e8c4a47dd0934015b7fb319ae6/sdl/events.go#L865-L871
Notice how msg is unexported.
This is what type msg points to in the SDL2 source:
https://github.com/veandco/go-sdl2/blob/1bad6977f9fe18e8c4a47dd0934015b7fb319ae6/.go-sdl2-libs/include/SDL2/SDL_syswm.h#L132-L186

Hi @kroppt! I don't have access to Windows machine right now but could you try to apply this patch and see if it works? You would be able to access via SysWMEvent.Msg.Windows().
https://transfer.sh/ImoDD/0001-sdl-syswm-add-way-to-access-internals-of-SysWMmsg.patch

$ go build
# github.com/veandco/go-sdl2/sdl
.\syswm_windows.go:10:7: could not determine kind of name for C.HWND
.\syswm_windows.go:13:9: could not determine kind of name for C.LPARAM
.\syswm_windows.go:11:6: could not determine kind of name for C.UINT
.\syswm_windows.go:12:9: could not determine kind of name for C.WPARAM

I hope I didn't do anything wrong!

If it helps:
HWND is HANDLE is void *, which I have been using as uintptr in go.
LPARAM is LONG_PTR is long (32-bit) or int64 (64-bit), which should be int in go.
UINT is unsigned int, which is uint32 in go.
WPARAM is UINT_PTR is unsigned int (32-bit) or unsigned int64 (64-bit), which I guess would be a int in go.
It's really just the sizes that matter I suppose.
Alternatively, you can C include WinDef.h.
Source: https://docs.microsoft.com/en-us/windows/desktop/WinProg/windows-data-types

@kroppt Okay, Let me try the header file approach! Could you try this patch?
https://transfer.sh/ImoDD/0001-sdl-syswm-add-way-to-access-internals-of-SysWMmsg.patch

That patch was the same, but adding the include was trivial.
I successfully tested it and got the expected result upon menu bar interaction. Thank you.
Side note, this looks clumsy.
if evt.Msg.Windows().Msg == 0x0111 {
	fmt.Printf("%v\n", evt.Msg.Windows())
}

@kroppt Oops, sorry about that! Do you mean the API is not user-friendly?

Yes, that is what I meant.

@kroppt Ahh okay. Do you think it would have been better if SysWMmsg contained the members of WindowsMsg directly?

The more I think about it, the more sense it makes to leave it how it is. It looks odd, but this is mainly a quirk of the Windows version of the SDL API, because it has a member called msg. For example, in C this would look like:
msg = evt.syswm.msg->msg.win.msg

I'm not sure which way would be best here, but I would try to make it consistent with other parts of the API, even if that means the Windows version looks quirky. The way you did it in the patch seems to be similar to how SysWMInfo is implemented.

Alright then. I'll push it to the test branch and then master branch some time today. I'll keep the API and perhaps revisit this in the future!

I have merged the changes into the master branch. Let me know if it still works for you 😃

Yes, it worked using latest. Thank you.


Mode button cleanup

It seems like either the settings screen should be merged into the slide-in popup screen (auto vs manual, channel vs hz, add band scan vs tuner and "settings!") or make the slide in menu as immediate as possible on mode press so it isn't quite so fussy about timing.  On the other hand I'm using it as a base station and not in goggles, so I'm less concerned about inadvertent button presses while I'm blindly groping for the toggle in the module bay.
(I see a (disused?) #define for that already (BUTTON_WAIT_FOR_MENU), so this might be on your development radar.)

Yes, I had a think about this. Putting everything in the side menu (including switching modes, etc) might make for a neat UI, though it's difficult to fit anything in other than icons (and maybe a slug of text).
I made the menu reachable by a hold rather than single press because I wanted to free up single press for other uses (e.g., selecting things in the menu itself, other things in future like favourites, etc), but I do admit it's a little awkward.


Unable to log in to Dev Panel.

Describe the problem and steps to reproduce it:
(Please include as many details as possible.)
Trying to log in here - https://addons.thunderbird.net/eN-US/seamonkey/addon/metal-lion-sea-monkey/ just produces endless loading here -
https://accounts.firefox.com/authorization?action=signin&scope=profile&state=54416515bab71121c6d5aee1ac0d93387f6a50a086151f1541c448c6cab3b327%3AL2VOLVVTL3NlYW1vbmtleS9hZGRvbi9tZXRhbC1saW9uLXNlYS1tb25rZXkv&redirect_url=https%3A%2F%2Faddons.thunderbird.net%2Fapi%2Fv3%2Faccounts%2Fauthenticate%2F&client_id=25691f3bf98f8ea8
What happened?
Endless loading
What did you expect to happen?
To be able to see a log in screen, at the least.
Anything else we should know?
(Please include a link to the page, screenshots and any relevant files.)

I can't reproduce this, so it must be an issue related to your specific account. Have you changed your Firefox Account email recently? Can you sign in on accounts.firefox.com? On AMO?

Hi, no, nothing has changed on my account and the endless loading is happening with both SeaMonkey and M$ Edge browsers.
I then realised - this is a Mozilla related website - so I used a VPN to the USA and a Chrome UA and was then instantly able to log in.


macOS TouchBar Button Mismatch?

OS: macOS Big Sur 11.4
VSCode version:  1.57.0
Extension version: v1.6.4
Compiler: G++ for CPP

When I tap the debug button on the right on Touchbar (shown below), the program only runs, all breakpoints are not working, and debug information (vars,watch,call stacks, etc.) is not displayed. But when I tap the Run button on the left, all the above debug functions become available.

I find it a bit strange because the functions of the two buttons seem to be reversed. When using other debuggers such as cppdbg or for other languages such as python, the functions of the buttons correspond properly. So I'm wondering if this is a problem with this extension.
launch.json:
{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "(lldb) Launch",
            "type": "lldb",
            "request": "launch",
            "preLaunchTask": "make test",
            "program": "${workspaceFolder}/test.out",
            "args": [],
            "stopOnEntry": false,
            "cwd": "${workspaceFolder}",
        }
    ]
}

Thanks for any help!

Sorry, I've not idea.   I don't alter anything about VSCode command mappings for this extension.   Sounds like you have "Start Debugging" and "Run Without Debugging" swapped.

Hi @vadimcn Thanks for your quick response! I have tried and was able to reproduce this issue on another mac with M1 chip (tried intel architecture before), but I don't have any ideas about how this can happen either. Where should be the place to report this issue?

Hold on, I just reproduced this problem in a Python workspace??! I now feel it may be related to the latest VS Code update 🤔


Port mav_planning_rviz plugins to ROS 2 Humble

Follow-up to https://github.com/ethz-asl/terrain-navigation/pull/20. This updates the mav_planning_rviz plugins for ROS 2.
This version builds and runs, however there are currently display issues to resolve and a test environment running on a ROS 2 supported version of PX4 or ArduPilot is required (either using mavros for ROS 2 or preferably with DDS integration).
Dependencies

https://github.com/ethz-asl/terrain-navigation/pull/20

Follow-up to #20. This updates the mav_planning_rviz plugins for ROS 2.
This version builds and runs, however there are currently display issues to resolve and a test environment running on a ROS 2 supported version of PX4 or ArduPilot is required (either using mavros for ROS 2 or preferably with DDS integration).
Dependencies

Port terrain-navigation to ROS 2 Humble #20

Do you need me to test on mide side to see if the display issues are MacOS specific?

Do you need me to test on mide side to see if the display issues are MacOS specific?

No, the display issues are now resolved. It’s a case of chasing down the service calls from each button to make sure they are running correctly with the correct inputs.
The most recent updates are in this branch: https://github.com/srmainwaring/terrain-navigation/tree/wips/wip-ap-dds-launch


Operator pod is in Terminating State during upgrade from 1.0.0 -> 1.1.0

Describe the bug
Operator pod is in Terminating State during upgrade from 1.0.0 -> 1.1.0
To Reproduce
Steps to reproduce the behavior:

installed operator & driver with CSI driver 1.0.0 successfully

[root@oc-w3 ~]# oc get pods -o wide
NAME                                               READY   STATUS    RESTARTS   AGE    IP             NODE                            NOMINATED NODE   READINESS GATES
ibm-spectrum-scale-csi-767nt                       2/2     Running   0          35s    <IP_ADDRESS>   oc-w5.ocp.openshift.scale.net   <none>           <none>
ibm-spectrum-scale-csi-attacher-0                  1/1     Running   0          37s    <IP_ADDRESS>    oc-w3.ocp.openshift.scale.net   <none>           <none>
ibm-spectrum-scale-csi-operator-5f8846dfbf-qdrtq   2/2     Running   0          3m1s   <IP_ADDRESS>    oc-w4.ocp.openshift.scale.net   <none>           <none>
ibm-spectrum-scale-csi-provisioner-0               1/1     Running   0          36s    <IP_ADDRESS>    oc-w4.ocp.openshift.scale.net   <none>           <none>
ibm-spectrum-scale-csi-w7kds                       2/2     Running   0          35s    <IP_ADDRESS>   oc-w4.ocp.openshift.scale.net   <none>           <none>
ibm-spectrum-scale-csi-xkm4w                       2/2     Running   0          35s    <IP_ADDRESS>   oc-w3.ocp.openshift.scale.net   <none>           <none>

[root@oc-w3 ~]# oc get pod ibm-spectrum-scale-csi-767nt -o yaml |grep image
    image: quay.io/k8scsi/csi-node-driver-registrar:v1.0.1
    imagePullPolicy: IfNotPresent
    image: quay.io/ibm-spectrum-scale/ibm-spectrum-scale-csi-driver:v1.0.0
    imagePullPolicy: IfNotPresent
  imagePullSecrets:
    image: quay.io/k8scsi/csi-node-driver-registrar:v1.0.1
    imageID: quay.io/k8scsi/csi-node-driver-registrar@sha256:5ad51d40e6de6762ae9bf2acbcf7117d46c87bc50048a337ce5a5cd6697498b4
    image: quay.io/ibm-spectrum-scale/ibm-spectrum-scale-csi-driver:v1.0.0
    imageID: quay.io/ibm-spectrum-scale/ibm-spectrum-scale-csi-driver@sha256:d1966fc94c9854765212adc35a930f7087e84e0935c74ab6182b5cd1e9188816

Upgraded the operator to 1.1.0

[root@oc-w3 ~]# oc apply -f ibm-spectrum-scale-csi-operator110.yaml
deployment.apps/ibm-spectrum-scale-csi-operator configured
clusterrole.rbac.authorization.k8s.io/ibm-spectrum-scale-csi-operator configured
clusterrolebinding.rbac.authorization.k8s.io/ibm-spectrum-scale-csi-operator configured
serviceaccount/ibm-spectrum-scale-csi-operator configured
customresourcedefinition.apiextensions.k8s.io/csiscaleoperators.csi.ibm.com configured

Previous Operator pod is in Terminating state
[root@oc-w3 tools]# oc get pods
NAME                                               READY   STATUS        RESTARTS   AGE
ibm-spectrum-scale-csi-767nt                       2/2     Running       0          43m
ibm-spectrum-scale-csi-attacher-0                  1/1     Running       0          43m
ibm-spectrum-scale-csi-operator-5f8846dfbf-qdrtq   0/2     Terminating   0          46m
ibm-spectrum-scale-csi-operator-85f9d768db-w96k8   2/2     Running       0          21m
ibm-spectrum-scale-csi-provisioner-0               1/1     Running       0          43m
ibm-spectrum-scale-csi-w7kds                       2/2     Running       0          43m
ibm-spectrum-scale-csi-xkm4w                       2/2     Running       0          43m

Expected behavior
Operator pod should not be in Terminating State during upgrade from 1.0.0 -> 1.1.0
Environment
Please run the following an paste your output here:
Deployment
[root@oc-w3 ~]# oc get nodes
NAME                            STATUS   ROLES    AGE    VERSION
oc-m1.ocp.openshift.scale.net   Ready    master   169d   v1.16.2
oc-m2.ocp.openshift.scale.net   Ready    master   169d   v1.16.2
oc-m3.ocp.openshift.scale.net   Ready    master   169d   v1.16.2
oc-w1.ocp.openshift.scale.net   Ready    worker   169d   v1.16.2
oc-w3.ocp.openshift.scale.net   Ready    worker   169d   v1.16.2
oc-w4.ocp.openshift.scale.net   Ready    worker   169d   v1.16.2
oc-w5.ocp.openshift.scale.net   Ready    worker   169d   v1.16.2

[root@oc-w3 ~]# operator-sdk version
operator-sdk version: v0.10.0, commit: ff80b17737a6a0aade663e4827e8af3ab5a21170

[root@oc-w3 ~]# oc get clusterversion
NAME      VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.3.8     True        False         3d3h    Cluster version is 4.3.8
[root@oc-w3 ~]#

[root@oc-w3 ~]# rpm -qa | grep gpfs
gpfs.callhome-ecc-client-5.0.4-1.noarch
gpfs.compression-5.0.4-1.x86_64
gpfs.gskit-8.0.50-86.x86_64
gpfs.crypto-5.0.4-1.x86_64
gpfs.librdkafka-5.0.4-1.x86_64
gpfs.gpl-5.0.4-1.noarch
gpfs.kafka-5.0.4-1.x86_64
gpfs.adv-5.0.4-1.x86_64
gpfs.base-5.0.4-1.x86_64
gpfs.java-5.0.4-1.x86_64
gpfs.gss.pmcollector-5.0.4-1.el7.x86_64
gpfs.gss.pmsensors-5.0.4-1.el7.x86_64
gpfs.docs-5.0.4-1.noarch
gpfs.msg.en_US-5.0.4-1.noarch
gpfs.license.dm-5.0.4-1.x86_64

Screenshots
If applicable, add screenshots to help explain your problem.
Additional context
Add any other context about the problem here.

Here is what /var/log/messages says about the terminating state operator pod

Apr  6 18:40:35 oc-w4 hyperkube: I0406 18:40:35.482252    2310 kubelet_pods.go:922] Pod "ibm-spectrum-scale-csi-operator-5f8846dfbf-qdrtq_ibm-spectrum-scale-csi-driver(6efe2102-26ae-4c01-9101-f891741b1f09)" is terminated, but some volumes have not been cleaned up
Apr  6 18:40:45 oc-w4 hyperkube: I0406 18:40:45.480858    2310 kubelet_pods.go:922] Pod "ibm-spectrum-scale-csi-operator-5f8846dfbf-qdrtq_ibm-spectrum-scale-csi-driver(6efe2102-26ae-4c01-9101-f891741b1f09)" is terminated, but some volumes have not been cleaned up
Apr  6 18:40:55 oc-w4 hyperkube: I0406 18:40:55.480977    2310 kubelet_pods.go:922] Pod "ibm-spectrum-scale-csi-operator-5f8846dfbf-qdrtq_ibm-spectrum-scale-csi-driver(6efe2102-26ae-4c01-9101-f891741b1f09)" is terminated, but some volumes have not been cleaned up
Apr  6 18:41:05 oc-w4 hyperkube: I0406 18:41:05.480011    2310 kubelet_pods.go:922] Pod "ibm-spectrum-scale-csi-operator-5f8846dfbf-qdrtq_ibm-spectrum-scale-csi-driver(6efe2102-26ae-4c01-9101-f891741b1f09)" is terminated, but some volumes have not been cleaned up
Apr  6 18:41:15 oc-w4 hyperkube: I0406 18:41:15.480278    2310 kubelet_pods.go:922] Pod "ibm-spectrum-scale-csi-operator-5f8846dfbf-qdrtq_ibm-spectrum-scale-csi-driver(6efe2102-26ae-4c01-9101-f891741b1f09)" is terminated, but some volumes have not been cleaned up
Apr  6 18:41:25 oc-w4 hyperkube: I0406 18:41:25.480789    2310 kubelet_pods.go:922] Pod "ibm-spectrum-scale-csi-operator-5f8846dfbf-qdrtq_ibm-spectrum-scale-csi-driver(6efe2102-26ae-4c01-9101-f891741b1f09)" is terminated, but some volumes have not been cleaned up
Apr  6 18:41:35 oc-w4 hyperkube: I0406 18:41:35.480974    2310 kubelet_pods.go:922] Pod "ibm-spectrum-scale-csi-operator-5f8846dfbf-qdrtq_ibm-spectrum-scale-csi-driver(6efe2102-26ae-4c01-9101-f891741b1f09)" is terminated, but some volumes have not been cleaned up
Apr  6 18:41:45 oc-w4 hyperkube: I0406 18:41:45.480846    2310 kubelet_pods.go:922] Pod "ibm-spectrum-scale-csi-operator-5f8846dfbf-qdrtq_ibm-spectrum-scale-csi-driver(6efe2102-26ae-4c01-9101-f891741b1f09)" is terminated, but some volumes have not been cleaned up
Apr  6 18:41:55 oc-w4 hyperkube: I0406 18:41:55.480893    2310 kubelet_pods.go:922] Pod "ibm-spectrum-scale-csi-operator-5f8846dfbf-qdrtq_ibm-spectrum-scale-csi-driver(6efe2102-26ae-4c01-9101-f891741b1f09)" is terminated, but some volumes have not been cleaned up
Apr  6 18:42:05 oc-w4 hyperkube: I0406 18:42:05.481089    2310 kubelet_pods.go:922] Pod "ibm-spectrum-scale-csi-operator-5f8846dfbf-qdrtq_ibm-spectrum-scale-csi-driver(6efe2102-26ae-4c01-9101-f891741b1f09)" is terminated, but some volumes have not been cleaned up
Apr  6 18:42:15 oc-w4 hyperkube: I0406 18:42:15.480398    2310 kubelet_pods.go:922] Pod "ibm-spectrum-scale-csi-operator-5f8846dfbf-qdrtq_ibm-spectrum-scale-csi-driver(6efe2102-26ae-4c01-9101-f891741b1f09)" is terminated, but some volumes have not been cleaned up
Apr  6 18:42:25 oc-w4 hyperkube: I0406 18:42:25.482297    2310 kubelet_pods.go:922] Pod "ibm-spectrum-scale-csi-operator-5f8846dfbf-qdrtq_ibm-spectrum-scale-csi-driver(6efe2102-26ae-4c01-9101-f891741b1f09)" is terminated, but some volumes have not been cleaned up
Apr  6 18:42:35 oc-w4 hyperkube: I0406 18:42:35.482027    2310 kubelet_pods.go:922] Pod "ibm-spectrum-scale-csi-operator-5f8846dfbf-qdrtq_ibm-spectrum-scale-csi-driver(6efe2102-26ae-4c01-9101-f891741b1f09)" is terminated, but some volumes have not been cleaned up

Expected behavior
Operator pod should not be in Terminating State during upgrade from 1.0.0 -> 1.1.0

This is actually incorrect because the operator uses a deployment, the operator pod will always be terminated in the upgrade path. Here's an example of the deployment rollout process.
Now staying in the terminating state is a bigger problem:
Looks like something  bad happened in the Replicaset:
     State:          Terminated
       Reason:       Error
       Exit Code:    137
       Started:      Mon, 06 Apr 2020 17:14:45 +0530
       Finished:     Mon, 06 Apr 2020 17:40:25 +0530
     Ready:          False

Error 137 is  an OOM error, which is holding up the delete of the operator. There's  no pressure,  however,  so that's unlikely.

This  error appears to be the source of the hang:
Apr  6 18:42:35 oc-w4 hyperkube: I0406 18:42:35.482027    2310 kubelet_pods.go:922] Pod "ibm-spectrum-scale-csi-operator-5f8846dfbf-qdrtq_ibm-spectrum-scale-csi-driver(6efe2102-26ae-4c01-9101-f891741b1f09)" is terminated, but some volumes have not been cleaned up

Based on this issue, it might be that  you're stuck on I/O for an unmount.

This mount in the pod is likely the source of the hang:
Volumes:
   runner:
    Type:       EmptyDir (a temporary directory that shares a pod's lifetime)
    Medium:
    SizeLimit:  <unset>```

I  don't think this  should have a probability of medium either, because I've run this  upgrade a number of times  and have never seen this, nor have I seen this on  other user's clusters before this issue.

@Jainbrt  has this been replicated recently?

@mew2057 I have not hit this again. So closing for now


Token lease not being respected

Artifactory version: 7.33.12
Vault Version: 1.12.2
Artifactory Plugin version: 0.2.0
I have set the Artifactory vault plugin following the instructions here https://www.jfrog.com/confluence/display/JFROG/Hashicorp+Vault+Artifactory+Secrets+Plugin
However when I request a token with a 1h lease even though the plugin returns the lease is for 1h it is valid of 1 YEAR in Artifactory.
❯ vault write artifactory/roles/ci \
∙ username="<redacted>" \
∙ scope="applied-permissions/groups:<redacted>" \
∙ default_ttl=1h max_ttl=3h
Success! Data written to: artifactory/roles/ci

Token has a lease_duration of 1h
❯ vault read artifactory/token/ci
Key                Value
---                -----
lease_id           artifactory/token/ci/xpFDZ5qdWmnaHUP49BLZl2ag
lease_duration     1h
lease_renewable    true
access_token       ey<redacted>
role               ci
scope              applied-permissions/groups:<redacted>
token_id           b79872ec-b8fc-4f1e-b7e0-53443e2aa578

But in Artifactory the token lives for a year
{
    "token_id" : "b79872ec-b8fc-4f1e-b7e0-53443e2aa578",
    "subject" : "jfac@01e7hr4k76vr470nkn64m81n3n/users/<redacted>",
    "expiry" :<PHONE_NUMBER>,
    "issued_at" :<PHONE_NUMBER>,
    "issuer" : "jfac@01e7hr4k76vr470nkn64m81n3n",
    "refreshable" : false
  }

It looks like the lease is explicitly set to never expire which I guess means the token takes the access default (in my case the default of 1year).
https://github.com/jfrog/artifactory-secrets-plugin/blob/master/artifactory.go#L89
I waited over 1 hour to check if Vault would revoke the token, but 90 minutes later and the token is still valid.

The way it is supposed to work is that Vault will "expire" that token at the end of the lease. The fact that you also posted about an error revoking the admin token during rotation makes me wonder whether there is an error in the "RevokeToken" function.
It does also seem like the "max_ttl" should be enforced by setting that as the artifactory access token expiration, by default, but it does not do that, perhaps related to artifactory "issues" -- https://github.com/jfrog/artifactory-secrets-plugin/blob/v0.2.0/artifactory.go#L80-L89

@TJM Thanks for bringing this to my attention. I'll take a quick look.
cc @mritunjaykumar

Thanks for looking into this.
Revoked tokens that still work is IMO a rather large security issue, especially with API keys going away soon. Leavers would be able to access the system until their access token expired, same with any accidentally leaked tokens.....
It also rather invalidates the point of this Vault plugin somewhat if tokens that Vault revokes live on till the Expiry.
Let me know if I can help in any way.

vault read af_new/token/ci
Key                Value
---                -----
lease_id           af_new/token/ci/W7qfY4<SNIP>cTQ0in30
lease_duration     1h
lease_renewable    true
access_token       eyJ2Z<SNIP>cA
role               ci
scope              applied-permissions/groups:<SNIP>
token_id           411e0119-6aca-4bef-b498-cfc27296725d

In Artifactory token id 411e0119-6aca-4bef-b498-cfc27296725d shows up in the non-revocable tokens list with an expiry of 1 year which I guess is why Vault cannot revoke it after the 1h lease_duration.
I guess there is a bug in Artifactory that is not respecting the passing of values.Set("expires_in", "0") as a never expires token (same in the UI as mentioned in my other issue).

@apr-1985 From my (albeit very quick) testing in 7.49.3, setting the expires_in field to 0 in the POST /access/api/v1/tokens request works to create a non-expiring token. There's no expires_in field when GET /access/api/v1/tokens and I am able to revoke by DELETE /access/api/v1/tokens/{id}.
When I create a token with expires_in set to a non-zero value (say 900 = 15 min), I was not able to revoke it which is correct behavior.
{
    "code": "BAD_REQUEST",
    "message": "Token not revocable",
    "detail": "Token not revocable. Token expirationTimeMillis:<PHONE_NUMBER>098, issuedAtMillis:<PHONE_NUMBER>098, revocableExpiryThresholdMillis: 21600000"
}

Thanks @alexhung
It sounds like all my issues here are from being on an "older" version of Artifactory and recent changes to tokens should have fixed them.
I will try and get a demo licence next week and test.

FWIW, I tested this using the same version of Vault and Artifactory, but was unable to reproduce. I set the lease time to 5m so I didn't have to wait quite as long, but as soon as the lease expired, I saw this in the logs:
2023-01-06T15:57:04.686-0700 [INFO]  expiration: revoked lease: lease_id=artifactory/token/jenkins/TJGyjp5rHPs5zVY1gvQ2UjyF

... then immediately attempted to use it:
$ curl -H "Authorization: Bearer $JENKINS_TOKEN" -H "Content-type: application/json" http://<IP_ADDRESS>:8082/access/api/v1/cert/root
{
  "errors" : [ {
    "code" : "UNAUTHORIZED",
    "message" : "Bearer authentication failed, invalid token"
  } ]
}

So, I think the problem is that for some reason tokens are not being properly revoked on your system. I don't think this is a problem with the plugin itself. It may be the initial admin token does not have the ability to revoke tokens by ID or it may be that there is something else. I think once we solve the error on rotation in #23 this one will resolve itself. The "revoke" (DELETE) token command is the same for the end of a lease and rotating an admin token.


Productionise Withdrawals Engine API Changes

Full implementation of https://github.com/ethereum/execution-apis/blob/main/src/engine/shanghai.md
The WIP is rather large and hard to review: https://github.com/hyperledger/besu/pull/4552
Ideally this should be split into PRs to get this into main behind the shanghaiTimestamp fork.
~Therefore this story is blocked on the shanghaiTimestamp PR.~
Note, this is strongly related to https://github.com/hyperledger/besu/issues/4777 and it might make sense to do unit tests and refactor per PR split.
One suggested split is:

~EVM logic  - WithdrawalsProcessor~ Covered by #4878
Supporting new withdrawals and withdrawalsRoot fields in domain layer, most wiring.
API EngineForkchoiceUpdatedV2, EngineNewPayloadV2, EngineGetPayloadV2, etc

There is also a small piece of validation to add for engine_newPayloadV2 (null/non-null withdrawals when pre/post-shanghai)

Covered by other stories

Closed the wrong issue


my monthly grocery expense data analysis

initial commit
sourced the data from mysql database

No conflict with the base branch. Okay to merge.


Won’t start on macOS

Getting to the webpage and it says “Error while starting PimpMyStremio

Same here

Same here, but it starts in the menu bar anyway and pressing Open in Browser opens settings.

Same here


Impossible to unarchive a study

Description
When I try to unarchive a study I get this error :

Additional Information
ID study on recette : 3a636969-d8b1-4383-9b4a-ca3d01adba84

I downloaded the zip and it's a bit weird, it contains no information on area at in thermal/clusters nor in thermal/prepro but it does in thermal/series :thinking: . @makdeuneuv who did report this bug to you ?

No body reports this issue for the moment. It's related to this PR #1871


Add category.product_count

More information: https://github.com/DivanteLtd/vue-storefront/issues/2577

Resolve with https://github.com/DivanteLtd/magento2-vsbridge-indexer/pull/37
Changes are available in develop branch.


Feature: Add/Fix HMR support.

This Pull Request will add/fix the HMR feature and also fixes some bugs.
The npm start command ran vite build --watch and  neu run concurrently. But when doing so neu won't find the index.html file found in the build folder since it is being built by vite(Note that they are running concurrently so when a command is waiting for something the other executes). This could be fixed by vite build --watch or npm run dev:vite and neu run or npm run dev:neu on a separate terminal but still hot reload won't work. since the app is rebuilt by vite everytime there is a change.
I fixed the issues mentioned above by using the neutralino's HMR capabilities mentioned in the docs which enables neutralino to connect to the frontend libraries dev server with neutralinos. This is implemented by:

Configuring vite.config.js to use localhost:3000 when serving and making sure it is strict.
Configuring neutralino.config.json to connect with vite as mentioned in the  docs and using the port used by vite for the devUrl i.e http://localhost:3000
Changing the dev:vite script in package.json to serve the application insead of building it and watching it
Changing the start script in package.json to run the dev:vite and neu run --frontend-lib-dev concurrently to serve the application with vite and open neutralino from it.

Also fixed incorrect path set to the include property in the react-plugin in vite.config.js.
And the app works with full HMR support.
There is also another pull request in https://github.com/pegvin/Create-Neutralino-App/pull/2 to update the vite-react template in tempate-urls.js according to the changes made here.

Hi There, this is a copy pasted messaged.
i'll look into this PR soon.
~ Aditya

Ok no hurries

thanks for the contribution!


luaPackages.luarocks: generate luarocks as well

When installing a lua package that depends on luarocks, luarocks was not capable of recognizing the luarocks module: https://github.com/NixOS/nixpkgs/issues/316009 .
As explained here https://github.com/luarocks/luarocks/issues/1659, luarocks needs a manifest to recognize the package. I first attempted to generate a manifest with luarocks-admin make-manifest on our current manual luarocks derivation but this ended up being too hackish as the make-manifest requires a .rockspec or .rock to work, which we had not.
It seemed simpled to just rename the current manual luarocks derivation to luarocks_bootstrap in order to break cyclic dependencies in buildLuarocksPackage and add a generated luarocks derivation. Previously it was impossible to test luarocks because of the cyclic dependency but we will now be able to test the generated derivation.
Description of changes

Things done

Built on platform(s)

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

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

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

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Result of nixpkgs-review pr 316221 run on x86_64-linux 1

1 package marked as broken and skipped:

lua54Packages.sqlite

1 package failed to build:

vimPlugins.haskell-tools-nvim

85 packages built:

lua51Packages.argparse
lua51Packages.cyan
lua51Packages.fzy
lua51Packages.haskell-tools-nvim
lua51Packages.luacheck
lua51Packages.luarocks
lua51Packages.luarocks-nix
lua51Packages.luarocksCheckHook
lua51Packages.luarocks_bootstrap
lua51Packages.moonscript
lua51Packages.rocks-config-nvim
lua51Packages.rocks-dev-nvim
lua51Packages.rocks-git-nvim
lua51Packages.rocks-nvim
lua51Packages.sqlite
lua51Packages.teal-language-server
lua51Packages.tl
lua52Packages.argparse
lua52Packages.cyan
lua52Packages.fzy
lua52Packages.luacheck
lua52Packages.luarocks
lua52Packages.luarocks-nix
lua52Packages.luarocksCheckHook
lua52Packages.luarocks_bootstrap
lua52Packages.moonscript
lua52Packages.rocks-config-nvim
lua52Packages.rocks-dev-nvim
lua52Packages.rocks-git-nvim
lua52Packages.rocks-nvim
lua52Packages.sqlite
lua52Packages.teal-language-server
lua52Packages.tl
lua53Packages.argparse
lua53Packages.cyan
lua53Packages.fzy
lua53Packages.luacheck
lua53Packages.luarocks
lua53Packages.luarocks-nix
lua53Packages.luarocksCheckHook
lua53Packages.luarocks_bootstrap
lua53Packages.moonscript
lua53Packages.rocks-config-nvim
lua53Packages.rocks-dev-nvim
lua53Packages.rocks-git-nvim
lua53Packages.rocks-nvim
lua53Packages.sqlite
lua53Packages.teal-language-server
lua53Packages.tl
lua54Packages.argparse
lua54Packages.cyan
lua54Packages.fzy
lua54Packages.luacheck
lua54Packages.luarocks
lua54Packages.luarocks-nix
lua54Packages.luarocksCheckHook
lua54Packages.luarocks_bootstrap
lua54Packages.moonscript
lua54Packages.rocks-config-nvim
lua54Packages.rocks-dev-nvim
lua54Packages.rocks-git-nvim
lua54Packages.rocks-nvim
lua54Packages.teal-language-server
lua54Packages.tl
luajitPackages.argparse
luajitPackages.cyan
luajitPackages.fzy
luajitPackages.haskell-tools-nvim
luajitPackages.luacheck
luajitPackages.luarocks
luajitPackages.luarocks-nix
luajitPackages.luarocksCheckHook
luajitPackages.luarocks_bootstrap
luajitPackages.moonscript
luajitPackages.rocks-config-nvim
luajitPackages.rocks-dev-nvim
luajitPackages.rocks-git-nvim
luajitPackages.rocks-nvim
luajitPackages.sqlite
luajitPackages.teal-language-server
luajitPackages.tl
luarocks-packages-updater
mpvScripts.mpv-webm
nelua
vimPlugins.nvim-teal-maker

🤔 I wonder why haskell-tools is failing? I presume it's the test suite?
Does it fail on master too?

Hm interesting, apparently not…

I remembered it failed during a test, maybe because of the background builds going on. I've just run nix-build -A vimPlugins.haskell-tools-nvim on this branch and it passed. Merging then


Need more context about the delivery process

As of now in Freshbey one can order items using COD and UPI. In both methods, the manual invention is needed to update the status. In delivery status, there is only one of the two messages "Delivered" or "Not delivered" which are shown to the user.
Here's the order page.

The plan is to give more context about the delivery like where the product is right now when it will get to reach the customer something like that.
Imagine Freshbey has one or more stores in every city. It need not be a store. It can also be a warehouse. So once we get the location from the user, we'll map the nearest store or warehouse to deliver the products to the customer. Accordingly, the details will be shown to the customer as I stated above.
Come up with a solution to address this problem. I am going to team up with you to work on this feature.

One approach i can think of is to use socket-IO to update order notifications pushing them from server to the client as sockets allow bidirectional communication. we can also use geolocation API in JavaScript to get the current location of the customer as latitude and longitude and use any geocoding service to get the client address. To implement nearest distance search we need to save the coordinates of the warehouses or stores in the database. I am willing to contribute on this or any other idea.


Zh/ramaplot

Added ramachandran plotting function

Added read phi-psi from silent file

Closes #12

Pull Request Test Coverage Report for Build 37

0 of 0 (NaN%) changed or added relevant lines in 0 files are covered.
223 unchanged lines in 6 files lost coverage.
Overall coverage decreased (-1.8%) to 69.752%

Files with Coverage Reduction
New Missed Lines
%

.tox/py36/lib/python3.6/site-packages/rstoolbox/utils/tools.py
12
22.22%

.tox/py36/lib/python3.6/site-packages/rstoolbox/components/description.py
15
86.07%

.tox/py36/lib/python3.6/site-packages/rstoolbox/utils/getters.py
31
64.71%

.tox/py36/lib/python3.6/site-packages/rstoolbox/components/rsbase.py
36
53.77%

.tox/py36/lib/python3.6/site-packages/rstoolbox/plot/structure.py
56
29.11%

.tox/py36/lib/python3.6/site-packages/rstoolbox/io/rosetta.py
73
61.93%

Totals

Change from base Build 36:
-1.8%

Covered Lines:
2057

Relevant Lines:
2949

💛  - Coveralls


Issue with Job in Laravel 10x

When I updated the laravel framework to 10x, the application is totally broken. Meaning instead of returning what it did before, it now just returning Illuminate\Foundation\Bus\PendingDispatch. Is there any plan to make this okay in future or not?

duplicate of #46

Feel free to use my fork https://github.com/ksimenic/lucid. It has all optimizations for Laravel 10.
All you need to do is to add following in your composer.json
    "repositories": [
        {
            "type": "vcs",
            "url": "https://github.com/ksimenic/lucid"
        }
    ],

and then require
"lucidarch/lucid": "dev-latest"


How can I reduce the App.framework file size ?

Details
I am generating the App.framework file using below command. However the ipa size increase in the native app when the Flutter gets integrated to it is around 18 MB. Is there a way I can minimise it ?
flutter build iOS-framework --split-debug-info --cocoapods

Target Platform:
iOS
Target OS version/browser:
Devices:
Physical device
Logs

[✓] Flutter (Channel stable, v1.17.3, on Mac OS X 10.15.4 19E287, locale en-IN)
• Flutter version 1.17.3 at /Users/murtuzasaify/Desktop/flutterSDK/flutter
• Framework revision b041144f83 (3 months ago), 2020-06-04 09:26:11 -0700
• Engine revision ee76268252
• Dart version 2.8.4
[✗] Android toolchain - develop for Android devices
✗ Unable to locate Android SDK.
Install Android Studio from: https://developer.android.com/studio/index.html
On first launch it will assist you in installing the Android SDK components.
(or visit https://flutter.dev/docs/get-started/install/macos#android-setup for detailed instructions).
If the Android SDK has been installed to a custom location, set ANDROID_SDK_ROOT to that location.
You may also want to add it to your PATH environment variable.
[✓] Xcode - develop for iOS and macOS (Xcode 11.5)
• Xcode at /Applications/Xcode.app/Contents/Developer
• Xcode 11.5, Build version 11E608c
• CocoaPods version 1.8.4
[!] Android Studio (not installed)
• Android Studio not found; download from https://developer.android.com/studio/index.html
(or visit https://flutter.dev/docs/get-started/install/macos#android-setup for detailed instructions).
[✓] VS Code (version 1.48.1)
• VS Code at /Applications/Visual Studio Code.app/Contents
• Flutter extension version 3.13.2
[!] Connected device
! No devices available
! Doctor found issues in 3 categories.

The IPA size may not accurately reflect the app size when a user downloads it: https://flutter.dev/docs/perf/app-size#ios. That web page also listed some things you can do to make your app smaller.
BTW, this seems to be more of a question instead of a bug/issue report or feature request. If so, maybe we shall close it, and ask the question either in https://stackoverflow.com/tags/flutter or discord?

Hi @murtuzasaify
This issue doesn't seem to describe a bug or a feature request. Please see https://flutter.dev/community for resources and asking questions like this, you may also get some help if you post it on Stack Overflow and if you need help with your code, please see https://www.reddit.com/r/flutterhelp/
Closing, as this isn't an issue with Flutter itself. If you disagree, please write in the comments and I will reopen it.
Thank you


Update to latest bgfx

Hey,
I'm doing another sync for visionOS work, especially to bring in the fix:

https://github.com/BabylonJS/bgfx/commit/3f3d3b443348eda809fc2b30857e208e7dddec88
https://github.com/BabylonJS/bgfx/commit/0b73e8c7e22a2876a8979a4dd9b77d0686058090

Were you able to test this in Babylon React Native as well?
Which platforms have you tested with these changes in both BN and BRN (e.g. Windows, iOS, Android)?

Hey @ryantrem,
I didn't check it in Babylon React Native (yet). I'm going to try integrating my visionOS PR to Babylon React Native next week so I'm going to check other platforms too. I've tested visionOS and iOS. Could you test Windows and Android?
I don't have any Windows/Android devices (I can test Android on a simulator but Im not sure if it works).
Im running into some build issues on Windows on my PR, so it will probably need some additional work

I usually do a PR to check validation tests with BabylonNative. So, it needs a bgfx.cmake update and a BN PR.
If BN Validation tests are fine then BRN should be no problem.

Just checking, you haven't created a BN PR with this change to run it through validation tests yet, correct?

@ryantrem

@okwasniewski Just checking, you haven't created a BN PR with this change to run it through validation tests yet, correct?

I'm sorry I've been busy with other stuff, I will create syncing PR tomorrow

No worries, I just remembered this and wanted to make sure you weren't waiting on us!

The BN draft PR to test this is here, correct?
https://github.com/BabylonJS/BabylonNative/pull/1408