HTTP Response Occasionally Cut Off

Description
When we access the HTTP endpoint via a python script and the requests library, we occasionally see responses from the triton inference server which are too short for the requested amount of data.
Triton Information
What version of Triton are you using?
Version 19.10-py3, as this is the highest we can support on GKE
Are you using the Triton container or did you build it yourself?
Using the official NVIDIA behavior
To Reproduce
Steps to reproduce the behavior.

We are serving two ONNX models, each which take a single input FP32 tensor, and return a single output FP32 tensor.
Only happens in our production environment, which is on GPUs running in a Kubernetes cluster. Occasionally some responses from the TRT server appear to be too short, causing errors in our pipeline.
Retrying the same request fixes the error.

Expected behavior
We'd expect the full response is sent every time. We are using python3 and the requests library to make the requests manually. Here is our code to send requests to the TRT server:
https://gist.github.com/jakepoz/3b1cb0676b4eb7bd95ebfa23d3aa0e46

Is the amount of returned data consistent with Content-Length?

It's hard for me to check, what I noticed is that locally, I can run the model and give TRT ~4GB of ram, it uses 2.5GB and everything serves fine. In production, we have to allocate 30GB (via Kubernetes), and then it starts working.

FYI, using TRT to refer to Triton will confuse many people because TRT means TensorRT which is in the inference space but is not a server and completely different than Triton.
It seems like you are talking about both GPU and CPU memory, but I'm not sure. Are there more GPUs on your production nodes than what you test locally? By default triton will load 1 copy of the model onto each GPU.
I don't know any reason why triton would behave differently in k8s than locally assuming your are sending the same amount of traffic in each case. Memory allocation and usage will be a function of how many requests are in flight.

Closing due to inactivity. Reopen if there is new information.


[FEATURE] RepVGG-A0 and A1 support

Tkx for your great work, I found this repository not contain RepVGG-A0 and RepVGG-A1, could you add these models in this repository
reference link repvgg

Done when #1925 is merged


Can't install both Commands and SQLite into same project?

I've tried this several times now in VS2015:

File -> New -> Project
Templates -> Visual C# -> Unit Test Project  w/ .NET Framework 4.5.2
Install-Package EntityFramework.SQLite -Pre
----> SUCCESS
Install-Package EntityFramework.Commands -Pre

Attempting to gather dependency information for package 'EntityFramework.Commands.7.0.0-rc2-16649' with respect to project 'TestEF', targeting '.NETFramework,Version=v4.5.2'
Install-Package : An error occurred while retrieving package metadata for 'Microsoft.Data.Sqlite.1.0.0-rc2-20466' from source 'C:\Users\DHentschel\Documents\Visual Studio 2015\Projects\TestEF\packages'.
At line:1 char:1

Install-Package EntityFramework.Commands -Pre

  + CategoryInfo          : NotSpecified: (:) [Install-Package], Exception
  + FullyQualifiedErrorId : NuGetCmdletUnhandledException,NuGet.PackageManagement.PowerShellCmdlets.InstallPackageCommand

If I try to install Commands first, and then SQLite second, the behavior is similar. Commands succeeds, but SQLite fails. Am I doing something wrong? I thought this worked the last time I tried, a few months ago.

danBhentschel

Do you have the latest version (3.4.3) of NuGet installed?

I had 3.4.0. I just installed 3.4.3, and retried. Same behavior as before.

Nevermind. I think I got it. I had AspNetVNext (https://www.myget.org/F/aspnetvnext/api/v2/) setup as a package source. Don't remember when or why I did that. When I removed that source, installation succeeds.
Perhaps the devs might still want to look into this??? But it's no longer an issue for me. I can move forward.

danBhentschel

You were mixing rc1 and rc2 packages then, and that will not work.

Thanks.


scipy.signal.fftconvolve along speficied axis — cannot you add it?

Gentlemen! I want to filter multidimensional signal with 1D convolutional filter using scipy.signal.fftconvolve (along specified axis).

Maybe fftconvolve could grow an axes=None argument. It uses fftn/ifftn under the hood, which support that argument.

I hope on that with breath bated.
^__^

PR welcome if you want this to happen soon.

Would there be any interest in adding a 'warp' or 'cyclic' mode to fftconvolve, that didn't do all the extra padding to avoid the kernel wrapping around? Cyclic convolution does have it uses...

'wrap', not 'warp'...

Well, just now in our project we use fftconvolve with 'full' mode. But I think that cyclic convolution may be also useful for other users.

@Felix-neko, simply adding the axis parameter to fftconvolve is a fairly simple change. Do you want to take the opportunity to become a scipy contributor?

See also #3525 for further discussion on this topic. It also includes a reference to an implementation of fftconvolve which supports axis.

isn't this an exact duplicate of https://github.com/scipy/scipy/issues/3525?


Is it a bug for getFeaturesAtPixel(pixel, opt_options)?

Describe the bug
Sometimes this function cannot get features where the features' style is at that pixel.
When I used this function to get features, I found that: If the 'Style' (like image and text) of a 'Feature' is within 100 pixels of the feature's coordinate, I can get the feature by using the pixels within the 'Style'; But If the 'Style' is too far (more than 100 pixels), I cannot get the 'Feature' by using the pixels of the 'Style'.
To Reproduce
Steps to reproduce the behavior:

let p = new Feature(new Point())
p.setStyle(new Style({text: new Text( { offsetX: 200 } )}))
then, if the point is at pixel-coordinate [0,0], using getFeaturesAtPixel( [200, 0] ) can get nothing.

Expected behavior
It should be able to get the features by clicking the features' style.

By default, OpenLayers only considers an area of 100 pixels around a feature for hit detection. When you use an offset of 200 pixels. you are outside of that region. To fix it, configure your layer with a renderBuffer with an appropriate size. In your case maybe renderBuffer: 250.

By default, OpenLayers only considers an area of 100 pixels around a feature for hit detection. When you use an offset of 200 pixels. you are outside of that region. To fix it, configure your layer with a renderBuffer with an appropriate size. In your case maybe renderBuffer: 250.

God, I didn't find it. My bad. Thanks so much!


Moving

Hi, thanks for your excellent work.
I'm trying to repeat your work (replicaCAD), but I cannot move the camera around, and the keys do not work. May I know the device and Linux version you used? Thanks.

Hi, can you give some more details of what you are running and what issue you are getting?

Hi Joe, Thanks for your reply.
I try to run iSDF on sequences with pose provided. I follow the readme instructions until the command python train_vis.py --config configs/replicaCAD.json. The window opens successfully but when I press the direction keys, the camera does not move. I wonder if my conda environment setup failed due to the device or Ubuntu version.

I'm not sure what behaviour you were expecting but nothing should happen when you press the directions keys in the open3d vis window. The camera that is capturing the input depth images moves according the a prerecorded sequence, you cannot move this camera with your keys. If you are talking about the viewpoint of the 3D reconstruction window, then you can change this perspective by dragging with your mouse.


feat: get pr number for workflow_run

Support event workflow_run triggered by PR workflow.
Upgrade to node 20

@xrkffgg Could you please release a new version for it?

ok

done


Invalid parsing of DM30 for single SPN in Part 1 only

This has been noted on all of our test runs with 3.1.0 and it seems to affect all engine model years.  This only occurs during part 1.  The SLOT failure message does not occur in any other instances where DM30 is requested for SPN 3521 after part 1.
3.0.13
11:56:03.5845 Sending DM7 for DM30 to Engine #1 (0) for SPN 3521
11:56:03.5875 18E300F9 [8] F7 C1 0D 1F FF FF FF FF (TX)
11:56:03.6015 18A4F900 [12] F7 C1 0D 12 00 01 00 FB FF FF FF FF
DM30 from 0: SPN 3521 FMI 18 (SLOT 256) Result: Test Not Complete.
3.1.0
09:55:30.5150 Sending DM7 for DM30 to Engine #1 (0) for SPN 3521
09:55:30.5190 18E300F9 [8] F7 C1 0D 1F FF FF FF FF (TX)
09:55:30.5290 1CA4F900 [12] F7 C1 0D 12 00 01 00 FB FF FF FF FF
DM30 from 0: SPN 3521 FMI 18 (SLOT 256) Result: Test Not Complete.
FAIL: <IP_ADDRESS>.a (A.7.1.c) - #-3521 SLOT identifier for SP 3521 FMI 18 from Engine #1 (0) is invalid

256 SAEpc08 Is in the A-7-3 list.

Investigation requested 7/8

https://github.com/Equipment-and-Tool-Institute/j1939-84/blob/5949042f5aedf7f509e962e8da559974d231ac6b/src/org/etools/j1939tools/j1939/J1939DaRepository.java#L56
https://github.com/Equipment-and-Tool-Institute/j1939-84/blob/5949042f5aedf7f509e962e8da559974d231ac6b/src/org/etools/j1939tools/j1939/J1939DaRepository.java#L60
https://github.com/Equipment-and-Tool-Institute/j1939-84/blob/3.1.4/src/org/etools/j1939tools/resources/bit-slots.csv
These may be the cause of the issue?  Pulling in bit-slots.csv seems new for the 3.1.X branch and the findSlot method has reordered its logic to check the slots map for a negative SPN first, which is defined in the bit-slots file.

Jacob, please confirm this as corrected.

This is still present on 3.1.7.
J1939-84 Tool version 3.1.7 - 2022/10/05 21:27
Generated: 2022/10/10 13:44:06.1648
12:37:55.0398 Sending DM7 for DM30 to Engine #1 (0) for SPN 3521
12:37:55.0418 18E300F9 [8] F7 C1 0D 1F FF FF FF FF (TX)
12:37:55.0508 1CA4F900 [12] F7 C1 0D 12 00 01 00 FB FF FF FF FF
DM30 from 0: SPN 3521 FMI 18 (SLOT 256) Result: Test Not Complete.
FAIL: <IP_ADDRESS>.a (A.7.1.c) - #-3521 SLOT identifier for SP 3521 FMI 18 from Engine #1 (0) is invalid

SPN 3521 has SLOT identifier of 89.  89 is not identified as a valid SLOT in A-7-3.
The error message needs to be cleaned up, but the SLOT is invalid, right?  This is the correct error, right?
FAIL: <IP_ADDRESS>.a (A.7.1.c) - #89 SLOT identifier for SP 3521 FMI 18 from Engine #1 (0) is invalid

12:37:55.0508 1CA4F900 [12] F7 C1 0D 12 00 01 00 FB FF FF FF FF
DM30 from 0: SPN 3521 FMI 18 (SLOT 256) Result: Test Not Complete.
The SLOT is in bytes 5-6.  It is 256 in this case, which was correctly identified by the tool.  There should be no fail message in this case.

I didn't realize that the SLOT was in the response.  We will quit using the SPN to lookup the SLOT in DM30 validation.

Looks fixed. From section 6.1.12 in v3.1.10:

10:19:35.8039 Sending DM7 for DM30 to Engine #1 (0) for SPN 3521
10:19:35.8060 18E300F9 [8] F7 C1 0D 1F FF FF FF FF (TX)
10:19:35.8157 1CA4F900 [12] F7 C1 0D 12 00 01 00 FB FF FF FF FF
DM30 from 0: SPN 3521 FMI 18 (SLOT 256) Result: Test Not Complete.
10:19:35.8184 Sending DM7 for DM30 to Engine #1 (0) for SPN 3936


Mid Epoch Resumption Draft

Description of changes:

Issue #, if available:

Merge Checklist:
Put an x without space in the boxes that apply. If you are unsure about any checklist, please don't hesitate to ask. We are here to help! This is simply a reminder of what we are going to look for before merging your pull request.
General

[ ] I have read the contributor guidelines
[ ] This is a documentation change or typo fix. If so, skip the rest of this checklist.
[ ] I certify that the changes I am introducing will be backward compatible, and I have discussed concerns about this, if any, with the MosaicML team.
[ ] I have updated any necessary documentation, including README and API docs (if appropriate).

Tests

[ ] I ran pre-commit on my change. (check out the pre-commit section of prerequisites)
[ ] I have added tests that prove my fix is effective or that my feature works (if appropriate).
[ ] I ran the tests locally to make sure it pass. (check out testing)
[ ] I have added unit and/or integration tests as appropriate to ensure backward compatibility of the changes.

Closing the PR as the actual implementation is in this PR: https://github.com/mosaicml/streaming/pull/37


'Can't open PhantomJS' error after upgrading PhantomJS from 1.9 to 2.0

I have been successfully running wraith with PhantomJS 1.9 but when I upgraded PhantomJS to 2.0 I get an error message...
Can't open ''C:/Ruby22-x64/lib/ruby/gems/2.2.0/gems/wraith-3.2.0/lib/wraith/javascript/phantom.js''
Nothing else has changed and if I switch back to 1.9 it starts working again.
Output...
D:\wraith>wraith history configs/alpha/individual_history.yaml
DEBUG: #################################################
DEBUG:   Command run:        history configs/alpha/individual_history.yaml
DEBUG:   Wraith version:     3.2.0
DEBUG:   Ruby version:       ruby 2.2.3p173 (2015-08-18 revision 51636) [x64-mingw32]

DEBUG:   ImageMagick:        Version: ImageMagick 6.9.2-7 Q16 x64 2015-11-28 http://www.imagemagick.org

DEBUG:   PhantomJS version:  2.1.1

DEBUG:   CasperJS version:   Couldn't find nor compute phantom.casperPath, exiting.

DEBUG: #################################################
DEBUG:
Config validated. No serious issues found.
Creating Folders
SAVING IMAGES
DEBUG: phantomjs --ignore-ssl-errors=true 'C:/Ruby22-x64/lib/ruby/gems/2.2.0/gems/wraith-3.2.0/lib/wraith/javascript/phantom.js' 'https://localhost/web/individual/31621/profile/connections?step=profile_connections_direct' '1024x2000' 'alpha/individual_history_shotsx/profile_connections_direct/1024x2000_phantomjs_alpha2.png' 'body' 'false' 'D:/wraith/javascript/individual.js'
Can't open ''C:/Ruby22-x64/lib/ruby/gems/2.2.0/gems/wraith-3.2.0/lib/wraith/javascript/phantom.js''
WARN: Failed to capture image alpha/individual_history_shotsx/profile_connections_direct/1024x2000_phantomjs_alpha2.png on attempt number 1 of 5
Can't open ''C:/Ruby22-x64/lib/ruby/gems/2.2.0/gems/wraith-3.2.0/lib/wraith/javascript/phantom.js''
WARN: Failed to capture image alpha/individual_history_shotsx/profile_connections_direct/1024x2000_phantomjs_alpha2.png on attempt number 2 of 5
Can't open ''C:/Ruby22-x64/lib/ruby/gems/2.2.0/gems/wraith-3.2.0/lib/wraith/javascript/phantom.js''
WARN: Failed to capture image alpha/individual_history_shotsx/profile_connections_direct/1024x2000_phantomjs_alpha2.png on attempt number 3 of 5
Can't open ''C:/Ruby22-x64/lib/ruby/gems/2.2.0/gems/wraith-3.2.0/lib/wraith/javascript/phantom.js''
WARN: Failed to capture image alpha/individual_history_shotsx/profile_connections_direct/1024x2000_phantomjs_alpha2.png on attempt number 4 of 5
Can't open ''C:/Ruby22-x64/lib/ruby/gems/2.2.0/gems/wraith-3.2.0/lib/wraith/javascript/phantom.js''
WARN: Failed to capture image alpha/individual_history_shotsx/profile_connections_direct/1024x2000_phantomjs_alpha2.png on attempt number 5 of 5
ERROR: Unable to capture image alpha/individual_history_shotsx/profile_connections_direct/1024x2000_phantomjs_alpha2.png after 5 attempt(s)
WARN: Using fallback image instead

Config...
phantomjs_options: "--ignore-ssl-errors=true"

verbose: true

browser: "phantomjs"

mode: diffs_first

# Type the name of the directory that shots will be stored in
directory: 'alpha/individual_history_shotsx'
history_dir: 'alpha/individual_history_shots_basex'

  # we've deliberately left out the snap_file

# Add only 2 domains, key will act as a label
domains:
  alpha2: "https://localhost/web"

#Type screen widths below, here are a couple of examples
screen_widths:
  - 1024x2000

#Type page URL paths below, here are a couple of examples
paths:
   profile_connections_direct:
     path: /individual/31621/profile/connections?step=profile_connections_direct
     before_capture: 'javascript/individual.js'

#Amount of fuzz ImageMagick will use
fuzz: '20%'

Thanks @SimonKeep, this looks similar to #441, it looks like PhantomJS 2+ doesn't like apostrophes in the command line.
This is a bug but I can't promise we'll be able to fix it anytime soon! Pull request fixes are welcome.

The cmd getting executed:
phantomjs  'C:/Ruby22-x64/lib/ruby/gems/2.2.0/gems/wraith-3.2.1/lib/wraith/javascript/phantom.js' 'http://www.google.com/' '1024' 'shots/home/1024_phantomjs_current.png' 'body' 'false' 'false'
If I executed this cmd from the console, it works just fine for both phantomjs v1.9.8 & v2.1.1
Did a quick fix which strips out the single quote from the cmd which works fine for both version.
PR: https://github.com/BBC-News/wraith/pull/479

Moving issue to #489.


Repo checking

This PR addresses https://github.com/binder-project/binder/issues/5, by adding repo content checking to the web app. The checking is server-side with authentication, using the Python client to GitHub's API. I've also added some simple repo validation on the front end for typos / formatting errors.
As our dependency specifications options are currently rather simple, the check is also rather simple (i.e. if you asked for requirements.txt, do you have requirements.txt). Users will get messages like:

One thing we're NOT doing is making sure that if your repo has a particular resource, you're requesting to use it. For example, if you ask to build with None but actually have a requirements.txt in your repo, that's "ok". Unless anyone feels we need that, I would err towards letting uses do what they want.

The change looks good to merge!


What of Angular2, Electron, NativeScript ?

What of Angular2, Electron, NativeScript ?

See http://caniuse.com/#search=angularjs:

AngularJS
This framework is not part of any web browser, so support is not listed here.

Afaik same with Angular2, Electron, NativeScript.
Also partial dup of #2743.
Imho only thing debatable is adding those to the 'not listed here'-list.

And vue too


Roam Import: Problems with double dot and slash

I encountered a problem when importing my Roam Graph that makes the import useless for me: I often use colons (:) and slashes (/) for page titles in Roam (mostly for book titles). The Obsidian importer cannot cope with this. All Roam pages that contain a slash or a colon become a folder (part of the page title before the colon or slash) and a page within it (part of the page title after the colon or slash). Obsidian-Importer should either import the page title correctly or replace the characters in the title.

any chance of this getting fixed? I've got the same problem and it makes importer from Roam basically useless for me.

Since it's related to OS-level restrictions (can't name a file with certain characters), it's unlikely that it can be changed, since it could break cross-platform compatibility. I'm in the process of moving my Roam vault over (7k+ notes) and will probably use the title property for the full-character titles.
I think Roam also namespaces slashes in titles, so it's likely that the displayed version of notes with slashes are handled differently. If you have an example, please share so I can check it out in my setup.
Choosing the replacement character would be helpful though, then it would be easier to update the affected files after the import is done. That's better than the alternative - replacing before the import.

I have the same issue: I often use forward slashes in my Roam page titles (e.g. for month/year like 05/2024 or for publications with two authors like Miller/Smith). As long as the Importer creates a folder plus a file from these pages, I don't see how I could migrate from Roam to Obsidian.
On the other hand, there are use cases where the current method of treating slashes makes sense: If someone uses prefixes (or namespaces) to distinguish between certain types of information (like Books/Moby Dick, Books/Robinson Crusoe, Movie/Oppenheimer), it would even be an advantage to have the pages stored under the respective folder.
Therefore I suggest to let the user choose:
( ) Use forward slashes to create folders.
( ) Replace forward slashes by the following character: ___

@martin8032 I submitted a PR with some changes, linked off of this (I had some similar thoughts to what you're talking about). One change is to have any illegal filename characters replaced with _:
Thread: https://github.com/obsidianmd/obsidian-importer/issues/236
PR: https://github.com/obsidianmd/obsidian-importer/pull/242
I've tested imports, and the slash-to-folder creation for notes works really well. I imported over 7k notes and they all dropped into their respective folders correctly. I also set up my Daily Notes as YYYY/YYYY-MM-DD and the import pulled them into year-named folders.
Still getting used to tags and notes being separate entities, but it'll be part of the processing I have to do along the way anyway.


Reuse WriteBatch in apply worker

Improvement
Apply worker will new a WriteBatch and fill it with updates, and will release it after these updates has been written to RocksDB. This cause many memory allocations and deallocations. Essentially, WriteBatch is a continuously memory buffer, each apply worker reuse the same WriteBatch is a better way.

seem we need to re-implement RocksDB API to not move WriteBatch, then we can reuse the batch.

@siddontang  No necessary, https://github.com/pingcap/rust-rocksdb/pull/283


Replaced "withinviewport" with our own "is-inviewport" library

Few of advantages of the new library:

Simpler than "withinviewport" - contains only what we need (~20 lines vs ~200 lines).
Packaged as ES6 module to get rid of Angular 10 warning.
Full control of the library in case we need to change anything.

Other features:

TS types
100% test code coverage

PS: might be a good idea to merge PR #225 before merging this one.

@isaacplmann if you see a need for it, I could even implement a binary flag config like the following:
isInviewport(htmlElement, ElementSides.Top | ElementSides.Right | ElementSides.Left);
isInviewport(htmlElement, ElementSides.Bottom | ElementSides.Left | ElementSides.Top);

@isaacplmann do I have to add npm link stuff to package.json for the library and do I need ng-package.json file with deleteDestPath set to false plus ng-package.prod.json without that config?

Ok, I'll open a new PR with the isInviewport() function in ngx-tour-core.


Issue with Bluetooth and UART0

We are using esp32 devkit for our experiments. While experimenting we have observed that if i turn the Bluetooth functionality(basically esp_bt_controller_init()), UART0 stops receiving data. Neither uart_rx_one_char() or uart_rx_one_char_block() functions work as expects. However the transmit functionality of UART0 is intact, we can see the messages sent by ESP32 SDK( messages sent using ESP_LOG() APIs ).
If i do not turn on Bluetooth functionality UART simply works fine.
While browsing online i read somewhere that BT RF is affecting the UART functionality (not able to find the thread now).
I am curious to know if this is known silicon issue with simultaneous functionality of UART0 and Bluetooth?
Thanks and Best Regards

RChavan

Interested in this.  Have you looked at what UART1 is doing in this same regard?  I'd love to know so I can have a workaround for one of my projects, if it does work right as opposed to how UART0 seems to be working for you.

Now I have configured UART1 of ESP32 and same issue is getting observed. UART transmit functionality of ESP32 is intact while reception hangs when BT turned ON. UART functionality is critical for our project and hence just wanted to confirm, if this is really an issue or if yes is there some workaround available?

Annoying.  I was about to work on something once I got a bit of a success in the code I was porting over that needed this ability as well.
Need to know if we've got a silicon or IDF bug here, guys- and be handed workarounds if it is.  I need UART support to bridge two ESP32's with BT/BLE running on them.

SPI might work, but it's clumsier for what I'm attempting.

What's the timeline for this?  I've got a few projects where this would be useful...  I know, I'm being a bit of a pest, but...  >;-D

@rajeshchavan88 , There's something unclear, do you want to use UART0 as HCI when bluetooth enable? or just user UART0 do another things when bluetooth enabled?

@rajeshchavan88 , Maybe the interrupt number of UART0 receive do something conflict with bluetooth's (Bluetooth use 1/5/8). Please check that.

Maybe the interrupt number of UART0 receive do something conflict with bluetooth's (Bluetooth use 1/5/8). Please check that.

I had a similar problem with BT+UART0 not working together and this was indeed the issue: both BT and UART0 use ISR number 5.  To fix it I used uart_isr_register to register the handler, rather than the low-level function xt_set_interrupt_handler.

@TianHao-Espressif  I want to use UART0 as simple UART and at the same time I want BT is also enabled.
@dpgeorge I will try out your solution and will check if it works for me. Thanks

Any news on if this works?  Basically can we use 2 UART ports (one for serial/log and one for comms), while BT is in use?

BT doesn't effect UART. rajeshchavan88's problem is interrupt number conflict with bt.

@rajeshchavan88 ,  sorry for disturbing you. So your problem is fixed?

Hello @TianHao-Espressif, as mentioned by @dpgeorge BT and UART  does use same interrupt number. after changing the interrupt number, both BT and UART are working fine. Thanks ! :)


[Bug]: The project administrator is unable to regress database changes made by the project initiator

ODC version
odc433
OB version

What happened?
Project initiator

Project Manager

What did you expect to happen?
Project administrators can roll back database change tasks initiated by project members
How can we reproduce it (as minimally and precisely as possible)?
After project members initiate tasks, project administrators view the tasks
Anything else we need to know?
No response

Fixed In Commit 46c4d29ce8cb1aad002f7cfd3316b72090abc643
------
艺泽
Mon Dec 30 14:23:26 2024 +0800

pass


Error when changing metadata and spl-token

When I enter this command  metaboss update uri -a 4VaU8pHkCmBcvycdd1tJdtzQpiP4FFsv1rMvUGZ9iUu5 -u https://gateway.pinata.cloud/ipfs/QmWVZtZMAroyEe1tWzPKrAnZBygyYMBn84RmugmoGZeZsf?_gl=1 -k HAY2.json
I am getting this  error Error: Action failed with error: failed to get account data
And I checked, the token account, etc. everything is fine.
And enough money for the commission

You're trying to update the metadata on a mint account that has no accompanying metadata account.

Can you please explain how to do it
I'm just learning 😁

Can you please explain how to do it I'm just learning 😁

I don't understand what you're trying to do. The mint account 4VaU8pHkCmBcvycdd1tJdtzQpiP4FFsv1rMvUGZ9iUu5 doesn't have any metadata associated with it so can't be updated. I think you used the wrong mint account or are confused about something. You can read more about Metaplex NFTs and tools here: https://docs.metaplex.com/.

ahh
Thank you
everything, now I understand everything
Thank you so much bro


How to create two related pie charts, one inside each other?

I need to create something like this:

Where both pie charts should be filtered if i filter one. Also the outside one should follow the inside group (as in the image).
Is this possible with the package?

One way is to use a Stack of Containers:
 return Stack(
      children: <Widget>[
        Container(
          transformAlignment: AlignmentDirectional.center,
          height: 300,
          width: 300,
          child: PieChart( ..
            PieChartData( sections:[
               PieChartSectionData(
                  radius: 50,
                  ..

        Container(
          transformAlignment: AlignmentDirectional.center,
          height: 300,
          width: 300,
          child: PieChart( ..
            PieChartData( sections:[
               PieChartSectionData(
                  radius: 100,
                  ..

  ..

If you align them in the center, each of your charts with a unique radius in its own Container at the same center origin.

Yes, I think the best solution is to use a Stack widget.
btw, I will keep it open to think about it later.
Maybe it would be better if we implemented it internally. I'm not sure!

Is there any chances that stack breaks during resize of the web navigator (i'm developing a flutter web project)

Also how can I "attach" the two charts behavior?

Interactions will not merge, unfortunately.
But there is no problem using Stack  in the web

Is it possible to trigger an interaction on the second chart after one on the first and vice versa?

Is it possible to trigger an interaction on the second chart after one on the first and vice versa?

Yes that should be fine, it depends where you keep your state. it works well with BloC implementation

@imaNNeo are there any chances of this being implemented as a default chart on the package?

@imaNNeo are there any chances of this being implemented as a default chart on the package?

Yes, we can do this. But unfortunately, I have limited time and I don't have enough funds to work full-time here.
So I do my best to implement it asap.
Also, contributions are welcome!


Create xmpp.svg

adding first draft, looks ok and in under 1023 :D

That's a great start, thanks! Please can you follow the template in https://github.com/edent/SuperTinyIcons/blob/master/CONTRIBUTING.md to make sure it is 512x512. Then we can merge it.

yeah, that's where it goes all wrong. buggered up your readme as well :/

jeez this i one way of learning github, how the hell do I refresh the file?

Haha! Yeah, GitHub is "fun". You should be able to push another commit to your branch. If that doesn't work, delete everything and start again :-)


npm install not working in powershell

Describe the bug
npm install returns error in poweshell
To Reproduce
'cp' is not recognized as an internal or external command,
operable program or batch file.
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR<EMAIL_ADDRESS>prepare: `rimraf dist/ && tsc -p ./ --outDir dist/ && cross-env mkdir -p dist/src/cli/commands/html/sc/ && cp -r src/cli/commands/html/sc/* dist/src/cli/commands/html/sc/ && npm run browser:build`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>prepare script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:

I can take care of this too. 👍

Sure @coding4funrocks it is time to do some housekeeping anyhow 😃 . The problem is that the build script is using the cp command which is not running cross platform.
we can use copyfiles package instead
npm install copyfiles --save-dev

after that  we should change the scripts to look like this:
 {
        "clean": "rimraf starterts/ && rimraf starterjs/ && rimraf dist/",
        "clean:dist": "rimraf dist/",
        "prepare": "npm run clean && npm run ts:build:dist && npm run copyfiles:dist && npm run browser:build",
        "copyfiles:dist": "copyfiles src/cli/commands/html/sc/* dist/src/cli/commands/html/sc/ --flat",
        "test": "npm run ts:build && mocha --colors --timeout=0",
        "test-dev": "npm run ts:build && cross-env NODE_TLS_REJECT_UNAUTHORIZED=0 mocha --reporter=list --timeout=0",
        "mocha-run": "mocha --colors --timeout=0",
        "test-jenkins": "npm run ts:build && cross-env JUNIT_REPORT_PATH=./report.xml mocha --colors --reporter mocha-jenkins-reporter --timeout=0",
        "ts:build": "tsc",
        "ts:build:dist": "tsc -p ./ --outDir dist/",
        "ts:watch": "tsc -w",
        "browser:build": "rollup -c",
        "lint": "tslint ./src/**.ts && tslint ./test/**/*.ts",
        "test:watch": "cross-env NODE_TLS_REJECT_UNAUTHORIZED=0 mocha --watch test/ --growl --reporter=spec --timeout=0",
        "start-dev": "cross-env NODE_TLS_REJECT_UNAUTHORIZED=0 cross-env concurrently --raw \"npm run ts:watch\" \"npm run test:watch\" ",
        "dev": "npm run ts:build && cross-env NODE_TLS_REJECT_UNAUTHORIZED=0 concurrently --raw \"npm run ts:watch\" \"npm run test:watch\" ",
        "start-agent-dev": "npm run ts:build && cross-env NODE_TLS_REJECT_UNAUTHORIZED=0 cross-env DEBUG=http,mindconnect-agent,mindconnect-fileencoder node ./src/demoagent/test-agent.js ",
        "doc": "compodoc -p tsconfig.json --output docs --name \"@mindconnect/mindconnect-nodejs\" --theme material && npm run copyfiles:doc",
        "copyfiles:doc": "copyfiles images/* docs/",
        "createkey": "openssl genrsa -out private.key 3072",
        "license": "license-checker --csv --onlyAllow \"Apache-2.0; Apache*; BSD; BSD-2-Clause; BSD-3-Clause; ISC; MIT; Unlicense; WTFPL; CC-BY-3.0; CC0-1.0\" --production",
        "license:summary": "license-checker --summary --onlyAllow \"Apache-2.0; Apache*; BSD; BSD-2-Clause; BSD-3-Clause; ISC; MIT; Unlicense; WTFPL; CC-BY-3.0; CC0-1.0\" --production"
    }

I also deleted some left-over docker build scripts from 2017 :)


Research if we can add eslint to this repo

ESLint is a static code analysis tool for identifying problematic patterns found in JavaScript code.
I would love to get some formatting / prettier running in the code base

Would like to take this up


snapTo going to wrong index

I am encountering a problem with the method snapTo() in version 1.0.0-alpha.19.
Indeed, I have a bottom sheet with 3 snap points (450, 300 and 0) and the initialSnap on the value 0;
<BottomSheet
  ref={this.bottomSheetRef}
  snapPoints = {[450, 300, 0]}
  renderContent = {this.renderContent}
  renderHeader = {this.renderHeader}
  initialSnap={2}
/>

Here are the steps I am doing:

I am first calling snapTo(1), so it should go to 300, but it always go to 450;
then I am calling snapTo(2), to close the bottom sheet, but it goes to 300;
then I am calling snapTo(1), but it goes to 0;
then I am calling snapTo(2), but it goes to 300;
then I am calling snapTo(1), but it goes to 0;
then I am calling snapTo(2), but it goes to 300;
etc...

It doesn't make any sense. snapTo(1) should be 300 and not 0, and  snapTo(2) should go to 0 and not 350.
Moreover, on the first call of snapTo(1), it goes to 450 and it should be 300.
It seems the indexes from snapPoints are totally mixed up.
I have created a snack so you can see the problem:
https://snack.expo.io/@alexandremaistret/bottomsheet-bug
In this snack, click on the red button in the top right. It will call snapTo(1) or snapTo(2) depending on the supposing bottomsheet state (opened or not). You can also check the logs "snapTo(2) called" and "snapTo(1) called" and you will see it does not make any sense. When snapTo(2) is called, "snapTo(2) called" is logged , but the bottomsheet goes to 300, and when snapTo(1) is called, "snapTo(1) called" is logged, but the bottomsheet goes to 0.

I am also having this issue, if I have three snap points e.g. snapPoints={400, 200, 100]}, to reference the second snapPoint "200" I have to give it the index 0: initialSnap={0}

I was having a problem with initialSnap.. removedenabledBottomInitialAnimation={true} and is now working properly


Login works but import don´t find users..

Laravel Version: 5.5.4
Adldap2-Laravel Version: 7.0.15
PHP Version: 7.0.9

Description:
Hi,
the login from the front-end works well. If the user doesn´t exists in the DB, adldap2, sync the user and create in the db and login correctly.
But, the import command, no found users.
I tried with different commands but always found 0 users:

php artisan adldap:import user.valid
php artisan adldap:import --filter "(uid=user.valid)"
php artisan adldap:import --filter "uid=user.valid"
php artisan adldap:import --connection ldap "(uid=user.valid)"

Nothing it´s written in the log...
Any idea??
Steps To Reproduce:
This is my config:
adldap_auth.php
return [
    'connection' => env('ADLDAP_CONNECTION', 'ldap'),
    'provider' => Adldap\Laravel\Auth\DatabaseUserProvider::class,
    'resolver' => Adldap\Laravel\Auth\Resolver::class,
    'importer' => Adldap\Laravel\Auth\Importer::class,
    'rules' => [
        //Only valid users from company
        App\Rules\Adldap\ldapFilter::class,
    ],
    'scopes' => [
        // Only allows users with a user principal name to authenticate.
        // Adldap\Laravel\Scopes\UpnScope::class,
    ],
    'usernames' => [
        'ldap' => 'uid', // Changed from 'userprincipalname'
        'eloquent' => 'username', // Changed from 'userprincipalname'
    ],
    'login_fallback' => env('ADLDAP_LOGIN_FALLBACK', false),
    'password_sync' => env('ADLDAP_PASSWORD_SYNC', true),
    'windows_auth_attribute' => ['samaccountname' => 'AUTH_USER'],
    'sync_attributes' => [
        'username' => 'uid',
        'email' => 'mail',
        'name' => 'cn',
    ],
];

Rule: ldapFilter
namespace App\Rules\Adldap;
use Adldap\Laravel\Validation\Rules\Rule;

class ldapFilter extends Rule
{
    public function isValid()
    {
    	$validUsers = [
    		'user.valid',
    	];

    	$validOus = [
            'ou=dc,ou=company,o=com',
        ];

        return in_array($this->user->getFirstAttribute('uid'), $validUsers) || str_contains($this->user->getDN(), $validOus);
    }
}

If you leave off the custom rules are you able to search for a user and import from command line?

If you leave off the custom rules are you able to search for a user and import from command line?

Nop

I have 2 connections configured:

ldap (basedn = o=intranet.rts)
adcare (basedn = DC=company,DC=com)

Command: php artisan adldap:import  --connection "ldap" "(uid=user.testing)"
    [Adldap\Models\ModelNotFoundException]
    No LDAP query results for filter: [(&(objectclass=person)(anr=(uid=user.testing)))] in: [o=intranet.rts]

Command: php artisan adldap:import  --connection "adcare" "(samaccountname=user.testing)"
    [Adldap\Models\ModelNotFoundException]
    No LDAP query results for filter: [(&(objectclass=person)(anr=samaccountname=user.testing))] in: [o=intranet.rts]

I´m not sure if param --connection it´s working, because the basedn it´s the same for both, but if I willfully change the ad connection with incorrect port, I get:
    [Adldap\Auth\BindException]
    Can't contact LDAP server

Hi @Albvadi, I think this is a bug (or lack of the feature being implemented) in v3.0.5 using a different connection for importing users (which you're trying to accomplish).
This is my mistake, and will be fixed shortly :).

Hi @Albvadi, this was actually removed in the new release of v4.0. It became too difficult to manage different connections with the import command (due to all the configuration options available).
If you can write a PR or suggest an implementation that would be great :smile:.


fix: 避免sql erorr

这个 PR 实现什么功能/修复什么问题:
fix: 避免sql erorr
是否需要 backport 到之前的 release 分支:

release/3.2

/area region
/cc @zexi

Codecov Report

Merging #6808 into master will increase coverage by 0.00%.
The diff coverage is 0.00%.

@@           Coverage Diff           @@
##           master    #6808   +/-   ##
=======================================
  Coverage    7.11%    7.12%
=======================================
  Files         654      654
  Lines      110462   110464    +2
=======================================
+ Hits         7857     7868   +11
+ Misses     102000   101990   -10
- Partials      605      606    +1

Flag
Coverage Δ

#aFlag
7.12% <0.00%> (+<0.01%)
:arrow_up:

Impacted Files
Coverage Δ

pkg/compute/models/dbinstance_skus.go
2.60% <0.00%> (-0.02%)
:arrow_down:

pkg/cloudcommon/validators/validators_cert.go
39.77% <0.00%> (ø)

pkg/cloudcommon/cronman/cronman.go
53.95% <0.00%> (+5.11%)
:arrow_up:

Continue to review full report at Codecov.

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


Incorrect Lux Calculation for Sunlight in GLTF Exporter with Standard Lighting Mode

Description:
When exporting a scene with a 1000W Sun light using the GLTF exporter set to the standard lighting mode (intended for use with physically-based units), the exporter incorrectly calculates the light's intensity as 683,000 lux. The expected intensity, based on a widely accepted conversion factor, should be approximately 120,000 lux or more accurately, 120,481 lux. It appears that the exporter uses the formula 1000W * 683 (where PBR_WATTS_TO_LUMENS = 683) for the conversion, misinterpreting the physically based rendering (PBR) watts-to-lumens conversion rate for sunlight. The correct calculation should instead use the conversion factor 0.0083, which translates 1000 watts per square meter to approximately 120,000 lux, or directly apply a multiplication factor of<PHONE_NUMBER>1084337 to achieve the precise value of 120,481 lux.
Steps to Reproduce:

Open Blender and create a new scene.
Add a Sun light to the scene and set its power to 1000W.
Export the scene using the GLTF exporter with the lighting mode set to 'standard', which is for physically-based units.
Check the exported file's metadata for the Sun light's intensity.

Expected Result:
The Sun light's intensity should be calculated to be around 120,000 lux, reflecting the use of the division conversion factor 0.0083, which equates 1000 watts per square meter to 120,000 lux, or using the precise multiplication factor to achieve 120,481 lux.
Actual Result:
The Sun light's intensity is incorrectly calculated as 683,000 lux, indicating the use of the formula 1000W * 683, which misapplies the PBR watts-to-lumens conversion factor.
Additional Information:
The conversion factor 0.0083 is endorsed by a source on ResearchGate discussing the conversion of solar intensity in lux to watts per square meter for sunlight. This factor suggests that 1 lux equals 0.0083 watts per square meter, providing a more accurate method for converting sunlight intensity into lux (ResearchGate discussion).
Environment:

Blender version: 4.0
GLTF Exporter version: 4.0.44
Operating System: Arch Linux

Cc @will-ca @donmccurdy

TL;DR: I'm pretty sure the current implemention is correct. The 0.0083 conversion factor sounds like it includes infrared, and is meant for estimating heat flux for physical objects left in the sun, not for rendering.
The current formulae are the result of an extensive discussion at https://github.com/KhronosGroup/glTF/pull/2214, involved experiments which explicitly confirmed how Blender and other renderers work (https://github.com/KhronosGroup/glTF/pull/2214#issuecomment-1278292085), are consistent with how other renderers work (https://github.com/KhronosGroup/glTF/pull/2214#issuecomment-1276762979), produce results that are consistent with how other renderers look (considering the spec, with appropriate exposure) (https://github.com/KhronosGroup/glTF-Blender-IO/pull/1760), and are immediately derivable from the SI definitions of the candela and the lumen.
I can PR a fix if the current implementation isn't right, but I'm afraid I'm going to have to ask for further explanation why, with consideration of the information and links above/below, if that is the case.

Why `0.0083` probably isn't right. (Click to expand.)

Additional Information:
The conversion factor 0.0083 is endorsed by a source on ResearchGate discussing the conversion of solar intensity in lux to watts per square meter for sunlight. This factor suggests that 1 lux equals 0.0083 watts per square meter, providing a more accurate method for converting sunlight intensity into lux (ResearchGate discussion).

That conversion factor is suggested for estimating total incident energy, for the purposes of physical hardware engineering:

I am trying to develop a solar dryer. for calculation of efficiency i want to know the incident energy on the dryer. I have a luxmeter […]

[…] But very useful for solar energy based research work. […] Purchase lux meter from market under 2 t0 5 thousand according your budget and convert it ino irradiance meter by multiplying irradiance factor, this is a good alternative of the pyranometer to measure irradiance.

It sounds like it outputs an estimated wattage which includes all of the incident energy from the sun, much of which is in non-visible ultraviolet and infrared wavelengths:

I.E. The mentioned 0.0083 number is for working with radiometric irradiance, not photometric illuminance. You can use it to make sure your dryer doesn't melt, but not for drawing pixels in a spec-compliant way.
It presumably does not account for the wavelength-dependent luminous efficiency function of the human eye— You effectively have to mask the above physical power distribution curve with the something like the below luminous efficiency/cone cell sensitivity curves, in order to get a number that you can use for rendering graphics:

[…] the exporter incorrectly calculates the light's intensity as 683,000 lux. […] should be approximately 120,000 lux or more accurately, 120,481 lux.

For rendering, we assume (and measured, by sampling resulting pixel values) that the energy levels used by Blender include only visible wavelengths. Therefore it makes sense that when 1,000W power of visible light is converted to lux illuminance, it produces a higher number than 1,000W of spectrally realistic (including non-visible) sunlight would (because none of the energy is lost to infrared and UV).

How we arrived at `683`. (Click to expand.)

It appears that the exporter uses the formula 1000W * 683 (where PBR_WATTS_TO_LUMENS = 683) for the conversion, misinterpreting the physically based rendering (PBR) watts-to-lumens conversion rate for sunlight.

We discussed the conversion formulae at length prior to deciding and committing the current implementation. That discussion can be found at:
https://github.com/KhronosGroup/glTF/pull/2214
In short, we found that 683 is the industry standard radiometric→photometric coefficient for converting from watts to lumens:

@donmccurdy commented on Oct 12, 2022:

https://devtalk.blender.org/t/why-watt-as-light-value/5658/7
https://google.github.io/filament/Filament.md.html#units
https://seblagarde.files.wordpress.com/2015/07/course_notes_moving_frostbite_to_pbr_v32.pdf and specifically the section below:

Radiometry or Photometry? With non-spectral rendering, like most game engines, the luminous
efficacy information is required for going back and forth between radiometric and photometric units.
As it increases complexity for artists to provide two values (light intensity and luminous efficacy), it
is preferable to use the hypothesis η = 683. With such an approximation, each quantity is a linear
transform of the other and thus their processing will be identical.

It appears that implementations have just adopted a conversion factor of 683, and are (intentionally) not doing the more complex perceptual version of the conversion.

Wikipedia: Lumen (unit) A source radiating a power of one watt of light in the color for which the eye is most efficient (a wavelength of 555 nm, in the green region of the optical spectrum) has luminous flux of 683 lumens. So a lumen represents at least 1/683 watts of visible light power, depending on the spectral distribution.

Wikipedia: Candela The 26th General Conference on Weights and Measures (CGPM) redefined the candela in 2018.[10][11] The new definition, which took effect on 20 May 2019, is:

The candela [...] is defined by taking the fixed numerical value of the luminous efficacy of monochromatic radiation of frequency 540×10^12 Hz, K.cd, to be 683 when expressed in the unit lm W^−1, which is equal to cd sr W^−1, or cd sr kg^−1 m^−2 s^3, where the kilogram, metre and second are defined in terms of h, c and Δν.Cs.

And, when you apply the algebraic unit cancellations to derive the appropriate conversion factors for the units in the KHR_punctual_lights spec, then you do indeed end up at 683 lux of photometric illuminance per 1 watt of visible-wavelength radiometric irradiance in Blender (as well as all the other conversion ratios we settled on):
$ units
You have: (1W/m^2) *(683lm/W)
You want: lux
        * 683

(Wolfram Alpha.)
In this comment, and in the final version of my Pull Request, I then performed extensive experiments to confirm both the implications and the assumptions of these conversion ratios. In short:

Lamp settings in Blender behave as I have described, as radiometric units with no secret non-zero non-visible spectral components (or anything like that), as tested by manually sampling rendered pixel values in linear colour space on a synthetic diffuse scene.
Three.JS in Linear mode behaves consistently with Blender, assuming the dimensions of the various units involved are as I have described, for all three types of KHR_punctual_lights, as tested by measuring the numeric error for all light types, in the same scene rendered in Blender and exported to GLTF.
The final resulting exports from the light strength calculations as currently programmed behave consistently in Blender, Babylon.JS, Three.JS, and the Khronos Group reference GLTF viewer, as tested by exporting a test file with all three light types and visually comparing the results with an appropriate exposure.

The feedback provided is comprehensive and illustrates a well-considered approach to the implementation of light intensity conversion within the GLTF exporter. However, I believe there is a misunderstanding regarding the application of these principles specifically to the representation of sunlight intensity in physically based rendering (PBR) environments, particularly in the context of the GLTF KHR_lights_punctual extension specification, which clearly states that directional lights use illuminance in lux (lm/m2).
1. Misapplication of Conversion Factor for Sunlight:
The conversion factor of 683 lumens per watt is indeed rooted in the definition of the candela and lumen, based on the most efficient wavelength of light perceivable by the human eye. While this conversion is scientifically valid, its direct application to model sunlight intensity in a PBR scene raises concerns. Sunlight, being a natural light source, has a broad spectrum that includes not only visible light but also infrared and ultraviolet wavelengths. The maximum perceived intensity of sunlight on Earth's surface is widely recognized as around 120,000 lux. This figure is not arbitrary but is derived from empirical measurements that consider the full spectrum of sunlight, including its distribution and the human eye's response to it.
2. Physical Realism in PBR:
Physically based rendering strives for realism, attempting to mimic real-world materials and lighting conditions as closely as possible. The KHR_lights_punctual extension specifies that directional lights, such as sunlight, use illuminance in lux (lm/m^2). A value of 683,000 lux for sunlight significantly exceeds the natural world's observed maximum values, which can distort the realism PBR aims to achieve. By adhering strictly to the 683 lumens per watt conversion without considering the specific nature of sunlight, we risk overestimating sunlight's intensity in our virtual environments, leading to non-physically plausible results.
3. Adherence to Real-World Measurements:
While the use of 683 lumens per watt for converting watts to lumens under the most efficient wavelength is technically correct, it disregards the practical aspect of how sunlight is experienced and measured in real-world conditions. For the purpose of rendering environments that are true to life, it is essential to consider real-world measurements and empirical data that provide a more accurate representation of sunlight. This includes recognizing that the maximum sunlight intensity does not exceed 120,000 lux under clear sky conditions at the Earth's surface.
4. Adjustment for Realism in PBR Workflows:
In light of the above points, I propose revisiting the application of the 683 lumens per watt conversion factor specifically for sunlight in the GLTF exporter. Adjusting this implementation to reflect a maximum sunlight intensity of around 120,000 lux would align more closely with real-world observations and empirical data. This adjustment would not only adhere to the physical correctness sought in PBR workflows but also ensure consistency and realism in the representation of sunlight across PBR environments.
5. Expert Consultation:
For further substantiation, it's pertinent to consider authoritative resources and expert opinions. Resources such as the Filament Rendering Engine Documentation and the Frostbite PBR Guide provide insights into realistic lighting models and their application in PBR, supporting a more nuanced approach to modeling sunlight intensity.
Additionally, engaging with experts like Romain Guy, a developer of the Filament rendering engine and a recognized authority in the field of realistic lighting models (@romainguy on GitHub), could yield invaluable insights. His extensive experience and active participation in the PBR community position him as an invaluable resource for exploring the standards of lighting intensity in PBR environments.
Conclusion:
While I acknowledge the rationale behind the current implementation, I believe that adjusting the sunlight intensity to reflect a maximum of 120,000 lux specifically for gaming applications in Physically Based Rendering (PBR) contexts would offer a more accurate and realistic modeling of natural sunlight. This adjustment aligns with the GLTF KHR_lights_punctual specification and empirical real-world data, thereby enhancing the physical realism that PBR workflows strive to achieve in games. Engaging with authoritative resources and expert opinions, such as those from the Filament Rendering Engine Documentation and insights from Romain Guy, could further substantiate this position, making a compelling case for reconsideration.
Moreover, adopting a more physically accurate sunlight intensity could significantly enhance the immersive quality of video games and game engines that utilize GLTF-based assets in their content pipelines, similar to the one I'm currently developing. This approach not only improves the aesthetics and realism of the games' graphics but also ensures consistency across different application cases, including games.

1. Misapplication of Conversion Factor for Sunlight:
[…] The maximum perceived intensity of sunlight on Earth's surface is widely recognized as around 120,000 lux. […]
2. Physical Realism in PBR:
[…] A value of 683,000 lux for sunlight significantly exceeds the natural world's observed maximum values, which can distort the realism PBR aims to achieve. […]

Right. See my previous comment:

For rendering, we assume (and measured, by sampling resulting pixel values) that the energy levels used by Blender include only visible wavelengths. […]

I guess you're probably gonna want to specify a much lower emitted power than 1000W in Blender, then, to realistically account for only the visible wavelengths in sunlight and get the exported lux to an appropriate 120,000.
The radiometric→photometric conversion is a much more complicated process physically than it is possible to model using a simple coefficient. Currently the exporter is based on correct/standard physics and produces light intensities that are proportioned correctly in spec-compliant renderers, to my knowledge.
You can take it up with/submit a patch to show lumens in Blender's UI to the Blender Foundation if you don't want work out the appropriate wattages yourself. But the exporter shouldn't just be changed to use an arbitrary new algorithm if it's currently behaving correctly according to physics/the spec/the ecosystem.

[…] By adhering strictly to the 683 lumens per watt conversion without considering the specific nature of sunlight, we risk overestimating sunlight's intensity in our virtual environments, leading to non-physically plausible results. […]

[…] it disregards the practical aspect of how sunlight is experienced and measured in real-world conditions. […] This includes recognizing that the maximum sunlight intensity does not exceed 120,000 lux under clear sky conditions at the Earth's surface.

4. Adjustment for Realism in PBR Workflows:
In light of the above points, I propose revisiting the application of the 683 lumens per watt conversion factor specifically for sunlight in the GLTF exporter. Adjusting this implementation to reflect a maximum sunlight intensity of around 120,000 lux would align more closely with real-world observations and empirical data. This adjustment would not only adhere to the physical correctness sought in PBR workflows but also ensure consistency and realism in the representation of sunlight across PBR environments.

While I acknowledge the rationale behind the current implementation, I believe that adjusting the sunlight intensity to reflect a maximum of 120,000 lux specifically for gaming applications in Physically Based Rendering (PBR) contexts would offer a more accurate and realistic modeling of natural sunlight.

Note that the words "sun" and "sunlight" do not appear at any point in the KHR_lights_punctual specification. Instead, what the specification defines is directional lights. It doesn't matter if those lights represent the sun, a large lamp placed far away, Rigel, a big laser, or an array of candles inside paraboloidal reflectors.
Modifying the importer/exporter to specifically accomodate sunlight would cause it to violate the spec (and also be inconsistent with Blender/Cycles/EEVEE's behavior, plus every other renderer and importer).

5. Expert Consultation:
For further substantiation, it's pertinent to consider authoritative resources and expert opinions. Resources such as the Filament Rendering Engine Documentation […]
Additionally, engaging with experts like Romain Guy, a developer of the Filament rendering engine […]

I have consulted the document in question. It is one of the places we got the 683 coefficient from.
Unless you are actually intending for Romain Guy to address this issue personally, in an exporter to which AFAIK he has no prior association, I don't see how any part of the rest of this point is relevant to this specific issue and feature, except for in a superficial and stochastic way.
@julienduroure Unless additional information comes to light, I don't think there's a bug here.

I have now written to an astrophysicist (an old acquaintance of mine) and I hope that he will write something here soon. And Romain Guy should already or soon know about this issue, as I wrote to him via Twitter/X.
And as a suggestion on my part, what about another lighting mode or a checkbox called "Directional sunlight scale" or something like that? Because then it would only be optional and it wouldn't break anything else.

In the first place, are any facts about the real physical sun relevant? Correctness needs to be based on equivalence of behavior, not equations between names. The fact there is a thing in Blender called a "sun" doesn't mean it behaves the same as the thing in the real world called a "sun".

In the first place, are any facts about the real physical sun relevant? Correctness needs to be based on equivalence of behavior, not equations between names. The fact there is a thing in Blender called a "sun" does not immediately mean it behaves the same as the thing in the real world called a "sun".

Hmm? But the essence of Physically Based Rendering (PBR) should be to closely simulate real-world light behavior and material interaction, using real values where possible for greater realism and consistency in digital visuals, in my point of view.

Hmm? But the essence of Physically Based Rendering (PBR) should be to closely simulate real-world light behavior […]

Yes, light. 683,000 lux is indeed too bright for a physically based model of our sun. But you got there by defining a 1,000W/m² visible light flux for the sun, which, as I've tried to explain in both my comments, is also not correct and too high because real-world insolation numbers include quantities like infrared and other things that are decidedly not visible light.

The fact there is a thing in Blender called a "sun" does not immediately mean it behaves the same as the thing in the real world called a "sun".

I.E. Our own real-world "sun" is an approximate blackbody radiator filtered through a nitrogen-oxygen-water atmosphere, where less than half the total energy reaching the surface is even visible and even less gets anywhere near the theoretical 683 lm/W peak luminous efficiency at 555nm.
Blender's "sun" is a theoretically perfect radiator where 100% of all its energy is concentrated in the visible spectrum, and furthermore even deep blue and red wavelengths are treated like they have the maximum cone cell sensitivity of green light.
The physics are (mostly) the same, but the object itself is different— Like how a "60W" incandescent lightbulb is different from a "60W" fluorescent light, which is different from a "60W" LED array, which is different from "60W" of idealized point light radiation as you might have in Blender.
In order to have equivalence of behaviour, you need to convert from the two different things you're measuring— So, theoretically, as I said in my first comment, divide the integral of the infrared-inclusive solar spectrum by the integral of that solar spectrum multiplied by human luminous efficiency curves, to calculate how much of the "1,000W" that you're using for your sun should actually be visible— Or, since you know your target lumens and the conversion factor, just do 120,000lm/(683lm/W)≈176W to figure it out.
TL;DR: 1,000W is wrong because it includes a bunch of radiation that isn't light. For rendering you want to include only the part of "sunlight" that's actually visible light, weighted for luminous efficiency, which should be around 176W or so. There's no meaningful/physically consistent way to compensate for that in the exporter, because different suns/planets/light sources/weather conditions/latitudes could change the spectral composition of "sunlight" too.

The Blender documentation clearly says to use 1000 W/m^2 to model the strength of the sun on a clear day.

The Blender documentation clearly says to use 1000 W/m^2 to model the strength of the sun on a clear day.

Yes. We discussed that page of the documentation in the first discussion I linked from my first reply, as well as in an issue linked to the Blender Foundation issue tracker from there:

https://github.com/KhronosGroup/glTF/pull/2214

https://projects.blender.org/blender/blender-addons/issues/91035#1431632

That page of the documentation also contradicts itself repeatedly. For example, it says a 2500lm light source should be 4.5W, and yet a 5000lm light source should be 22W.

Thanks for linking that PR. This line feels like it cuts to the core of the issue:

when Blender decided to move past their own unitless setup they just slapped a "Watts" label on everything (and that happened to work out with mostly sane exposures),

Though I will push back on whether Blender's default exposure is actually reasonable. This Wikipedia section lists out exposure values to use with a real camera which range from 5–7 (home interiors) to 15–16 (daylight). By contrast, Blender's default exposure value seems to be 0!
Has anyone tried to get Blender to make changes on their end? Either to update the documentation to at least be self consistent (and ideally also consistent with the gltf exporter!) or even better to have the option to have light units be lumens / lux?

@fintelia Pushed for it, no. But I think they might be open to it:

billrey
Feb '19
Because this is now part of the units system, we should be able to add a way to display light values in Lumens (Lm) Luxers (Lx) or Candelas (Cd), by adding an enum menu of options in the Scene > Units section.
This might be a good task for a new developer to create a patch for this.

I bet there's a single big struct/enum somewhere that you'd pop the 683.0 coefficient(s) into, CTRL+SHIFT+F to find the places it's used, add a dropdown to the scene panel— Hm, looks like it's PROP_POWER in #60824 on the BF Gitea.
(Though if W is used anywhere else to mean actual power, and not just luminous flux, then that would be another needed separation.)

Don't know about the "Exposure" slider. It acts more like the "Exp Comp" button you get on cameras, than the shutter speed/aperture definition (especially without ISO).
I just meant Watts was both physically based and backwards-compatible, without introducing numeric changes or changed exposure to old files.


How to use it at IOS?

In theory you should be able to import the model and use it in CoreML but we did not tested it.

I've found a way to use pretrained models in Android / iOS APPs.

I've found a way to use pretrained models in Android / iOS APPs.

how? I am starting to investigate how to use spleeter for iOS, thanks

Did anyone ever figure this out?

https://github.com/FaceOnLive/Spleeter-Android-iOS

Did anyone ever figure this out?

I have not found anything yet. The library suggested above is paid, unfortunately.

https://github.com/FaceOnLive/Spleeter-Android-iOS

I have tried it on ios, but there is a issue with it.
spleeterSDK.process(wavPath!, outPath: url.path)
is returning 1 instead of 0
can anyone help with the issue or Any other way to run spleeter on ios?

https://github.com/FaceOnLive/Spleeter-Android-iOS

I have tried it on ios, but there is a issue with it.
spleeterSDK.process(wavPath!, outPath: url.path) is returning 1 instead of 0
can anyone help with the issue or Any other way to run spleeter on ios?

Yes, I have the same problem. Have you solved it？

https://github.com/FaceOnLive/Spleeter-Android-iOS

I have tried it on ios, but there is a issue with it.
spleeterSDK.process(wavPath!, outPath: url.path) is returning 1 instead of 0
can anyone help with the issue or Any other way to run spleeter on ios?

Yes, I have the same problem. Have you solved it？ @MuhammadAarfeen

Contact us in repo for the guide.

Contact us in repo for the guide.

<EMAIL_ADDRESS>@zhu-j-faceonlive

I messaged faceonlive if I can get a copy of the sdk for my iPad. They asked for $6,000. I’ll just use the free version I already have on my computer.


MWPW-147361-Update firefly model to v3

Update firefly model to v3

Resolves: MWPW-NUMBER
Test URLs:

Before: https://stage--cc--adobecom.hlx.live/drafts/ruchika/firefly/remove-dnt/document1?martech=off
After: https://firefly-model3--cc--adobecom.hlx.live/drafts/ruchika/firefly/remove-dnt/document1?martech=off

Verified in the below url as advised :
https://firefly-model3--cc--adobecom.hlx.live/drafts/ruchika/firefly/remove-dnt/document1?martech=off

click on generate and signin

url redirected to :

modelInputVersion=v3&modelConfig=v3 is seen in url


[BUG] while leaving cmus paused for a while cordmus crashes

here is the output to console
./cordmus
/home/sam_tunder/git/cordmus/src/cordmus.nim(142) cordmus
/home/sam_tunder/.nimble/pkgs2/cligen-1.7.8-1261a00456f7837bd34eefa24f4f13c0fc9a6545/cligen.nim(906) cligenScope
/home/sam_tunder/.nimble/pkgs2/cligen-1.7.8-1261a00456f7837bd34eefa24f4f13c0fc9a6545/cligen.nim(865) dispatchcordmus
/home/sam_tunder/git/cordmus/src/cordmus.nim(136) cordmus
/home/sam_tunder/git/cordmus/src/cordmus.nim(84) update
/home/sam_tunder/.nimble/pkgs2/discord_rpc-0.2.0-d3c707a1e8b032d8625828d0fde6ddaae1419f00/discord_rpc.nim(846) setActivity
/home/sam_tunder/.nimble/pkgs2/discord_rpc-0.2.0-d3c707a1e8b032d8625828d0fde6ddaae1419f00/discord_rpc.nim(697) send
/home/sam_tunder/.nimble/pkgs2/discord_rpc-0.2.0-d3c707a1e8b032d8625828d0fde6ddaae1419f00/discord_rpc.nim(691) send
/home/sam_tunder/.nimble/pkgs2/discord_rpc-0.2.0-d3c707a1e8b032d8625828d0fde6ddaae1419f00/discord_rpc.nim(282) write
/usr/lib/nim/std/assertions.nim(41) failedAssertImpl
/usr/lib/nim/std/assertions.nim(36) raiseAssert
/usr/lib/nim/system/fatal.nim(53) sysFatal
Error: unhandled exception: /home/sam_tunder/.nimble/pkgs2/discord_rpc-0.2.0-d3c707a1e8b032d8625828d0fde6ddaae1419f00/discord_rpc.nim(282, 5) `s.send(unsafeAddr payload[0], payload.len) == payload.len`  [AssertionDefect]

Sorry, i havent had the time to look into this until now.
This error is generic and actually happened with another bug i encountered where an ascii double quote " in a song title caused this error to be thrown. I solved that (temporarily) by replacing ascii double quotes with unicode ones in cordmus. The error is something from the underlying Nim Discord RPC library im using and i have no idea what it is, as i havent gotten around to dig around the library or report an issue on their github yet. Ive had cmus paused for a while before but i never encountered this issue. Can you provide some more details, like what is the title/album name of the song song you paused cmus at, how long did you have it paused for, or if you can replicate it again?

sadly not reproduced the bug and don't recall what song was the selected one while paused


npm package 0.1.4 does not match git commit with tag 0.1.4

The types file updated in https://github.com/WiredSolutions/react-azure-maps/pull/74 (commit tagged 0.1.4) does not match the one in npm package 0.1.4.
Sample repro:

npx create-react-app my-app --template typescript
Change directory to /my-app
npm i react-azure-maps
Check node_modules/react-azure-maps/dist/types/types.d.ts - it is not updated

Alternatively download the .tgz directly from npm using link below, extract it, and you'll notice that types.d.ts is still the old version.
https://registry.npmjs.org/react-azure-maps/-/react-azure-maps-0.1.4.tgz
No code changes are required, so there's nothing I can do to help but report the issue. The npm package may need to be re-published.

Hi @bg6471, I republished package.


[ADD] PySpark Cheatsheet

Quick reference guide to common patterns & functions in PySpark.

https://github.com/kevinschaich/pyspark-cheatsheet  last update 5mohts ago

You guys wanna merge this or should I close it, 4 years 🙃

Are you OK with this @oluies ?


Vite's generated build files always include filename, linenumber and columnnumber info

Describe the bug
When I do a build with vitejs, regardless of mode production or development, the generated build files always embed filename (with absolute file path values), line number, and column number info.
The expected behavior is that if the sourcemap is turned off, these info should not be include in the build files. How do I turn them off? Thanks.
Here is the snippet of what the content of the generated file looks like:
const Main = () => {
  return /* @__PURE__ */ jsxDevRuntimeExports.jsxDEV("div", { children: /* @__PURE__ */ jsxDevRuntimeExports.jsxDEV("h1", { children: "Hello World" }, void 0, false, {
    fileName: "/Users/tpham/Documents/Cogility/dctc/Engagements/vite-build/src/components/Main.tsx",
    lineNumber: 5,
    columnNumber: 13
  }, void 0) }, void 0, false, {
    fileName: "/Users/tpham/Documents/Cogility/dctc/Engagements/vite-build/src/components/Main.tsx",
    lineNumber: 4,
    columnNumber: 9
  }, void 0);
};
function App() {
  return /* @__PURE__ */ jsxDevRuntimeExports.jsxDEV(Main, {}, void 0, false, {
    fileName: "/Users/tpham/Documents/Cogility/dctc/Engagements/vite-build/src/App.tsx",
    lineNumber: 6,
    columnNumber: 9
  }, this);
}
client.createRoot(document.getElementById("root")).render(/* @__PURE__ */ jsxDevRuntimeExports.jsxDEV(App, {}, void 0, false, {
  fileName: "/Users/tpham/Documents/Cogility/dctc/Engagements/vite-build/src/index.tsx",
  lineNumber: 5,
  columnNumber: 62
}, void 0));

Reproduction
https://github.com/tpham/vite-build
Steps to reproduce
You can inspect the already-generated contents of the dist folder. Or:

Run npm run build
Inspect the generated javascripy file in dist/assets folder. Notice filename, linenumber, columnumber info embedded.

System Info
System:
    OS: macOS 14.4.1
    CPU: (10) arm64 Apple M1 Max
    Memory: 1.89 GB / 64.00 GB
    Shell: 3.2.57 - /bin/bash
  Binaries:
    Node: 20.13.1 - ~/.asdf/installs/nodejs/20.13.1/bin/node
    Yarn: 1.22.19 - ~/node_modules/.bin/yarn
    npm: 10.5.2 - ~/.asdf/plugins/nodejs/shims/npm
  Browsers:
    Chrome: 124.0.6367.208
    Edge: 125.0.2535.51
    Safari: 17.4.1
  npmPackages:
    @vitejs/plugin-react-swc: ^3.5.0 => 3.7.0
    vite: ^5.2.0 => 5.2.12

Used Package Manager
npm
Logs
No response
Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to vuejs/core instead.
[X] Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
[X] The provided reproduction is a minimal reproducible example of the bug.

I ran build on your repo, but I couldn't reproduce. I'm properly getting jsx instead of jsxdev:
// dist/assets/index-Dk4KTi2w.js
const Main = () => {
  return /* @__PURE__ */ jsxRuntimeExports.jsx("div", { children: /* @__PURE__ */ jsxRuntimeExports.jsx("h1", { children: "Hello World" }) });
};

Is it possible that you have NODE_ENV=development somewhere in your shell? That would probably trips up Vite to build with development mode.

I think I figured out the cause but it is weird. So I changed the build command to include NODE_ENV=production but that didn't change the generated output file, like so:
"build": "NODE_ENV=production tsc && vite build",

However, by removing tsc from the command (like below), then I got jsx instead of jsxDev:
"build": "NODE_ENV=production vite build",

I think the tsc command interferes with it, is there a need to include it in the build command? It defaults that way when I first created the project. Anyway, consider the problem resolved. Thank you for looking into it!

I don't think tsc is related. It's just a shell thing that NODE_ENV=production tsc && vite build don't give NODE_ENV to the 2nd command.
Either way, it's totally your choice to not have tsc during build.


no manual settings for forwarding since Hyperion-2.0.13/mDNS integration

[x] I confirm that this is an issue rather than a question.

Bug report
forwarding settings for mDNS replace manual IP entries
Steps to reproduce
install Hyperion-2.0.13
goto settings/network
enable forwarding
try to setup IPs manually without finding anything with mDNS first
What is expected?
that users can still do manual IP setup - auto-discovery should just be a new addition to the old settings from .12
What is actually happening?
the new auto-discovery for mDNS replaced the old settings completely, so users cannot setup targets manually - at least not without finding one with mDNS first.
System
Hyperion Server:

Build:           (HEAD detached at df149583) (GitHub-dc6aa4dd/df149583-1637501177)
Build time:      Nov 21 2021 16:50:38
Git Remote:      https://github.com/hyperion-project/hyperion.ng
Version:         2.0.12
UI Lang:         de (BrowserLang: de-DE)
UI Access:       expert
Avail Capt:      v4l2,qt,dx
Config path:     C:/Users/user/.hyperion
Database:        read/write

Hyperion Server OS:

Distribution:   Windows 10 Version 2009
Architecture:   x86_64
Kernel:         winnt (10.0.22000 (WS: 64))
Root/Admin:     true
Qt Version:     5.15.0
Python Version: 3.10.0
Browser:        Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/<IP_ADDRESS> Safari/537.36

The mDNS discovery way ensures that the configuration with the remote configuration is correct and working.
On top , in case the port of the remote Hyperion is changed, the forwarding Hyperion will adapt to the new port as the handshake is via the exposed service capabilities.
Would you mind elaborating why a manual configuration is required with the risk of inconsistent configurations?
Note: as a workaround, you could export the configuration and replace the remote Hyperion's mDNS service name via an IP.

Closing as no feedback was provided


Got kernel installed, touchscreen doesn't work.

When I boot into the surface kernel the touchscreen does not work.
I followed the steps and got no errors.

Wich device did you run the setup.sh

What device did you install the kernel on? Was it a surface pro? Surface pro 4? etc.

What device did you install the kernel on? Was it a surface pro? Surface pro 4? etc.

Wich device did you run the setup.sh

Surface Pro 6

Seems like an upstream issue. It looks like my setup.sh follows jakeday's setup.sh for installation of IPTS touchscreen drivers for the Surface Pro 6 option.

Closing issue in 7 days if there are no new developments.

Try re-running the setup script with mkinitcpio, firmware, and libwacom options selected. Make sure to install the latest kernel version (5.3.15) too.


Consider changing documentation fonts

Most of the fonts in our generated documentation make it easy to confuse uppercase I and lowercase l.  We should consider switching to one with a more distinct character set.

one with a more distinct character set

I'm not opposed to switching to a serif font for the class name.  I wouldn't change the entire page to that though.  It's easier to read sans-serif fonts.

Maybe monospace instead of introducing a serif?


Preview transaction info before sending it in zos send-tx

When using zos send-tx, we can show the user an estimate of how much gas it's going to take, how much it's going to cost in fees (price times estimated gas), and whether it's going to fail or not. We can ask for the user to confirm the tx before sending it then.

Would it be possible, perhaps with a verbose flag, or "-showTransaction" to show them the actual transaction? I could imagine a use case where someone needs to build a transaction that they would like to copy-paste for something else.

It would also help to preview gas estimate of calls, not just txs.


Updates to Grid style / visual config and CSS

Support rowBorders and stripeRows observables on GridModel.
Borders off by default, row striping remains on.
Move Grid.showHover prop -> GridModel.highlightOnHover.
Update grid variant CSS class names to BEM conventions.
Ensure Hoist border-color CSS var actually applies, then set to a lighter value.

Note this is technically a breaking change due to the rename of the (relatively minor) Grid.showHover prop and tweaks to grid CSS classes, but I think these are small / edge enough to take into a minor version release if we wanted.

Hi -- making some tweaks here and will merge shortly.  I think its ok and preferable to continue to rely on bindable now (and since you said you didn't feel too strongly... :-))  If we decide it's really inappropriate and should be replaced with setXXX(), I think we could look to do that in a consistent bombing.


Eliminate warnings in tests

Fix all warnings and errors in the test suite. All test can now be run as either python setup.py test or pytest. Even in most verbose pytest -r A -W d.

This PR closes #213, which contains further details.


Revert "feat: update ecosystem page"

Reverts base-org/web#1334

🟡 Heimdall Review Status

Requirement
Status
More Info

Reviews

🟡
0/1

Denominator calculation

Show calculation

1 if user is bot
0

1 if user is external
0

From .codeflow.yml

1

Additional review requirements

Show calculation

Max
0

0

From CODEOWNERS

0

Global minimum
0

Max

1

1

1 if commit is unverified
0

Sum
1

🟡 Heimdall Review Status

Requirement
Status
More Info

Reviews

🟡
0/1

Denominator calculation

Show calculation

1 if user is bot
0

1 if user is external
0

From .codeflow.yml

1

Additional review requirements

Show calculation

Max
0

0

From CODEOWNERS

0

Global minimum
0

Max

1

1

1 if commit is unverified
0

Sum
1


Removes deprecated EventHubs PubSub component

Description
Removes deprecated Azure EventHubs PubSub component
Issue reference
#951
Checklist
Please make sure you've completed the relevant tasks for this PR, out of the following list:

[X] Code compiles correctly
[X] Created/updated tests
[ ] Extended the documentation / Created issue in the https://github.com/dapr/docs/ repo: dapr/docs#[issue number]

need sync with master

We will remove it in 1.6 instead per the stated deprecation policy.
But really nobody should be using this 😀


Update monitors to support latest features, favor API model

what

Update the monitors support to support all current features supported by the Datadog terraform provider
Revise the input to match the Datadog API model (see modules/monitors/README.md for details)

why

Module did not support several current features
Make it easy to use the Datadog Web Console to create and edit monitors, then convert the exported JSON to input to this module

references

monitors/README
Supersedes #86
Closes #85
Supersedes #84
Supersedes #76

/terratest

/terratest


Not an Issues

This is not an Issues, but will work start on this great mod for 1.13.1/1.14 soon

#390 when Forge for 1.13 is out

@Lunatrius It is out.

Time to get crackin'!


Implement Public Addon Config

There is a new preferred way to store configs. We should implement that and somehow provide a migration for legacy installations
https://developers.home-assistant.io/blog/2023/11/06/public-addon-config/
https://developers.home-assistant.io/docs/add-ons/configuration/#add-on-advanced-options

Some add-ons need access to all these add-on-specific config folders. For example:

Samba

SSH

Studio Code Server

When those updated I will update the addon and release notes.

implemented

Don't you think we should consider a non-breaking migration?

whats your proposal?

You have your db in /data/evcc.db?

whats your proposal?

My proposal is to first of all roll back to /config, because of all the confusion this generates - see https://github.com/evcc-io/evcc/discussions/10744
The HA Supervisor Team got that too and will push out an update which makes /config and /addon_config side-by-side and this will allow us to do config migration in the background. See https://github.com/home-assistant/supervisor/pull/4697 for details

old status, next try will be when HA has fixed there problems. I will leave this open.

Currently frenck is doing a hacky migration, see https://github.com/hassio-addons/addon-appdaemon/pull/285/files#diff-a3cb8f1cd3251bfb32a8e374ec6ce13a10be81b009300b9f570d5b6fd70f0352R8
So what they do:

map homeassistant_config:rw into the addon
change mapping from config:rw to addon_config:rw
migrate the config file(s) from /homeassistant/ to /config/
... some weeks/months/years later, you should be safe to remove homeassistant_config:rw

I'll try this inside my own fork and will monitor the official HA addons what they're doing.

Hello everybody and first of all: thank you for providing evcc as this wonderful Home Assistant add-on! 👍
A few days ago I tried to install the add-on by following the installation instructions in the README and unfortunatelly I have to say, that I got very confused 🙈 The instructions still tell the user to copy evcc.yaml to the /addon_configs/<your addon's slug> directory. After I figured out, how to access this directory, I realized (from the discussion over at the main repository) that you reverted the change in the add-on and I had to use /config after all.
Finally, after some rather frustrating tinkering, I got the add-on to work properly 🎉 To spare future users this ordeal, please fix the README 🙏
Since almost two months have past since your last comments, I got curious what the state of affairs was. The revert mentioned above (https://github.com/home-assistant/supervisor/pull/4697) was reverted yet again (https://github.com/home-assistant/supervisor/pull/4702). So it seems that was Frenck is doing in his add-ons (mapping addon_config plus homeassistant_config and moving existing configurations from /homeassistant to /config) is the way to go.
If you find the time to implement that, you could just leave the README as is 😄

Is there any idea out there? It looks like that evcc.db in /data is not persistent in docker host (Home Assistant) instead its only locally store in docker container, or where to find it on the host ?

@goebelmeier, we should give it another try…?

where to find it on the host

Just run a docker inspect on the container id. Should be /mnt/data/supervisor/addons/data/<id>_evcc.

@klein0r an easy way:
https://github.com/evcc-io/hassio-addon/blob/main/README.md#how-to-find-and-copy-dataevccdb
documentation is adapted.

@thecem Thanks, that was exactly my solution: https://www.youtube.com/watch?v=ibrmbByk0MU

@goebelmeier, we should give it another try…?

From my point of view it's worth trying. But first of all we need to extend https://github.com/evcc-io/evcc/blob/master/packaging/docker/bin/entrypoint.sh to contain the migration logic. So:

check if ${CONFIG} (should be /config/evcc.yaml) exists, if yes, skip next parts
if not, check if /homeassistant/evcc.yaml exists and copy it to ${CONFIG} (which again should be /config/evcc.yaml)

If that logic exists, we could

map homeassistant_config:rw into the addon
change mapping from config:rw to addon_config:rw
on first start, the entrypoint.sh should copy the config from /homeassistant/evcc.yaml to /config/evcc.yaml and on subsequent restarts it should not change anything any more
some weeks/months/years later, you should be safe to remove homeassistant_config:rw

following mapping is possible:
map:
  - type: homeassistant_config
    read_only: False
  - type: addon_config
    read_only: False

"homeassistant_config":
/homeassistant in container maps to /config directory in home assistant
Addon Configuration
-> Options
-> config_file: /homeassistant/evcc.yaml maps to /config/evcc.yaml
"addon_config":
/config in container maps to /addon_configs/<slug>_evcc directory in home assistant
Addon Configuration
-> Options
-> config_file: /config/evcc.yaml maps to /addon_configs/<slug>_evcc/evcc.yaml

With this we could trigger following:
If a file /homeassistant/backup_evcc_db_from_data.txt (or something similar) exist:

copy /data/evcc.db to /config/evcc.db (which maps to /addon_configs/<slug>_evcc/evcc.db)
if copy is sucsessfull delete /homeassistant/backup_evcc_db.txt

Advantages:

User could decide when they migrate the evcc.db
User are easy able to get there evcc.db out of the /data directory


responses: Korean better translation for "move"

original one, 움직이기! is used in two triggers
changed one, 이동하기! is used in four triggers
These two are slightly different in meaning, but if player knows mechanics in battle, they'll understand with any of which shows.
But, I have some concerns, sometimes other languages don't have exact same meaning words corresponding to English,
which means it seems fine to use same Responses for multiple triggers in English, sometimes it does not in other languages.
How do we deal with it?
I already sacrificed some readability in Korean responses, it's bearable now but there can be very different meaning in Korean in the future.

But, I have some concerns, sometimes other languages don't have exact same meaning words corresponding to English,
which means it seems fine to use same Responses for multiple triggers in English, sometimes it does not in other languages.

Can you show some examples about these "words"?
I think if it happens in Korean, it might happen in Japanese or even Chinese too.

stack
Korean people call stack marker as 쉐어징 (쉐어 for stack / 징 for marker)

But it only mean "that" marker.
sometimes, there's stack, means just stack and bait aoe in the middle, in Korean that would be 모이기.
Those are slightly different.
쉐어징 problem is Korean community's tacit(?) word, not dictionary thing.
move
move has two usage,

move to avoid freezing
move to dodge aoes

first one, in Korean, it's better to say 움직이기 (okay to move z axis)
second one, in Korean, it's better to say 이동하기 (move x, y axis)
If we only say 움직이기 and without mechanic knowledge, player would understand just to jump.
etc
There'd been some more examples but those are okay not using exact word, better not separating, for project maintenance.

Yeah, it is the same as Japanese and Chinese too.
For "Stack" things, when it refers to "share damage", we always say, "分摊"/"頭割り"; when it refers to "get together", we'll say, "集合"/"集合".
So when I am translating the mechanics I would check it out what is exactly the solution, so I can write the correct word to refer it.
Also, for "Move", we have "移动"/"動く" and "避开"/"避け" and so many words.
I would agree what you said.

But, I have some concerns, sometimes other languages don't have exact same meaning words corresponding to English,
which means it seems fine to use same Responses for multiple triggers in English, sometimes it does not in other languages.
How do we deal with it?

If there are phrases that need to be differentiated in other languages, I think we should add multiple responses.  Maybe something like moveAway vs moveAround (or some other phrasing, with some comments about when to use each)?

I already sacrificed some readability in Korean responses, it's bearable now but there can be very different meaning in Korean in the future.

Can I ask which responses you have sacrificed readability on? What can be improved?

move part I mentioned on the third comment was it. I thought "sacrifice" was some strong word, but I couldn't think of other words.

I'll change responses.js as quisquous mentioned to split response, then change status to ready for review.

Thanks!  Please speak up in the future if something like this comes up again.


Push v0.7.2 to quay.io

It would be lovely to get easy access to every release, especially latest.

Hey @sdlarsen, we're aware, that the image is not published yet, I'm sorry about that. Unfortunately, during my testing, it turns out that there are more fixes required to get the operator working on Kubernetes 1.17 and we are now actively working on that.
Once that is fixed, I'll make another release and push the Docker images. You can track the progress of this work in the milestone I created: https://github.com/kinvolk/flatcar-linux-update-operator/milestone/1.

@sdlarsen v0.7.3 is now released and available in quay.io, as 0.7.2 was faulty and we recommend all users to update to v0.7.3. Please let us know if it works for you now (if not, please create another issue).
As the latest image is available in quay.io, I'm going to close this issue now.

Thanks!


SqlBrowserClient

SqlBrowserClient is not getting all the server names ? I wonder if you suggest any modifications for this code

Hey there,
Sorry for the very late reply. When you are saying it's not getting all the server names, how are you testing this hypothesis? Using Management Studio? or another tool?

Thank you for this code. I'm also having a similar issue of not getting all servers on the network that have SQL Server instances running. Currently looking into it on my end.

I think I found the issue. When I got the raw response from the SqlBrowserClient, it looks like all the SQL servers are located in the content. I think the regex is somehow parsing out some databases on the local network.


Fixes broken CSS classes

Appears that YNAB updated CSS variable names from snake_case to camelCase. I did my best to update all of them and not break anything, but there were a ton of changes
GitHub Issue (if applicable): #3382, #3383
Explanation of Bugfix/Feature/Modification:
Fix outdated CSS classes

@YusefOuda Thanks for fixing this! I went to try out my new fix from #3359 and thought I broke something. I found the issue and got like half way through fixing and realized I hadn't pulled from main and 🪄 they were fixed! From my second pass it looks like you got them all, appreciate it!


Test: "Open in Desktop" from web

Refs:

[ ] macOS @btholt
[ ] linux @JacksonKearl
[ ] windows @chrmarti

Complexity: 3
Verify that you can open VSCode insiders on a remote workspace from the web.

open a workspace via web
verify you see a "Open in Desktop" status entry that you can click
verify this opens the remote workspace in your local installed VSCode insiders when VSCode is not running
verify this opens the remote workspace in your local installed VSCode insiders when VSCode is running on a different workspace

open a workspace via web

@bpasero  Not sure how to do this, yarn web puts me in a sample folder and in that case "Open in Desktop" just opens Insiders to whatever was last open. And VSO does not have an "Open in Desktop" button.


Add Ubuntu icon as default for detected WSL Ubuntu profile

Blocked on https://github.com/microsoft/vscode-codicons/issues/61

Added terminal-ubuntu to Codicons via 1e6315f7059c803d17e12ee35938ecec5aedf06b


v2.3.0

What does this PR do?:

Merges changes from main that were made from v2.2.2 onwards into v2.3.x branch
Which issue(s) this PR fixes:

Part of https://github.com/devfile/api/issues/1620
PR acceptance criteria:
Testing and documentation do not need to be complete in order for this PR to be approved. We just need to ensure tracking issues are opened and linked to this PR, if they are not in the PR scope due to various constraints.

[ ] Unit/Functional tests

[ ] QE Integration test

[ ] Documentation (READMEs, Product Docs, Blogs, Education Modules, etc.)

[ ] Client Impact

[ ] Gosec scans

How to test changes / Special notes to the reviewer:

Note DCO check is because usernames on git differ - Similar to what happened with v2.2.2 release

Note DCO check is because usernames on git differ - Similar to what happened with v2.2.2 release

Set DCO to pass as the 2 commits it was complaining about were signed the main email attached to the committers github were just different:
https://github.com/devfile/library/pull/223/commits/45a4cc4d35047460d1e25639575107b5d0959e86
https://github.com/devfile/library/pull/223/commits/d966ea316c00446eeda623f49f4befb9431a6a29


VM: Reflective access to simple name of constructor should be consistent in declarations and newInstance

The simple name of a constructor should be the identifier without the class or the constant symbol for the empty string if it is a default constructor. Currently this is not the case with unfortunate consequences.
One cannot lookup a constructor and use its simple name to run it, because the "simple" name is actually qualified by the class name.  This leads to the need to do string surgery to call the constructor.
The qualified name ends up being library.Class.Class.id which is very confusing.
Once the simple name behaves correctly, these problems should go away.
See issue #13248.

@rmacnak-google Is this something we are going to fix? If not consider closing this issue as stale.


suppress unwanted docs

Goal
Suppresses unwanted symbols that are internal-only from our KDoc. @hide should not be used - @supress should be used instead. Anything inside an internal.** package is automatically hidden by our Dokka setup.
This hides the vast majority of unwanted symbols. We may want to convert some Java classes as part of the major bump to have a mechanism for hiding them (and also get rid of Java code).

There isn't a way to get Dokka to understand arbitrary annotations as far as I can see unfortunately. However, given that we're moving most of the internal classes to other modules eventually this should be a much smaller problem in future.


Repository upload unexpectedly halts on 0kb file.

Command attempted:

In github web interface, the drag and drop file upload halts on 0KB files.
What happened:

No further files upload, no error message.
More info:

github.com, 26/04/2021, chrome on windows 10

Hi, I believe this is a question about GitHub.com, the website. This issue tracker is for a command-line utility called hub, not the website itself. For reporting bugs and requesting features for GitHub the website, please go to https://github.com/contact or visit https://github.community. Thank you!


MiddlewareError: Type generator exists in middleware but is missing in Schema.

Bug report

[x] I have checked other issues to make sure this is not a duplicate.

there are a few similar issues but they were closed without any solution:

https://github.com/maticzav/graphql-shield/issues/970
https://github.com/maticzav/graphql-shield/issues/151#issuecomment-428368605

Describe the bug
file:///home/v1rtl/Coding/x/api/node_modules/.pnpm/graphql-middleware@6.1.11_graphql@15.0.0/node_modules/graphql-middleware/dist/validation.mjs:10
      throw new MiddlewareError(`Type ${type} exists in middleware but is missing in Schema.`);
            ^

MiddlewareError: Type generator exists in middleware but is missing in Schema.
    at file:///home/v1rtl/Coding/x/api/node_modules/.pnpm/graphql-middleware@6.1.11_graphql@15.0.0/node_modules/graphql-middleware/dist/validation.mjs:10:13
    at Array.forEach (<anonymous>)
    at validateMiddleware (file:///home/v1rtl/Coding/x/api/node_modules/.pnpm/graphql-middleware@6.1.11_graphql@15.0.0/node_modules/graphql-middleware/dist/validation.mjs:8:27)
    at addMiddlewareToSchema (file:///home/v1rtl/Coding/x/api/node_modules/.pnpm/graphql-middleware@6.1.11_graphql@15.0.0/node_modules/graphql-middleware/dist/middleware.mjs:8:27)
    at normalisedMiddlewares.reduceRight.schema.schema (file:///home/v1rtl/Coding/x/api/node_modules/.pnpm/graphql-middleware@6.1.11_graphql@15.0.0/node_modules/graphql-middleware/dist/middleware.mjs:36:9)
    at Array.reduceRight (<anonymous>)
    at applyMiddlewareWithOptions (file:///home/v1rtl/Coding/x/api/node_modules/.pnpm/graphql-middleware@6.1.11_graphql@15.0.0/node_modules/graphql-middleware/dist/middleware.mjs:29:77)
    at applyMiddleware (file:///home/v1rtl/Coding/x/api/node_modules/.pnpm/graphql-middleware@6.1.11_graphql@15.0.0/node_modules/graphql-middleware/dist/middleware.mjs:51:10)
    at file:///home/v1rtl/Coding/x/api/graphql/schema.ts:23:17
    at ModuleJob.run (node:internal/modules/esm/module_job:183:25)

To Reproduce
import { makeExecutableSchema } from '@graphql-tools/schema'
import { applyMiddleware } from 'graphql-middleware'
import { shield, rule } from 'graphql-shield'
import { gql } from 'graphql-tag'

// Construct a schema, using GraphQL schema language.
let typeDefs = gql`
  type Query {
    hello: String
  }
`

const resolvers = {
  Query: {
    hello: () => 'Hello world!'
  }
}

const permissions = shield({
  Query: {
    hello: rule()(async () => {
      return false
    })
  }
})

const _schema = applyMiddleware(
  makeExecutableSchema({
    typeDefs,
    resolvers
  }),
  permissions
)

export const schema = applyMiddleware(_schema, permissions)

{
  "name": "api",
  "type": "module",
  "dependencies": {
    "@graphql-tools/schema": "^8.3.1",
    "graphql": "15.0.0",
    "graphql-middleware": "^6.1.11",
    "graphql-shield": "^7.5.0",
    "graphql-tag": "^2.12.5"
  },
  "devDependencies": {
    "@types/node": "^16.11.6",
    "tsm": "^2.1.4"
  }
}

$ tsm index.ts

Environment

Node.js 16.11
Linux x64
pnpm 6.17.2

I think it's connected with https://github.com/maticzav/graphql-middleware/issues/433 and you can downgrade graphql-middleware to =6.0.9 to make it work.


Google Signup should add firstname and lastname to user account

currently both values are null

We are using displayName now instead of first and last names.  Google gives us this.


gradle 7.4.2

https://docs.gradle.org/7.4.2/release-notes.html#upgrade-instructions

It is already at 7.4.2:
https://github.com/Netflix/spectator/blob/main/gradle/wrapper/gradle-wrapper.properties#L3