Added Gltf_Viewer files and its new model files.

Removed Debug_BVH_Intersection.html and its model file.

If you want keep the Debug_BVH_Intersection.html, let me know, so I exclude it from the PR. But if you do please change the model used in that scene and remove the scene.gltf model file.

Hi @n2k3
The revised viewer is looking really good!  I will copy your code into my editor and play around with some of the settings and epsilons and see if I can get rid of some of those light leaks.  I will also look over the shader code carefully and see if I can spot any errors or optimization candidates - but from how it's running nicely, it looks really good so far!
About the old debug_intersection html file, that's fine - you can permanently remove that.  I will want to use your most updated version of the viewer on this repo going forward.
Great work!  I'll let you know when I can look over everything.
Thanks,
-Erich

@n2k3
I cleaned up and updated the shader code.  You can find it here
Yes you might want to comment out the back-face culling inside pathTracingCommon, the BVH_TriangleIntersect() routine.  I also found this necessary in order to avoid the light leaks with this house model.  I also adjusted the epsIntersection to be higher.  The windows appear to be working but the color or dark tinting on the windows makes the sunlight that goes through the windows too dark in my opinion.  You might still try lightening the color to almost white, vec3(1.0, 1.0, 1.0) with maybe the red channel dialed down just a little less, 0.8 or so, for a greenish bluish tint.  But again, real house windows are pretty clear, almost white.  I have to go to work but I will make another post talking about the sunlight and other things like clouds and sky.  Let me know what you think so far

Hi, I'm back to discuss the directLighting and sky stuff.  About the directLighting, I noticed you tried directLightingSun and had to comment it out because it was crashing your browser gl context.  That was the original issue I ran into also a month or so ago when starting to work with more heavy models of 10,000 triangles and up.  With the older more simple scenes, the directLighting worked fine, and this is in fact the way most commercial renderers handle bright small light sources like the sun, or a spotlight or point light.  Without going too much into details, basically when a ray hits a diffuse surface, it sends out a shadowRay towards the sun or other bright small light source of our choosing.  If it hits nothing along the way, great, we light the surface.  If it runs into anything else however, the color comes back vec3(0), which is why they are nicknamed shadowRays.  They make everything converge much faster, but at a cost of sending double the amount of rays for diffuse surfaces.
This worked fine until the models got more complex, then the cost of sending out those extra shadowRays was really adding up.  Now on a modern expensive graphics card along with a C++ and CUDA or DirectX RTX environment, it wouldn't break a sweat, but with WebGL, javascript, glsl shaders, etc.,  the cost is just too much and the scene either won't compile or will run for just a few seconds before crashing.   A couple of months ago I thought I had hit a wall with browser path tracing and would never be able to render big models and small bright light sources, until I read a passage from Peter Shirley's Ray Tracing in One Weekend in which he casually mentions you can either do what the majority of programmers do, which is extra shadowRays, or you can just statistically send the original rays toward the light a little more often and down-weight them accordingly.  That one line changed my entire approach to all the demos, and that is how every demo is working now, especially the GLTF demos.  When I tried that alternate approach, the models all loaded just fine without crashing, no matter how large!  One of the tradeoffs though is getting the 'weight' variable to look good, which you noticed is an arbitrary number like 0.02.  My approach with this repo is too get things looking good and rendering fast in real time, not so much to be exactly physically correct (like energy conservation), so hence the 'magic' weight numbers.  For a more detailed analysis of how to down-weight sampled sunlight, see this website in particular the section entitled "Direct Lighting / Next Event Estimation", which nicely explains the probability factors like arc angular diameters, etc.  All I know is that the weight has to be a small number because empirically what are the odds of a random ray exactly hitting the small Sun disk, vs. the whole other part of the sky?
Now about the clouds, I had wanted to add some procedural clouds to my outdoor demos so they would poof into existence and then poof out of existence like you see on sped-up footage of the sky.  Although they look good, they are very costly vs. just using a skybox or static HDR sky dome.  Therefore, for reflected surfaces like mirrors and glass, I had to 'cheat' a little by rendering the whole sky upfront and then rendering the 'precomputed' clouds inside the mirror or glass.  In reality you would have to re-render the clouds from the mirror's point of view to see what was behind your head, but the frame rate tanked when I tried it the 'correct' way, too much GPU divergence.  So in summation, if you really want accurate reflections no matter the angle, we might consider adding support for HDR sky backgrounds for the GLTF viewer, (which is what most ray/path tracers do anyway) rather than trying to build real volumetric clouds one pixel at a time.  That being said, if you look into the glass of the house, it does look pretty convincing, some of the sky you can see through the window on more face-on angles (which models reality exactly with the 1.5 index of refraction slightly bending the transparency rays), and you'll also see some reflected sky and sun in the parts of the glass that get reflected (from more shallow viewing angles due to the Fresnel effect, like a still lake).
Let me know what your goals are for the sky stuff and we can work from there.  :-)

Ugh I feel like a dope, the epsIntersect wasn't even included in the code for the DIFF surface directLight branch!  The ray was getting nudged too far along the surface normal ('nl') from its origin, giving it too much of a head start, then of course it tunneled through walls and found the sun when it wasn't supposed too, lol!  When I added the eps, and turned back-face culling back on (which it really should be on all the time) the light leaking problem went away!  Here is the revised shader  This bug was driving me nuts, lol! ;-D

I'll read through your feedback after I'm back from work today.

As noted in commit message, using r.direction now for materials defined as REFR (so no refraction calculation), as tdir doesn't calculate the index of refraction correctly as shown in the two pictures below:
Just behind the glass window (1.0 ior of air):

Just in front of the glass window (1.5 ior of glass):

@n2k3
Whoa that's weird about the curvature through the flat glass in your renderings.  Could you tell me what the geometry is for the windows?  Is it one pane of glass (like a single quad, or 2 triangles making a single rectangle shape), or is it like in reality, having 2 panes of glass, with a little air in between the 2 panes? The reason I ask is that all my demos have only dealt with 1 glass/dielectric surface, like a perfect hollow glass sphere, or a perfect body of water, with no real mathematical 'thickness' to the dividing surface edge - you're either on the outside of the object, or you're on the inside.  Now this works great with traditional raytracing technique (using the tdir, which stands for transmitted ray direction, btw).  But it may be giving errors when trying to go through 2 really close surfaces that both have 1.5 IoR.  In reality the ray would need to be refracted going from air to glass, then glass to the thin sliver of air between the 2 glass panes, then refracted going from thin sliver of air to 2nd glass, then finally back to air again (that's a lot of bounces!).
Yeah I agree that supporting static HDR would be a nice feature, especially for model viewing apps. I will look into that - I know how to handle it geometrically, but I'm not sure how to extract the right amount of energy from different parts of the sky.  I believe HDR has some kind of encoding with luminosity raised to some power, and not just straight ahead RGB like a regular texture would have.
Other than these few minor issues, your model and demo look awesome!

Could you tell me what the geometry is for the windows? Is it one pane of glass (like a single quad, or 2 triangles making a single rectangle shape), or is it like in reality, having 2 panes of glass, with a little air in between the 2 panes?

The geometry consists of 12 triangles (so no quads) connected to 8 vertices per window. Where windows do not have multiple panes. Vertex normals are calculated by Three.js. The screenshot below displays two windows beside each other in wireframes viewed from an upper left angle.

I know how to handle it geometrically, but I'm not sure how to extract the right amount of energy from different parts of the sky. I believe HDR has some kind of encoding with luminosity raised to some power, and not just straight ahead RGB like a regular texture would have.

Your assumption is correct, although I couldn't tell you how to get to the specific value in technical terms. But I'm pretty sure you can figure it out, if you can write this awesome PathTracing shader :1st_place_medal:

@n2k3
Ahh thanks for the picture.  It looks to me like there is thickness to the glass, although pretty narrow.  Maybe not 2 panes, but a front face (+Z) and a back face (-Z) separated by 2 very thin triangles on each side (+Y, -Y, +X, -X) of the flattened box shape.  When the refracted ray is trying to go through the small "thickness" (+Z to -Z) of that box, maybe it is getting messed up somehow, or there could be machine precision issues with the epsilon offset for such a tight region of space.
I'll play around with some of the values, but in the end, we might just be keeping what you have, the r.direction instead of tdir.
I'll let you know when I can study up on the HDR stuff.  Yeah it shouldn't be too hard to find an online resource outlining how you extract the luminosity data from such a file.

@n2k3
Success!  I finally figured out how to load an equi-rectangular HDR image, ray trace it as a background, extract the luminosity data for direct sunlight sampling, and then apply three.js's various optional tonemapping routines to bring the hdr data (greater than 1.0) back into the 0.0-1.0 RGB range for viewing on a computer screen.  Here's the links to all the updated files:
html
js
shader
sample hdr
Be sure to place the sample hdr file inside the 'textures' folder in your project directory so the new loading code inside the GltfViewer.js file can find it.  You can play around with the exposure setting, also defined at the top of the GltfViewer.js file (maybe an Exposure setting could replace the SunDirection slider in the gui menu, since the SunDirection is set in the hdr image file and cannot be changed).
Speaking of sun direction, one issue with using hdr is that the sun direction of the file is unknown to the loader and path tracer.  I had to create a long red metal cylinder that extended to the sky just so I could visualize the angle at which to sample the direct sunlight inside the bounces loop of the path tracer.  Through trial an error I got the cylinder to 'touch' the sun spot on the large skydome and then used that normalized vec3 to use in the path tracer.  I only did 1 file so far, so if you change to something other than the symetrical-garden hdr, then just be aware that we have to re-find the sun direction.  Eventually, we could have a list of all the files that you like, and their respective sun directions commented out beside them, or something like that.
Still no luck with refractive tdir, I'm not sure what's going on with the warping - let's just keep what you have, it looks great.  By the way I got all the HDR files from here which does not require payment or licensing.  Feel free to tell me what background you want, which ones you like and don't like.  I don't have a preference, as long as there is a sun somewhere in the image.  :)

@n2k3
btw I put other HDR example files in this folder on my repo - there are a total of 5 to choose from.  Of course if you find another that you like on the internet, we can use that.  I just picked these because they were on a free website and they had some sun and clouds and mostly sky.  The perfect image would have mid-day sun, some white puffy clouds, and no ground, or minimal ground features, just sky. But I haven't found something like that as of yet.

Hey Erich,
I've updated the PR with your changes, on which you did another great job! This cleans up the shader quite well, and the result is as good. And now there are correct reflections :)
Check it here: https://n2k3.github.io/glTF_Viewer.html
I've chosen for the following HDR:
This one has some nice clouds in the sky but has no sun, this is fine for me. After thinking on this a bit, it seems I've incorrectly implemented the sun direction, as it's now getting the pixel based on the sun direction. While there is no sun at that position in the HDR image. I guess we could add another property to the menu that defines the color of the sun, instead of getting it from the HDR. But this might diminish the purpose of using an HDR.
The reason I added skyLight & sunLight intensity sliders is so that the user itself has more freedom over the lighting setup. If the user wants to have no direct sun light, it can be set to 0. The user can then increase the skyLight value to compensate and get a good result based on bounced light rays.
I decided to keep the sun angle property, to simulate a sun that generates shadows. This decision was based on the same reason as above, more freedom of the lighting setup.
Some comparison screenshots, previous version (dynamic sun/sky/clouds):

Updated version (HDR skybox):

A couple of things I noticed:

The previous version had way more blue in the parts that are in shadow. Compared to the updated version the difference is too big, the question is then, which one do you think better reflects reality? (Hmm, I now remember that I used a weight of 2.0 for any of light coming from the sky, so I guess this is part of the problem...)
I'm unsure if the light value retrieved from the HDR image is properly retrieved and/or applied. If you increase the hdrExposure value to 5, the skybox itself (when you look up) actually gets a lot brighter, but it feels as if the exposure value used for the PT has a lot less of an impact on the brightness of diffuse materials.

Let me know how you want to continue.

@n2k3
Hey everything is looking great!  Nice choice for the HDR image also, I like the puffy clouds!
About your 2 concerns,

Yes I believe the current result is following the behavior of real-world physical light correctly, even though it differs with respect to the amount of blue in the indirect illumination on the diffuse objects.  In the HDR you selected, if you look up and study the amount of clear sky, there is not much room - it's mostly white clouds.  Which is totally fine, but that will be the predominant color that is reflected on the house - white.  With my HDR choices and the old physical procedural sky, there is a much larger blue portion of the sky which is reflected in the objects below.

Let me take a look and review how I am getting the power (or energy) amount out of the sky when a random diffuse ray hits it.  At least on my machine, when I dial up the energy with the sun or the sky HDR, the house gets brighter as it should.  Hmm... I'm just thinking, I bet the tone-mapper is capping the energy output.  Now without it, the sky becomes unbearable because the colors overflow - it looks a little weird.  But maybe the choice of the various tone mapping styles affects the total amount of output.  I'll mess around with some things and report back.  If all else fails, we can manually dial up the 'weight' value in the shader.  That will definitely make things brighter. :)

Again, looks great, thanks!  I'll let you know what I find out.

Yep that was it - the Uncharted 2 tonemapper was limiting the power output (as it was designed to).  Try the Linear tonemapping option, then dial the sunlight intensity all the way down, and the sky all the way up.  The house will become washed out with white light - almost too much, but at least we know it's working.  :)
In the end, we may just want Linear tonemapping, because that allows the greatest range of light from dark (black) to over-saturated white.
As before, I have made some small changes to the shader.  Here is the new one:
shader
Let me know if you like being able to dial the light up and down that much.

Yea you're right, tone-mapped exposure is better. Fixed sun light not going through windows, taking into account the sunLightIntensity multiplier.
Check the updated result here: https://n2k3.github.io/glTF_Viewer.html
It wouldn't make sense why people would want over exposed images. And in that light (heh), would it possible to clamp the values of the skybox itself as well? I've tested multiplying the inverted hdrExposure value to the textData.rgb, this will render the skybox correctly, but keep reduces the amount of light in the scene as well...
One last problem I want to resolve before we can consider this PR complete. Using a non-default sun direction value (around 1.67) results in blue sky light. This seems to be related to Get_HDR_Color() which is getting a pixel's color based on the sun direction. But since the image is mostly white it 'works'.
To solve this: I guess we could add another property to the menu that defines the color of the sun, instead of getting it from the HDR. This would result in lighting being combined from the sun color and the HDR image. Would you agree?
One last thing I noticed when setting both sky & sun light intensity to 0, there is still light (and a rather cool effect):

This seems to be based on these two lines. Is this the intended behavior?

Hi @n2k3
I fixed that mysterious ghost light when all the lights are turned off.  I just forgot to add the skyLight multiplier.  Although the subtle light is cool, it was not really intended behavior, he he.
shader
Yes I agree that there should be a color picker for the sun color. It would be nice, for instance, to lower the sun to just above the horizon, and then choose a reddish orange color.  If you can somehow get a simple rainbow slider added in, I'll be glad to hook it up to the uSunLightIntensity variable in the shader.  It should work if we just multiply the vec3 Sun color choice times the uSunLightIntensity float.
The new tone mapping option you chose looks real nice.  Yeah I don't know why people would want to over-expose the HDR image - it seems to get washed out and unrealistic looking.  But just to be on the conservative side, we probably should leave the exposure slider in there.  :)

Hey @erichlof,
I've added the sun color as a property to the menu (and the hdr exposure is back too).
Check it out here: https://n2k3.github.io/glTF_Viewer.html
One last thing, I promise :)
Adding the skyLightIntensity multiplier fixes light going through refractive materials when both sun & sky intensity are 0, but this introduces the problem that when viewing through a refractive material, the hdr sky is multiplied as well. And I can't think of a way to separate the two situations... In other words: multiplying by skyLightIntensity to get rid of the phantom light through glass, but NOT multiplying when looking to the sky through refractive materials (see picture below).

Do you have any idea's on how to solve this?

@n2k3
Ahh yes I see the bug now too.  There's so many angles to think about in path tracing - I didn't see that one, ha ha.  Let me try a couple of things to hopefully fix it.  Will be back soon! :)
p.s. great job on adding the sun color and all the other gui controls - it's really shaping up nicely!

@n2k3
I'm back!  I think this covers all the situations :-D
shader

Neat, thanks for the help!
Go ahead an merge this :+1:
P.S. maybe for convenience you can do this for future PR's:
https://help.github.com/en/articles/committing-changes-to-a-pull-request-branch-created-from-a-fork

@n2k3
Everything looks great!  Merging...
Thanks for the 'committing changes to a fork' link - I was wondering if that was possible.  Even though I've been coding for many years, I'm still pretty much a newbie when it comes to GitHub, lol.   One of these days I need to go through the docs or watch a youtube tutorial on GitHub so I can at least get the basics down.  :)
Thanks for all your work on this PR!  In the coming days I'll create a link to your GLTF_Viewer on my README.md.  Yeah it would be nice to have a model picker, between helmet and duck for instance.  But that might call for a separate PR.  I would have to redo some of the shader code to load a different model/BVH on the fly while the demo is running at full speed.  It's possible, I just need to figure out the best/easiest way to get that functionality in, which might take more than a couple of days.
If you have any changes in the future just let me know, thanks!
-Erich


Usability request

Hi again :-)
I've been using your extension a lot today, and I've come to miss one thing:
Many of us (at least the dinosaurs) still recall most Object IDs. Obviously you also manage the different Object Names in most cases, but it isn't always so. I.e.: I'm working on WMS right now and the names are impossible to know by memory (all the different abbreviations, hyphens, dots, etc.). In fact they're so messy that even IntelliSense gets lost... (you can try that on Codeunit 7324 "Whse.-Activity-Post"... yuck!!)
To solve this, I've been jumping to the old Developer Environment just to copy the Object Name.
On your object list, if you click on an Object Name it opens the Object definition.
Do you think it would be possible to right-click just to copy the Object Name?

I have been working on several updates, kept this one in mind as well.
I am using a new grid component that allows text selection/editing by double-clicking or hitting Enter on a table cell. This feature is activated for "Name" column. So double-clicking on the name cell, except the link, should show you the selected text that can be copied with ctrl+c.
This is available in 0.0.7-alpha build


Update package constraints

Added support for Laravel 5.3 (which is just around the corner)
Added new recomended constraint syntax

I've also updated the Laravel support constraint since [Laravel doesn't follow SemVer. Also just a quick note: ~5.1 would cover both ~5.1 and ~5.2, please see the documentation.
Let me know what you think.

Awesome ... thank you!


Implementation of setLibraryList API

As this is this the most requested topic I get from clients, I thought it might be worth adding this API.
I have created and the API, tested it, added to the readme and added the documentation.
Let me know if there is anything else I should do.
Thanks!
Signed-off-by: Liam Allan<EMAIL_ADDRESS>

To this day it boggles my mind how this seemingly simple task escapes so many people.
Regardless, it seems to be something we should add if it will make things easier and discoverable for people.

The commits above cleaned up the PR and added test case for setLibraryList


Added missing openssh server package. Needed by vagrant up & vagrant ssh.

OpenSSH server is missing from Debian Jessie template.
As said in title, SSH is needed by vagrant up & vagrant ssh.
This patch adds openssh-server during extra packages installation.
Best regards,

Hey @glenux! I shot you an email about becoming a collaborator on this project but I'm not sure you got it.
Would you be interested on that? As per https://github.com/fgrehm/vagrant-lxc/issues/375 I haven't been using the plugin that much recently so I'm holding back on merging changes on both projects.
LMK if you are interested and so I can hook you up with write access here!

Thank you!


Add rtl support with dynamic right & left properties

This PR resolves this issue.
I've checked result of this PR with both RTL and LTR apps.
It works as expected in both situations.

LTR(default):

RTL:

Hi @RichardLitt ,
React Native Allegedly 😊 has support for end and start, you can find more info about it here.
But I'm currently working on a RTL app. And I know that this feature is not well implemented in react native. It simply doesn't work as expected.
So I defined my own start, end.
const rtl = I18nManager.isRTL;
const start = rtl ? 'right' : 'left';
const end = rtl ? 'left' : 'right';

So If I used end: leftOverlayRight, without brackets, React-native would have replaced end with It's own definition, BUT I want end to be strictly set as left in RTL apps.

We can refactor usage of [end] [start] in the future when React-Native resolved this issue. I'll keep  an eye for this. 😊

@iamsoorena Sorry for the delay on reviewing this. This looks really good! Thank you. I'm just curious if it is possible to programmatically switch the direction. For example, when changing the language within the app's settings (English -> Farsi -> English). I couldn't find any function for switching back to LTR on I18nManager. I18nManager.forceRTL(false) also does not seem to work.

This looks good to me. I would just like to know if the programmatic change of direction is a possibility. In that case, we would have to move the RTL check (Line 48-50) into the _animateMove method.

Seems that #82 includes these changes as well as the onPress thing. It would be better if the PRs only introduce one new feature or bug fix. But for now, we can just close this one, and follow up the rest in #82 and merge both functionalities at once.

@mohebifar First I think you mean #71.
Since I thought  #71 would be merged long time ago, I just worked on that branch to avoid conflicts in the future, But I don't have a problem with separating PRs.

@iamsoorena Thanks for letting us know, @iamsoorena. Sorry about the delay - we don't have unlimited time to work on this repository. :)

@RichardLitt no problem.

@iamsoorena Just wanted to follow up with you to see if you want still would like to:

Make the change to check the direction dynamically in the measurement code. (For example, for apps that support switching the language in the settings menu)
Keep out the changes available in this PR from #71 so that #71 will only contain changes related to the onPress functionality.
Thanks!

@mohebifar once again I'm sorry for my slow responds.
critically busy on a project.
I'll let you know ASAP.


Add CentOS 8 Vault RPMs to centos driverbuilder

Signed-off-by: David Windsor<EMAIL_ADDRESS>
What type of PR is this?

Uncomment one (or more) /kind <> lines:

/kind bug
Any specific area of the project related to this PR?

Uncomment one (or more) /area <> lines:

/area build
What this PR does / why we need it:
Some CentOS releases have been moved from Stream to Vault since the centos driverbuilder was created. This causes test-infra tests to fail when building CentOS 8.3, 8.2, and 8.1 kernels (8.4 kernels build successfully in test-infra):
utils/checkfiles config/3aa7a83bf7b9e6229a3824e3fd1f4452d1e95cb4/centos_4.18.0-240.10.1.el8_3.x86_64_1.yaml
INFO using config file                             file=config/3aa7a83bf7b9e6229a3824e3fd1f4452d1e95cb4/centos_4.18.0-240.10.1.el8_3.x86_64_1.yaml
INFO driver building, it will take a few seconds   processor=docker
FATA exiting                                       error="kernel not found"

For some reason, CentOS 8 releasees follow a different directory structure on vault.centos.org than any of the previous CentOS releases so special-case handling needs to be added to download these RPMs.
Which issue(s) this PR fixes:

Fixes #105
Special notes for your reviewer:
Does this PR introduce a user-facing change?:

NONE

LGTM label has been added.  Git tree hash: 91e51ea80fe35be02a35d4f5d3737d274105d1ff

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: dwindsor-scwx, leodido
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [leodido]

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


CPI ignores maintenance mode of datastore

The datastore accessibility is mentioned in https://github.com/cloudfoundry-incubator/bosh-vsphere-cpi-release/issues/29, but its not quite the same.
We have a range of datastores, at any point in time one or more could be in maintenance mode.  As it stands, the CPI falls over when it tries to create a disk inside a datastore that is in maintenance mode.
Within the datastore.rb file the object returned by Vim::Datastore + Datastore::PROPERTIES should return a 'summary.maintenanceMode' boolean.  It should be possible to check this value before determining if a datastore can be used.
My Ruby is quite poor, but I would imagine changing https://github.com/cloudfoundry-incubator/bosh-vsphere-cpi-release/blob/master/src/vsphere_cpi/lib/cloud/vsphere/resources/datastore.rb#L18
from:
ds_properties['summary.accessible'],

to:
ds_properties['summary.accessible'] &&  ! ds_properties['summary.maintenanceMode'],

would cause the datastore to be not selected and the CPI would be free to move to the next datastore for integration.

Fixed in version 46.


Action Lag issues

What issue do you have? Please be as thorough and explicit as possible.
There is a huge lag but everything is working, its aorund 10seconds?
Details of your setup.

Do you use Homebridge (with config-ui?) or HOOBS?
Latest

Which version of Homebridge/HOOBS do you have?
latest

Which version of this plugin (homebridge-ewelink) do you have? Has the issue started since upgrading from a previous version?
newest, upadated

Which eWeLink devices do you have that are causing issues? Please include product models if applicable.
Just normal smart sockets

Do you use your main eWeLink credentials or do you use a secondary eWeLink account for Homebridge?
main

Please paste any relevant logs below.
<!--
   It helps if you can turn on 'Debug Logging' and 'Request & Response Logging' in the plugin settings for more thorough logging.
   If you are posting an error then it is helpful for me to also see the previous few lines as this can show the cause of the error.
   Please enter the logs between the two ``` lines below so that the logs are formatted in a way which is easier to read

Hi @krakenx40
Out of interest, if you control devices through the Homebridge user interface, is there a lag?

@bwp91 Yes, there is lag through the hoobs interface, I have used this plugin for a very long time in the past it was perfect, never failed, super reponsive.

Could you turn on Debug Logging and Request & Response Logging via the plugin settings and paste some logs of when you control a device?

11/30/2020, 7:29:33 PM [eWeLink] LAN message sent. This text is yellow for clarity.
{
"apikey": "hidden",
"deviceid": "hidden",
"params": {
"switches": [
{
"switch": "off",
"outlet": 0
},
{
"switch": "off",
"outlet": 1
},
{
"switch": "off",
"outlet": 2
},
{
"switch": "off",
"outlet": 3
}
]
}
}
11/30/2020, 7:29:48 PM [eWeLink] [Study RGB] Reverting to web socket as socket hang up.
11/30/2020, 7:29:48 PM [eWeLink] WS message sent. This text is yellow for clarity.
{
"apikey": "hidden",
"deviceid": "hidden",
"params": {
"switches": [
{
"switch": "off",
"outlet": 0
},
{
"switch": "off",
"outlet": 1
},
{
"switch": "off",
"outlet": 2
},
{
"switch": "off",
"outlet": 3
}
]
},
"action": "update",
"sequence": "1606735788710",
"ts": 0,
"userAgent": "app"
}
11/30/2020, 7:29:48 PM [eWeLink] WS message received.
{
"deviceid": "hidden",
"params": {
"online": true,
"updateSource": "WS"
}
}
11/30/2020, 7:29:48 PM [eWeLink] [Study RGB] WS update received and will be refreshed.
11/30/2020, 7:29:48 PM [eWeLink] LAN message received.
{
"deviceid": "hidden",
"params": {
"switches": [
{
"switch": "off",
"outlet": 0
},
{
"switch": "off",
"outlet": 1
},
{
"switch": "off",
"outlet": 2
},
{
"switch": "off",
"outlet": 3
}
],
"updateSource": "LAN",
"online": true
}
}
11/30/2020, 7:29:48 PM [eWeLink] [Study RGB] LAN update received and will be refreshed.
11/30/2020, 7:29:52 PM [eWeLink] LAN message sent. This text is yellow for clarity.
{
"apikey": "hidden",
"deviceid": "hidden",
"params": {
"switches": [
{
"switch": "on",
"outlet": 0
},
{
"switch": "off",
"outlet": 1
},
{
"switch": "off",
"outlet": 2
},
{
"switch": "off",
"outlet": 3
}
]
}
}
11/30/2020, 7:29:57 PM [Pi Temp] Sending temp: 33.102
11/30/2020, 7:30:07 PM [eWeLink] [Study RGB] Reverting to web socket as socket hang up.
11/30/2020, 7:30:07 PM [eWeLink] WS message sent. This text is yellow for clarity.
{
"apikey": "hidden",
"deviceid": "hidden",
"params": {
"switches": [
{
"switch": "on",
"outlet": 0
},
{
"switch": "off",
"outlet": 1
},
{
"switch": "off",
"outlet": 2
},
{
"switch": "off",
"outlet": 3
}
]
},
"action": "update",
"sequence": "1606735807706",
"ts": 0,
"userAgent": "app"
}
11/30/2020, 7:30:07 PM [eWeLink] WS message received.
{
"deviceid": "hidden",
"params": {
"online": true,
"updateSource": "WS"
}
}
11/30/2020, 7:30:07 PM [eWeLink] [Study RGB] WS update received and will be refreshed.
11/30/2020, 7:30:07 PM [eWeLink] LAN message received.
{
"deviceid": "hidden",
"params": {
"switches": [
{
"switch": "on",
"outlet": 0
},
{
"switch": "off",
"outlet": 1
},
{
"switch": "off",
"outlet": 2
},
{
"switch": "off",
"outlet": 3
}
],
"updateSource": "LAN",
"online": true
}
}
11/30/2020, 7:30:07 PM [eWeLink] [Study RGB] LAN update received and will be refreshed.

The issue is that the plugin is trying to control to your devices over the LAN network but can’t quite connect to them. It waits the ~10 seconds before reverting to using the cloud. This explains the delay.
Solution:

Are your devices updated to the latest firmware?
Can you think of any other reason why the plugin can’t connect to your devices over LAN?
If not, then I can add an option to disable LAN mode skip the trying over LAN

@bwp91 I am not sure why, controling the devices from the ewelink app has instantaneous reponses, and never fails. Would resetting the app help? If not, could you please add the option? Thank you so much!

The ewelink app directly uses the cloud.
The plugin tries to use local control first, but then reverts to the cloud.
This is why there is a delay with the plugin.
I'll get back to you

@bwp91 is there anyway to make it use local control?

@krakenx40 This is why I asked if the devices are on the latest firmware?
The LAN control should be automatically on.
You can check this setting per device in the ewelink app, go to device settings and enable the option for "LAN control"

@bwp91 I dont see an option for that in the ewelink app

Which device (product model) is it?
And is it updated with the most recent firmware?

All my devices are smart plugs, yes updated to 3.3.2, the latest version

Yes but which brand/product models are they?

Ewelink mini smart sockets

I dont think there is a way to make it go LAN, can you make a option for it to go cloud control only?

Yes, could you upgrade to a beta version, v3.15.1-2, using this guide.
Let me know once you have done this.

Just tried it I got this error message

Did you stop the hoobs service first?

Yes I tried again, and it told me to also update my NPM (Using npm install -g npm), but I got this. The service is stopped. You got any idea how to run it ask root/admin?

So did you turn the “disable LAN mode” setting to true?

Yes, the LAN mode setting is good, but I am having a problem updating the npm of the hoobs itself, could you please help me with that?

Updating node will also update npm:
https://github.com/bwp91/homebridge-ewelink/wiki/How-to-update-node#hoobs

Thank you so much for your help

You’re welcome. Stay on the beta for now and when an official release of the plugin is available, it will show as an update in hoobs.

I have a new problem, I just restarted my hoobs and now there is no response to the server.
I tried sudo hoobs service log, and this is what is showing

The command on my wiki page for updating node on HOOBS is directly from hoobs support, so should have worked.
Looks like someone else found a solution to a similar error on this comment, but your safest bet would be to get in contact with hoobs support.
I'm hesitant to suggest anything else in case it makes things worse

or here:
https://github.com/hoobs-org/HOOBS/issues/914

Thank you for your help again!

You're welcome. I'll close this as I assume from the plugin perspective it's working again!

Hi, I just updated my plugin, and I am having the same problem again, could you please consider adding it as an option to add it into the next update?

Hi, I just updated my plugin, and I am having the same problem again, could you please consider adding it as an option to add it into the next update?

@bwp91 Is it possible for me to revert back to the  v3.15.1-2 beta, since that was working very well for me? I dont see a restore buttonn since im on hoobs :(

@bwp91 Is it possible for me to revert back to the  v3.15.1-2 beta, since that was working very well for me? I dont see a restore buttonn since im on hoobs :(

Hi @krakenx40
Please can you paste the ewelink part of your hoobs config? Remove your username and password of course! There have been a few config changes recently and just want to make sure you're up-to-date as this may be why you are experiencing the lag again.

Hi @krakenx40
Please can you paste the ewelink part of your hoobs config? Remove your username and password of course! There have been a few config changes recently and just want to make sure you're up-to-date as this may be why you are experiencing the lag again.

Of course! Here it is
{
"platform": "eWeLink",
"plugin_map": {
"plugin_name": "homebridge-ewelink-max"
},
"name": "eWeLink",
"debug": false,
"debugReqRes": false,
"disableHTTPRefresh": false,
"disablePlugin": false,
"inUsePowerThreshold": 0,
"lowBattThreshold": 25,
"sensorTimeDifference": 0,
"hideZBLDPress": false,
"countryCode": "86",
"username": "XXXXXXXX",
"password": "XXXXXXXXXXXXX",
"disableLANMode": true
},

Of course! Here it is
{
"platform": "eWeLink",
"plugin_map": {
"plugin_name": "homebridge-ewelink-max"
},
"name": "eWeLink",
"debug": false,
"debugReqRes": false,
"disableHTTPRefresh": false,
"disablePlugin": false,
"inUsePowerThreshold": 0,
"lowBattThreshold": 25,
"sensorTimeDifference": 0,
"hideZBLDPress": false,
"countryCode": "86",
"username": "XXXXXXXX",
"password": "XXXXXXXXXXXXX",
"disableLANMode": true
},

You can strip this down to:
   {
      "platform": "eWeLink",
      "plugin_map": {
      "plugin_name": "homebridge-ewelink-max"
   },
   "name": "eWeLink",
   "countryCode": "86",
   "username": "XXXXXXXX",
   "password": "XXXXXXXXXXXXX",
   "mode": "wan"
},

The plugin_name should be homebridge-ewelink, but I'm hesitant to change it if it's working already.
The last option I have added, "mode": "wan", should stop the lagging again.

You can strip this down to:
   {
      "platform": "eWeLink",
      "plugin_map": {
      "plugin_name": "homebridge-ewelink-max"
   },
   "name": "eWeLink",
   "countryCode": "86",
   "username": "XXXXXXXX",
   "password": "XXXXXXXXXXXXX",
   "mode": "wan"
},

The plugin_name should be homebridge-ewelink, but I'm hesitant to change it if it's working already.
The last option I have added, "mode": "wan", should stop the lagging again.

I just tried it, but there is still a lag.

I just tried it, but there is still a lag.

Yes it working agian, Thank you so much!

Yes it working agian, Thank you so much!

Fab. I’ll close this issue again!

Fab. I’ll close this issue again!


Added bumped versions and also a Tempry fix of excluding guava is added

What is this fix !!!
**/repository/components/plugins/com.google.guava_15.0.0.jar
looks wrong for me


:seedling: Remove the dependency of core.kcp.io/v1alpha1/logicalclusters from Syncer

Summary
This is the PR for #874.
What's the changed

Remove the dependency of kcp logical cluster function from Syncer

I reviewed Syncer code whether Syncer really depends on logical cluster id or not and concluded it's not required. I have removed the dependent codes on the logical cluster stuff from Syncer. As a result, Syncer does no longer require --from-cluster option.
Verification
UT passed
$ make test-syncer COUNT=1
go test -count 1 `go list ./... | grep "/pkg/cliplugins\|/pkg/syncer"`
?       github.com/kubestellar/kubestellar/pkg/syncer   [no test files]
?       github.com/kubestellar/kubestellar/pkg/syncer/clientfactory     [no test files]
?       github.com/kubestellar/kubestellar/pkg/syncer/shared    [no test files]
?       github.com/kubestellar/kubestellar/pkg/syncer/syncers   [no test files]
ok      github.com/kubestellar/kubestellar/pkg/cliplugins/kubestellar/syncer-gen        0.952s
ok      github.com/kubestellar/kubestellar/pkg/syncer/controller        18.689s

E2E passed
$ make e2e-test-kubestellar-syncer
rm -rf /Users/yana/git/trl/kcp/kcp-edge-mc/.kcp/etcd-server
rm -rf /Users/yana/git/trl/kcp/kcp-edge-mc/.kcp/.admin-token-store /Users/yana/git/trl/kcp/kcp-edge-mc/.kcp/admin.kubeconfig
rm -rf /Users/yana/git/trl/kcp/kcp-edge-mc/.kcp/apiserver.* /Users/yana/git/trl/kcp/kcp-edge-mc/.kcp/sa.key
export PATH=/Users/yana/git/trl/kcp/kcp-edge-mc/kcp/bin:$PATH && \
        kcp start --root-directory=/Users/yana/git/trl/kcp/kcp-edge-mc/.kcp > /Users/yana/git/trl/kcp/kcp-edge-mc/.kcp/kcp.log 2>&1 & PID=$! && echo "PID $PID" && \
        trap 'kill -TERM $PID' TERM INT EXIT && \
        while [ ! -f "/Users/yana/git/trl/kcp/kcp-edge-mc/.kcp/admin.kubeconfig" ]; do sleep 1; echo "kcp is not ready. wait for 1s...";done && \
        echo 'Starting test(s)' && \
        NO_GORUN=1 GOOS=darwin GOARCH=arm64 \
                go test -race  ./test/e2e/kubestellar-syncer/...  \
                --kcp-kubeconfig /Users/yana/git/trl/kcp/kcp-edge-mc/.kcp/admin.kubeconfig --suites kubestellar-syncer \

PID 6248
kcp is not ready. wait for 1s...
kcp is not ready. wait for 1s...
kcp is not ready. wait for 1s...
Starting test(s)
ok      github.com/kubestellar/kubestellar/test/e2e/kubestellar-syncer  258.144s

I also verified that a manual test (example1.md) passed with the Syncer image built by this branch
Related issue(s)
Fixes #874

/cc @fileppb

This PR in its current form breaks the example1 test.  That is because this PR both: (1) changes the syncer from requiring the --from-cluster command line argument to forbidding it, and (2) changes the kubectl kubestellar syncer-gen plugin from putting that command line flag in the generated PodSpec for the syncer to omitting that flag.  But this PR does not change the kubectl kubestellar prep-for-syncer plugin to default to a syncer image built from (the effects of) this PR.  So a test fails because the old syncer image is used and it just crashes due to the missing command line flag.
To fix I suggest either (A) update kubectl-kubestellar-prep_for_syncer to specify quay.io/kubestellar/syncer:test-999 (which I built from this PR) as the default syncer image, as a temporary expedient (after this merges we should build a new syncer image from main and update the prep-for-syncer plugin to default to that one) or (B) break this PR into two, with the first one making the syncer allow but not require the --from-cluster command line flag.

Thanks for the investigation. I didn't notice that removing this option was breaking the backward compatibility. To keep the compatibility, the suggestion (B) might be safer for those who use syncer-gen plugin with older Syncer images. I added another commit that syncer-gen adds --from-cluster option with a dummy value.

Maybe, syncer-gen plugin has to keep --from-cluster option permanently for those who use older version of Syncer (kubectl kubestellar syncer-gen  --syncer-image <older version of Syncer>).

The added commit bfe7371912ccc4acfa685d87883d5fa0802794dd does not take the approach I labeled "B".  This PR now passes testing with the example1 docs-ecutable but still requires a coordinated change in the future: anyone running the new syncer code will also have to run revised syncer-gen code that omits the --from-cluster flag.  The way to enable incremental transition is as follows.

The first PR that merges makes the --from-cluster optional on the syncer command line, and does not change the syncer-gen code from what is currently merged (i.e., syncer-gen continues to emit --from-cluster).
After that merges we can build a syncer image from main and start using that.  We can change prep-for-syncer to default to the new syncer image.
At that same time or later, we change syncer-gen to not emit the --from-cluster flag.

I got it. The phasing approach is needed. I am concerning the last step.

At that same time or later, we change syncer-gen to not emit the --from-cluster flag.

If syncer-gen stops emitting --from-cluster flag, syncer image that's equal or less than v0.7.0 won't be supported.
How about adding a logic that if specified image version in --syncer-image <= v0.7.0, syncer-gen emits --from-cluster in generated yaml while if the version > v0.7.0, syncer-gen doesn't emit the flag?
Or, simply syncer-gen returns an error if a user specifies --syncer-image with the version <= v0.7.0

I think that is more complicated than necessary.  We do not really have a use case for very uncoordinated usage.  In fact, I think my previous remark was more demanding than necessary.  The current state of this PR is good enough.  It passes tests.  After it merges we can build a new syncer image from main.  Then in just one more PR we can change syncer-gen to omit the --from-cluster flag and change prep-for-syncer to default to using the new syncer image.

/lgtm
/approve

I think that is more complicated than necessary

Yes, I agree with it. I feel that is too much.


rollRange under certain circumstances very likely to return the same result

The default java.util.Random handles calls to nextInt(x) where x is a power of two specially.
In Indigo, this leads to the fact that when you do dice.rollRange(1, 4) at the start of every FrameTick, you are overwhelmingly likely to get the same number as before.
Possible workaround: call rollRange(1, 4)  (or with any other number) and discard the first return value. Successive calls seem to yield more random values.

@felher, @hobnob has a PR open against this, if you're interested. I don't believe he managed to replicate the issue:
https://github.com/PurpleKingdomGames/indigo/pull/770
I wonder if it's a difference in random behaviour due to the difference in platform? Or was something missed?

I wonder if it's a difference in random behaviour due to the difference in platform? Or was something missed?

The problem might be fixed (I didn't test it) but I think you did miss something,
The issue is not on the distribution of random values (e.g. calling dice.rollRange(1, 4) multiple times) but on the distribution of the first random value (e.g. calling Dice.diceSidesN(4, scala.util.Random.nextLong()).rollRange(1, 4) multiple times)

@davesmith00000 @hobnob
wow, cool, thanks for your work!
I'm not completely sure whether that fixes the issue. @JD557 is right that consecutive random numbers from the same generator should work, but it seems that every frame creates the RNG anew, and the first random number from a dice with 4 sides seems to be highly correlated to the next first random number.
How should I best test the fix? Checkout the repo, publishLocal and test against that? Or is there a snapshot published?
I did dig around a bit and found an old test of mine: https://scribble.ninja/u/felher/cmbyvskqdvghhlgeecbuzibjpug
The first line tells you the number of times the first random number for a frame tick was equal to first number of the last frame tick. The second line tells how many times the second number was equal to the first in the same frame tick. The second number is at 25%, which seems correct given a 4-sided dice. The first number is 90%, though.

How should I best test the fix? Checkout the repo, publishLocal and test against that?

Yup, that's how you would test this fix :slightly_smiling_face:

The issue is not on the distribution of random values (e.g. calling dice.rollRange(1, 4) multiple times) but on the distribution of the first random value (e.g. calling Dice.diceSidesN(4, scala.util.Random.nextLong()).rollRange(1, 4) multiple times)

I wonder if it's worth checking the seed you're passing here.. each time you call Dice.diceSidesN(4, scala.util.Random.nextLong()) you're creating a new dice with a new seed. But actually you would be better off creating a single dice this way (or using another semi-random seed) and then rolling it multiple times

@JD557 I've just updated my unit tests to test the distribution of Dice.diceSidesN(4, scala.util.Random.nextLong()).rollRange(1, 4) and can confirm that this returns a uniform distribution of numbers each time, even when called multiple times

Of course - that doesn't address the over-weighting of the same number each frame, but I'm hoping the fix in #770 will do that :crossed_fingers:

Hi All,
We're going to merge the PR against this soon, because it will fix the problem. However, it moves the behaviour of the engine slightly away from the way it's supposed to work. @hobnob and I have discussed this at great length!
That being the case, it's very likely that Dice will change again when I look to introduce the notion of 'services': https://github.com/PurpleKingdomGames/indigo/issues/783

As per my previous comment:
This PR deprecates FrameContext in favour of a new Context type, that splits up long lived side effecting processes from frame-to-frame data / tools that are meant to be referentially transparent.
As part of that work, random values will now be available in two ways:
// As previously, Dice instances are created per frame and seeded on the running time, but Dice is now backed by the super simple but good enough (I hope) Xorshift algorithm.
ctx.frame.dice.roll

// References a long running (~whole game) scala.util.Random instance with a non-zero initial seed.
ctx.services.random.nextInt


llama facotry example运行时报错binascii.Error，有时候又能执行成功，是什么原因？

Reminder

[X] I have read the README and searched the existing issues.

System Info
运行有时会失败
CUDA_VISIBLE_DEVICES=0,1 NNODES=2 RANK=0 MASTER_ADDR=<IP_ADDRESS> MASTER_PORT=29500 llamafactory-cli train /home/jq/LLaMA-Factory/examples/train_full/llama3_chinse_full_sft.yaml
[2024-06-17 06:18:58,071] [INFO] [real_accelerator.py:203:get_accelerator] Setting ds_accelerator to cuda (auto detect)
[WARNING]  async_io requires the dev libaio .so object and headers but these were not found.
[WARNING]  async_io: please install the libaio-dev package with apt
[WARNING]  If libaio is already installed (perhaps from source), try setting the CFLAGS and LDFLAGS environment variables to where it can be found.
[WARNING]  Please specify the CUTLASS repo directory as environment variable $CUTLASS_PATH
[WARNING]  sparse_attn requires a torch version >= 1.5 and < 2.0 but detected 2.3
[WARNING]  using untested triton version (2.3.0), only 1.0.0 is known to be compatible
06/17/2024 06:19:00 - INFO - llamafactory.cli - Initializing distributed tasks at: <IP_ADDRESS>:29500
W0617 06:19:02.222000<PHONE_NUMBER>30816 torch/distributed/run.py:757]
W0617 06:19:02.222000<PHONE_NUMBER>30816 torch/distributed/run.py:757] *****************************************
W0617 06:19:02.222000<PHONE_NUMBER>30816 torch/distributed/run.py:757] Setting OMP_NUM_THREADS environment variable for each process to be 1 in default, to avoid your system being overloaded, please further tune the variable for optimal performance in your application as needed.
W0617 06:19:02.222000<PHONE_NUMBER>30816 torch/distributed/run.py:757] *****************************************
[2024-06-17 06:19:07,666] [INFO] [real_accelerator.py:203:get_accelerator] Setting ds_accelerator to cuda (auto detect)
[2024-06-17 06:19:07,692] [INFO] [real_accelerator.py:203:get_accelerator] Setting ds_accelerator to cuda (auto detect)
[WARNING]  async_io requires the dev libaio .so object and headers but these were not found.
[WARNING]  async_io requires the dev libaio .so object and headers but these were not found.
[WARNING]  async_io: please install the libaio-dev package with apt
[WARNING]  If libaio is already installed (perhaps from source), try setting the CFLAGS and LDFLAGS environment variables to where it can be found.
[WARNING]  Please specify the CUTLASS repo directory as environment variable $CUTLASS_PATH
[WARNING]  sparse_attn requires a torch version >= 1.5 and < 2.0 but detected 2.3
[WARNING]  using untested triton version (2.3.0), only 1.0.0 is known to be compatible
[WARNING]  async_io: please install the libaio-dev package with apt
[WARNING]  If libaio is already installed (perhaps from source), try setting the CFLAGS and LDFLAGS environment variables to where it can be found.
[WARNING]  Please specify the CUTLASS repo directory as environment variable $CUTLASS_PATH
[WARNING]  sparse_attn requires a torch version >= 1.5 and < 2.0 but detected 2.3
[WARNING]  using untested triton version (2.3.0), only 1.0.0 is known to be compatible
[2024-06-17 06:19:10,339] [INFO] [comm.py:637:init_distributed] cdb=None
[2024-06-17 06:19:10,339] [INFO] [comm.py:668:init_distributed] Initializing TorchBackend in DeepSpeed with backend nccl
[2024-06-17 06:19:10,350] [INFO] [comm.py:637:init_distributed] cdb=None
[rank0]: Traceback (most recent call last):
[rank0]:   File "/usr/local/lib/python3.10/dist-packages/accelerate/utils/deepspeed.py", line 51, in init
[rank0]:     config_decoded = base64.urlsafe_b64decode(config_file_or_dict).decode("utf-8")
[rank0]:   File "/usr/lib/python3.10/base64.py", line 133, in urlsafe_b64decode
[rank0]:     return b64decode(s)
[rank0]:   File "/usr/lib/python3.10/base64.py", line 87, in b64decode
[rank0]:     return binascii.a2b_base64(s)
[rank0]: binascii.Error: Incorrect padding
Reproduction
数据集是identity,alpaca_en_demo,
cat LLaMA-Factory/examples/train_full/llama3_chinse_full_sft.yaml
model
#model_name_or_path: meta-llama/Meta-Llama-3-8B-Instruct
model_name_or_path: /home/jq/model/llama3/
method
stage: sft
do_train: true
finetuning_type: full
ddp
ddp_timeout: 180000000
deepspeed: examples/deepspeed/ds_z3_config.json
dataset
dataset: identity,alpaca_en_demo
template: llama3
cutoff_len: 1024
max_samples: 1000
overwrite_cache: true
preprocessing_num_workers: 16
output
output_dir: saves/llama3-8b/full/sft
logging_steps: 10
save_steps: 500
plot_loss: true
overwrite_output_dir: true
train
per_device_train_batch_size: 1
gradient_accumulation_steps: 2
learning_rate: 1.0e-4
num_train_epochs: 3.0
lr_scheduler_type: cosine
warmup_ratio: 0.1
fp16: true
eval
val_size: 0.1
per_device_eval_batch_size: 1
eval_strategy: steps
eval_steps: 500
root@ubuntu3:/home/jq#
Expected behavior
No response
Others
No response

同样的问题

请问你解决了吗@ituantuan

解决了！应该是工作路径不对，你可以把执行命令时候的根目录切换成LLaMA-Factory，或者在你的yaml配置文件里面把deepspeed的json从相对路径改成绝对路径就好了！


[BUG] Website looks odd on small screen devices.

Description
Problem: The site looks fine on medium to large screen devices, but looks odd on small screen devices. Which becomes irritating for users who are using it on mobile.
Solution: We can fix it by adding some media queries and adjusting width and height of some element.
I want to work on this, can you assign it to me?
Screenshots

It's great having you contribute to this project by creating an issue Make sure you are assigned to this before you work on it and you read the Contributing.md file, Thank you! Welcome to the community :nerd_face:

Sure

Sure

BTW, would you mind if I create PR regarding this on 1st october?

Create now, I will merge then, what makes your pr count is what i add to your pr and if i merge it in october

Oh, actually it's my first time for participating in hacktoberfest.
So didn't knew about that, thanks for telling.
Will create the PR soon.

it's also my first

it's also my first

That's great!

It's great having you contribute to this project by creating an issue
Make sure you are assigned to this before you work on it and you read the Contributing.md file, Thank you! Welcome to the community

I'm not sure if this issue have been resolved but can you assign me to this?

:tada: This issue has been resolved in version 2.1.3 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


⚠ BeyondHD has degraded performance

In fab3520, BeyondHD ($BHD) experienced degraded performance:

HTTP code: 200
Response time: 1989 ms

Resolved: BeyondHD performance has improved in ce4cce2 after 6 minutes.


[VS Code] Starting collaboration session: Could not connect to the server. Live Share requires openssl 1.0 for authentication, please verify you have the dependency installed.

LiveShareLogs.zip

Error:
Starting collaboration session: Could not connect to the server. Live Share requires openssl 1.0 for authentication, please verify you have the dependency installed.
Steps to Reproduce:

Install VSCode on ParrotSec OS
Manually install Dotnet core
Install Live Share extension
Attempt to start the session.

apt-cache policy openssl
openssl:
Installed: 1.1.1b-2
Candidate: 1.1.1b-2
Version table:
*** 1.1.1b-2 1001
1001 https://deb.parrotsec.org/parrot parrot/main amd64 Packages
100 /var/lib/dpkg/status

Version Data

extensionName
VSLS

extensionVersion
1.0.125

protocolVersion
2.2

applicationName
VSCode

applicationVersion
1.33.1

platformName
Linux

platformVersion
4.19.0-parrot4-28t-amd64

Adding @Priya91 .

dupe #2030

LiveShare version 1.0.181 was just released to the marketplace and contains a fix for this issue.


crash about markdown env.containingImages

VS Code Version: 1.53
OS Version: all

Steps to Reproduce:

vsocde markdown feature recently (1.53) add a lazy load image feature(?) by contributing a new plugin to markdwon-it
the plugin requires env.containingImages, which is initialized in preview feature
when I call markdownit.render other places without env.containingImages, it crashes

that's why this issue happens: https://github.com/qjebbs/vscode-markdown-extended/issues/98
and I temporarily fix it with: https://github.com/qjebbs/vscode-markdown-extended/commit/e68b60a1e08cb5602e7a7a6705e91d8094ea9fb5
But it's not elegant, could you pls add one line to initialize it?
// e.renderer.rules.image=(e,n,r,i,o)=>{const s=e[n];s.attrJoin("class","loading");const l=s.attrGet("src");if(l){i.containingImages.push({src:l});const e=a.hash(l);s.attrSet("id","image-hash-"+e)}return t?t(e,n,r,i,o):o.renderToken(e,n,r,i,o)}
e.renderer.rules.image = (e, n, r, i, o) => {
    const s = e[n];
    s.attrJoin("class", "loading");
    const l = s.attrGet("src");
    if (l) {
        // add this line
        if(!i.containingImages) i.containingImages=[];
        i.containingImages.push({
            src: l
        });
        const e = a.hash(l);
        s.attrSet("id", "image-hash-" + e)
    }
    return t ? t(e, n, r, i, o) : o.renderToken(e, n, r, i, o)
}

Is this a duplicate of #116987?

Yeah, it's the same issue - should be fixed by my most recent PR #117041

Thanks. Please test the next insiders build and let me know if the issue has not been fixed


Invoke Web Assembly-specific dependencies when building for Wasm.

The purpose of the  proposed change is to allow MatCAT to be compiled to Web Assembly without modification.
This isn't compiling yet. Changes may be necessary before it can be merged.
On my system, at least, compiling dependencies that include C code fails, as Clang can't find the Standard C library (specifically, a file not found error is returned when opening stdlib.h).
The command line was:
cargo build --target wasm32-unknown-unknown

Sorry -- missed this PR for some reason.
A prior commit changed the zip compression algorithm to avoid the need to use Clang. Between that and publishing MathCAT, I believe MathCATDemo should build MathCAT without a problem now.
@jasonjgw: is your proposed change still useful?

I wasn't able to complete the compilation process for WebAssembly even with this change, but that was prior to the revision you mentioned regarding zip compression.
If it builds for WebAssembly without modification, then I'd leave this change out for the moment and close the pull request, but if you think it would be better to include those dependencies conditionally (in WebAssembly only) for the future then the approach taken is this PR could be a good starting point.


Could not spend spendable outputs panic

This is probably related to a channel closure that I did on this wallet.
INFO mutiny-core/src/logging.rs:27
2023-04-27 20:57:04.786 INFO  [mutiny_core::esplora:220] Starting transaction sync.
<EMAIL_ADDRESS>DEBUG mutiny-core/src/logging.rs:26
2023-04-27 20:57:05.438 DEBUG [lightning::chain::chainmonitor:612] New best block<PHONE_NUMBER>f1840b4559ce14ca2ef491e0a734e14b30a852f5de406b237e9217 at height 36878 provided via best_block_updated
<EMAIL_ADDRESS>DEBUG mutiny-core/src/logging.rs:26
2023-04-27 20:57:05.439 DEBUG [lightning::chain::onchaintx:707] Updating claims view at height 36878 with 0 claim requests
<EMAIL_ADDRESS>DEBUG mutiny-core/src/logging.rs:26
2023-04-27 20:57:05.439 DEBUG [lightning::chain::onchaintx:820] Updating claims view at height 36878 with 0 matched transactions in block 36878
<EMAIL_ADDRESS>DEBUG mutiny-core/src/logging.rs:26
2023-04-27 20:57:05.439 DEBUG [lightning::chain::channelmonitor:3244] Descriptor StaticOutput 532ff37cb6c3cb28b5f3ec5f96a0373c1765ab757a7343a40737cd5f50186110:0 marked for spending has got enough confirmations to be passed upstream
<EMAIL_ADDRESS>DEBUG mutiny-core/src/logging.rs:26
2023-04-27 20:57:05.440 DEBUG [lightning::chain::onchaintx:707] Updating claims view at height 36878 with 0 claim requests
<EMAIL_ADDRESS>DEBUG mutiny-core/src/logging.rs:26
2023-04-27 20:57:05.440 DEBUG [lightning::chain::onchaintx:820] Updating claims view at height 36878 with 0 matched transactions in block 36878
<EMAIL_ADDRESS>DEBUG mutiny-core/src/logging.rs:26
2023-04-27 20:57:05.442 DEBUG [event:0] EVENT: SpendableOutputs processing
<EMAIL_ADDRESS>panicked at 'could not spend spendable outputs: ()', /data/Dev/Mutiny/mutiny-node/mutiny-core/src/event.rs:527:22

Stack:

getImports/imports.wbg.__wbg_new_abda76e883ba8a5f/<@http://localhost:3420/@fs/data/Dev/Mutiny/mutiny-node/mutiny-wasm/pkg/mutiny_wasm.js:2129:21
logError@http://localhost:3420/@fs/data/Dev/Mutiny/mutiny-node/mutiny-wasm/pkg/mutiny_wasm.js:232:18
getImports/imports.wbg.__wbg_new_abda76e883ba8a5f@http://localhost:3420/@fs/data/Dev/Mutiny/mutiny-node/mutiny-wasm/pkg/mutiny_wasm.js:2128:66
console_error_panic_hook::Error::new::h41a97964ab0b8763@http://localhost:3420/@fs/data/Dev/Mutiny/mutiny-node/mutiny-wasm/pkg/mutiny_wasm_bg.wasm:wasm-function[56016]:0x1bd0b0e
console_error_panic_hook::hook_impl::hccf120d22d6ba64c@http://localhost:3420/@fs/data/Dev/Mutiny/mutiny-node/mutiny-wasm/pkg/mutiny_wasm_bg.wasm:wasm-function[14472]:0x1553158
console_error_panic_hook::hook::headc4e1f35397d32<EMAIL_ADDRESS><EMAIL_ADDRESS>Uncaught (in promise) RuntimeError: unreachable executed
<EMAIL_ADDRESS>panicked at 'already borrowed: BorrowMutError', /home/dev/.cargo/registry/src/index.crates.io-6f17d22bba15001f/wasm-bindgen-futures-0.4.33/src/task/singlethread.rs:85:37

Stack:

getImports/imports.wbg.__wbg_new_abda76e883ba8a5f/<@http://localhost:3420/@fs/data/Dev/Mutiny/mutiny-node/mutiny-wasm/pkg/mutiny_wasm.js:2129:21
logError@http://localhost:3420/@fs/data/Dev/Mutiny/mutiny-node/mutiny-wasm/pkg/mutiny_wasm.js:232:18
getImports/imports.wbg.__wbg_new_abda76e883ba8a5f@http://localhost:3420/@fs/data/Dev/Mutiny/mutiny-node/mutiny-wasm/pkg/mutiny_wasm.js:2128:66
console_error_panic_hook::Error::new::h41a97964ab0b8763@http://localhost:3420/@fs/data/Dev/Mutiny/mutiny-node/mutiny-wasm/pkg/mutiny_wasm_bg.wasm:wasm-function[56016]:0x1bd0b0e
console_error_panic_hook::hook_impl::hccf120d22d6ba64c@http://localhost:3420/@fs/data/Dev/Mutiny/mutiny-node/mutiny-wasm/pkg/mutiny_wasm_bg.wasm:wasm-function[14472]:0x1553158
console_error_panic_hook::hook::headc4e1f35397d32@http://localhost:3420/@fs/dat…
<EMAIL_ADDRESS>Uncaught (in promise) RuntimeError: unreachable executed
<EMAIL_ADDRESS>INFO mutiny-core/src/logging.rs:27
2023-04-27 20:57:05.535 INFO  [mutiny_core::esplora:316] Finished transaction sync.

Afterwards, here's a few logs that might be relevant. It does seem like I did get all the funds on chain, so perhaps not a big worry as far as the funds go.
INFO mutiny-core/src/logging.rs:27
2023-04-27 20:58:04.908 INFO  [mutiny_core::esplora:220] Starting transaction sync.
<EMAIL_ADDRESS>DEBUG mutiny-core/src/logging.rs:26
2023-04-27 20:58:05.346 DEBUG [lightning::chain::chainmonitor:612] New best block 000001a5755469dd348a12d71f2f4a1eec11f08dcf32633f872dcf4036b8db92 at height 36879 provided via best_block_updated
<EMAIL_ADDRESS>DEBUG mutiny-core/src/logging.rs:26
2023-04-27 20:58:05.347 DEBUG [lightning::chain::onchaintx:707] Updating claims view at height 36879 with 0 claim requests
<EMAIL_ADDRESS>DEBUG mutiny-core/src/logging.rs:26
2023-04-27 20:58:05.348 DEBUG [lightning::chain::onchaintx:820] Updating claims view at height 36879 with 0 matched transactions in block 36879
<EMAIL_ADDRESS>DEBUG mutiny-core/src/logging.rs:26
2023-04-27 20:58:05.349 DEBUG [lightning::chain::onchaintx:707] Updating claims view at height 36879 with 0 claim requests
<EMAIL_ADDRESS>DEBUG mutiny-core/src/logging.rs:26
2023-04-27 20:58:05.349 DEBUG [lightning::chain::onchaintx:820] Updating claims view at height 36879 with 0 matched transactions in block 36879
<EMAIL_ADDRESS>INFO mutiny-core/src/logging.rs:27
2023-04-27 20:58:05.431 INFO  [mutiny_core::esplora:316] Finished transaction sync.

INFO mutiny-core/src/logging.rs:27
2023-04-27 20:59:04.738 INFO  [mutiny_core::esplora:220] Starting transaction sync.
<EMAIL_ADDRESS>DEBUG mutiny-core/src/logging.rs:26
2023-04-27 20:59:05.214 DEBUG [lightning::chain::chainmonitor:612] New best block 0000009a7c28c28ac3292d063870ff68bbb051771559303a657e7f5bbcbb9c3d at height 36881 provided via best_block_updated
<EMAIL_ADDRESS>DEBUG mutiny-core/src/logging.rs:26
2023-04-27 20:59:05.214 DEBUG [lightning::chain::onchaintx:707] Updating claims view at height 36881 with 0 claim requests
<EMAIL_ADDRESS>DEBUG mutiny-core/src/logging.rs:26
2023-04-27 20:59:05.214 DEBUG [lightning::chain::onchaintx:820] Updating claims view at height 36881 with 0 matched transactions in block 36881
<EMAIL_ADDRESS>DEBUG mutiny-core/src/logging.rs:26
2023-04-27 20:59:05.216 DEBUG [lightning::chain::onchaintx:707] Updating claims view at height 36881 with 0 claim requests
<EMAIL_ADDRESS>DEBUG mutiny-core/src/logging.rs:26
2023-04-27 20:59:05.216 DEBUG [lightning::chain::onchaintx:820] Updating claims view at height 36881 with 0 matched transactions in block 36881
<EMAIL_ADDRESS>INFO mutiny-core/src/logging.rs:27
2023-04-27 20:59:05.309 INFO  [mutiny_core::esplora:316] Finished transaction sync.

INFO mutiny-core/src/logging.rs:27
2023-04-27 21:00:04.922 INFO  [mutiny_core::esplora:220] Starting transaction sync.
<EMAIL_ADDRESS>DEBUG mutiny-core/src/logging.rs:26
2023-04-27 21:00:05.291 DEBUG [lightning::chain::chainmonitor:612] New best block 00000174cd1bab49d854a7a79fc024e485a18ae59d0c9ebd3b1aad94e578c509 at height 36883 provided via best_block_updated
<EMAIL_ADDRESS>DEBUG mutiny-core/src/logging.rs:26
2023-04-27 21:00:05.291 DEBUG [lightning::chain::onchaintx:707] Updating claims view at height 36883 with 0 claim requests
<EMAIL_ADDRESS>DEBUG mutiny-core/src/logging.rs:26
2023-04-27 21:00:05.292 DEBUG [lightning::chain::onchaintx:820] Updating claims view at height 36883 with 0 matched transactions in block 36883
<EMAIL_ADDRESS>DEBUG mutiny-core/src/logging.rs:26
2023-04-27 21:00:05.293 DEBUG [lightning::chain::onchaintx:707] Updating claims view at height 36883 with 0 claim requests
<EMAIL_ADDRESS>DEBUG mutiny-core/src/logging.rs:26
2023-04-27 21:00:05.293 DEBUG [lightning::chain::onchaintx:820] Updating claims view at height 36883 with 0 matched transactions in block 36883
<EMAIL_ADDRESS>INFO mutiny-core/src/logging.rs:27
2023-04-27 21:00:05.367 INFO  [mutiny_core::esplora:316] Finished transaction sync.
<EMAIL_ADDRESS>
and it just keeps going like that forever. Keeps updating claims view.

Yeah the event manager returns a () so we have to panic if anything errors :/
Not sure what would be a fix here, maybe getting rid of unwraps and just turning errors into logs

According to @thebluematt we should persist failures and retry them in the future, at least for spendable outputs.

I believe this is fixed entirely by the linked PR so I will close it. Will open it again if I see any issues there.


Version 4.51.1/4.51.2 does not fix bug and rebuild doesn't work

Describe The Bug
After the update to 4.51.1, Homebridge UI is not running.
Rebuilding it fails with:
username@raspberrypi:~ $ sudo hb-service rebuild
ℹ Rebuilding for Node.js v18.18.2...
node:internal/modules/cjs/loader:1080
  throw err;
  ^

Error: Cannot find module './es6/validate-engines.js'
Require stack:
- /opt/homebridge/lib/node_modules/npm/lib/cli.js
- /opt/homebridge/lib/node_modules/npm/bin/npm-cli.js
    at Module._resolveFilename (node:internal/modules/cjs/loader:1077:15)
    at Module._load (node:internal/modules/cjs/loader:922:27)
    at Module.require (node:internal/modules/cjs/loader:1143:19)
    at require (node:internal/modules/cjs/helpers:119:18)
    at Object.<anonymous> (/opt/homebridge/lib/node_modules/npm/lib/cli.js:1:25)
    at Module._compile (node:internal/modules/cjs/loader:1256:14)
    at Module._extensions..js (node:internal/modules/cjs/loader:1310:10)
    at Module.load (node:internal/modules/cjs/loader:1119:32)
    at Module._load (node:internal/modules/cjs/loader:960:12)
    at Module.require (node:internal/modules/cjs/loader:1143:19) {
  code: 'MODULE_NOT_FOUND',
  requireStack: [
    '/opt/homebridge/lib/node_modules/npm/lib/cli.js',
    '/opt/homebridge/lib/node_modules/npm/bin/npm-cli.js'
  ]
}

Node.js v18.18.2
node:internal/modules/cjs/loader:1080
  throw err;
  ^

Error: Cannot find module './es6/validate-engines.js'
Require stack:
- /opt/homebridge/lib/node_modules/npm/lib/cli.js
- /opt/homebridge/lib/node_modules/npm/bin/npm-cli.js
    at Module._resolveFilename (node:internal/modules/cjs/loader:1077:15)
    at Module._load (node:internal/modules/cjs/loader:922:27)
    at Module.require (node:internal/modules/cjs/loader:1143:19)
    at require (node:internal/modules/cjs/helpers:119:18)
    at Object.<anonymous> (/opt/homebridge/lib/node_modules/npm/lib/cli.js:1:25)
    at Module._compile (node:internal/modules/cjs/loader:1256:14)
    at Module._extensions..js (node:internal/modules/cjs/loader:1310:10)
    at Module.load (node:internal/modules/cjs/loader:1119:32)
    at Module._load (node:internal/modules/cjs/loader:960:12)
    at Module.require (node:internal/modules/cjs/loader:1143:19) {
  code: 'MODULE_NOT_FOUND',
  requireStack: [
    '/opt/homebridge/lib/node_modules/npm/lib/cli.js',
    '/opt/homebridge/lib/node_modules/npm/bin/npm-cli.js'
  ]
}

Node.js v18.18.2
Error: Command failed: npm rebuild --unsafe-perm
✖ ERROR: Failed Operation

I could only fix it by running sudo apt-get reinstall homebridge but now the version is downgraded again.
Logs
[27/10/2023, 14:12:28] [Homebridge UI] Error<EMAIL_ADDRESS>cannot open shared object file: No such file or directory
[27/10/2023, 14:12:28] [Homebridge UI] [node-pty] Node.js v18.18.2
[27/10/2023, 14:12:28] [Homebridge UI] [node-pty] Failed to load node-pty module
[27/10/2023, 14:12:28] [Homebridge UI] [node-pty] This could be because the installation of this plugin did not complete successfully or you may have recently upgraded Node.js to a new major version.
[27/10/2023, 14:12:28] [Homebridge UI] [node-pty] Follow the steps below to resolve this issue.
[27/10/2023, 14:12:28] [Homebridge UI] [node-pty] Trying to rebuild automatically...
[27/10/2023, 14:12:28] [Homebridge UI] [node-pty] Path: /opt/homebridge/lib/node_modules/homebridge-config-ui-x/node_modules/@homebridge/node-pty-prebuilt-multiarch
[27/10/2023, 14:12:29] [Homebridge UI] [node-pty] Failed to rebuild npm modules automatically. Manual operation is now required.
[27/10/2023, 14:12:29] [Homebridge UI] [node-pty] From the terminal run this command to rebuild npm modules:

[27/10/2023, 14:12:29] [Homebridge UI] sudo hb-service rebuild

[27/10/2023, 14:12:29] [HB Supervisor] ERROR: The user interface threw an unhandled error
Error: Node.js global modules rebuild required. See log errors above.
    at main (/opt/homebridge/lib/node_modules/homebridge-config-ui-x/dist/main.js:29754:19)
    at 1808 (/opt/homebridge/lib/node_modules/homebridge-config-ui-x/dist/main.js:29806:1)
    at __webpack_require__ (/opt/homebridge/lib/node_modules/homebridge-config-ui-x/dist/main.js:30138:42)
    at /opt/homebridge/lib/node_modules/homebridge-config-ui-x/dist/main.js:30166:1
    at /opt/homebridge/lib/node_modules/homebridge-config-ui-x/dist/main.js:30272:3
    at Object.<anonymous> (/opt/homebridge/lib/node_modules/homebridge-config-ui-x/dist/main.js:30277:12)
    at Module._compile (node:internal/modules/cjs/loader:1256:14)
    at Module._extensions..js (node:internal/modules/cjs/loader:1310:10)
    at Module.load (node:internal/modules/cjs/loader:1119:32)
    at Module._load (node:internal/modules/cjs/loader:960:12)

Config
No response
Homebridge UI Version
Former: 4.51.1 After rebuild: homebridge-config-ui-x v4.50.6
Homebridge Version
v1.6.1
Node.js Version
v18.18.2
Operating System
Raspberry Pi OS / Raspbian
Environment Info

[ ] Using Docker?
[ ] Using Hyper-V?
[X] Using hb-service?

Raspberry Pi Model
Raspberry Pi 3 A+

Neither does 4.51.2
And we can't update as the Debian OS that we installed with doesn't allow GLIBCXX update

i could fix this via
sudo hb-service rebuild

This seems somewhat related to #1599

Yes, probably the same underlying cause. I just wanted to highlight that rebuild is not working.
I would assume that it is related to the fact that strings /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 | grep GLIBCXX is giving me strings: '/usr/lib/arm-linux-gnueabihf/libstdc++.so.6': No such file.
However, some sort of GLIBCXX should be installed as sudo dpkg -l | grep libc6 gives me
ii  libc6:arm64                          2.31-13+rpt2+rpi1+deb11u7        arm64        GNU C Library: Shared libraries
ii  libc6-dbg:arm64                      2.31-13+rpt2+rpi1+deb11u7        arm64        GNU C Library: detached debugging symbols
ii  libc6-dev:arm64                      2.31-13+rpt2+rpi1+deb11u7        arm64        GNU C Library: Development Libraries and Header Files

(But this is beyond my knowledge of RPi)

There are two issues going on
1 - NodeJS 20 update on Operating System Environments that don't support it are failing with a GLIBCXX issue - https://github.com/homebridge/homebridge/issues/3453
2 - After the update to config-ui-x 4.51+, the UI doesn't start and needs to have sudo hb-service rebuild run.
Your issue is #2, and you setup is in limbo as your setup for some reason fails trying to run sudo hb-service rebuild
We are working on a beta release that should resolve #2, you could try the test version of Homebridge-config-ui-x-4.52.0-beta.33

Thanks for the response – that makes sense.
I have plenty of backups and can access via SSH, so whenever the beta is ready for testing, I'm happy to participate however it is helpful!

The beta is available now -

Ahh sorry didn't know. Ran the beta it worked :tada:
My node version is v18.18.2. The UI is at homebridge-config-ui-x v4.52.0-beta.33

Tks very much for confirming

However, updating node still fails (not sure if that is on purpose):
homebridge@raspberrypi:/var/lib/homebridge $ hb-service update-node
ℹ Updating Node.js from v18.18.2 to v20.9.0...
ℹ Target: /opt/homebridge
✔ Download complete.
✔ Cleaned up npm at at /opt/homebridge/lib/node_modules/npm
✔ Installed Node.js v20.9.0
ℹ Rebuilding for Node.js v20.9.0...
/bin/sh: 1: npm: not found
/bin/sh: 1: npm: not found
Error: Command failed: npm rebuild --unsafe-perm
✖ ERROR: Failed Operation

@BastianZim - What does
cat /etc/os-release
and
strings /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 | grep GLIBCXX
show ?

PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
NAME="Debian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

and
strings: '/usr/lib/arm-linux-gnueabihf/libstdc++.so.6': No such file
Note: This is after the failed update of node.

Strangely enough, I pulled the plug on my Raspberry Pi as it became unresponsive after updating node and I couldn't even SSH in. When I rebooted it, it started to work fine again and the node version is reported as v20.9.0.

If you run node -v, uname -a and npm -v what does it show, also getconf GNU_LIBC_VERSION
node -v
v18.18.2

uname -a
Linux sheldon 6.1.0-rpi4-rpi-v8 #1 SMP PREEMPT Debian 1:6.1.54-1+rpt2 (2023-10-05) aarch64 GNU/Linux

npm -v
9.8.1

getconf GNU_LIBC_VERSION
glibc 2.36

Over SSH I get:
node -v
-bash: node: command not found

uname -a
Linux raspberrypi 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr  3 17:24:16 BST 2023 aarch64 GNU/Linux

npm -v
-bash: npm: command not found

getconf GNU_LIBC_VERSION
glibc 2.31

Via the Homebridge terminal I get:
node -v
v20.9.0

uname -a
Linux raspberrypi 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr  3 17:24:16 BST 2023 aarch64 GNU/Linux

npm -v
bash: npm: command not found

getconf GNU_LIBC_VERSION
glibc 2.31

You could try downgrading node, then updating again

ie sudo hb-service update-node 18 then sudo hb-service update-node 20

Well, it is running fine. I just had to hard-reboot it.
I did, however, run those commands and it is giving me the same error:
user@rpi:~ $ sudo hb-service update-node 18 && sudo hb-service update-node 20 && sudo hb-service rebuild
ℹ Installing Node.js v18.18.2 over v20.9.0...
ℹ Target: /opt/homebridge
✔ Download complete.
✔ Installed Node.js v18.18.2
ℹ Rebuilding for Node.js v18.18.2...
/bin/sh: 1: npm: not found
/bin/sh: 1: npm: not found
Error: Command failed: npm rebuild --unsafe-perm
✖ ERROR: Failed Operation
⚠ Please restart Homebridge for the changes to take effect.

Somehow, I don't have npm and it wasn't installed when I installed homebridge

Am thinking that over time something has happened to your setup.   Would it make sense to just rebuild from scratch at some point ?
Are you running the homebridge raspbian image or the homebridge apt package ?

Yeah, I guess so. I don't really have anything major running on it, so I'll probably do that then.
It's the apt package, as I have a couple of other small things running on it for various things.
What I don't understand is besides installing Cloudflare's warp agent, it's a stock Raspbian image with nothing changed. I wonder what bugged it.

If you just do sudo apt-get reinstall homebridge it should reset homebridge back our spring release levels.  Pls do a homebridge archive backup first.

Ok just ran that. I guess I'll wait until the beta is released or should I test anything else?

You could try the beta and update-node again.  I'm curious if the missing NPM is resolved now

Ahh ok. It's still the same as in https://github.com/homebridge/homebridge-config-ui-x/issues/1607#issuecomment-1785975083 with no NPM found.
I have no idea how that can be the case, as I can install plugins in Homebridge, which uses NPM, from what I understand.

Node update fails with the same error but when I pull the power it shows v20.9.0 after restarting.

I've updated the OS manually and that that seems to solve the problem.
I guess a clean install and reconfiguring from a backup is a better solution
I followed the instructions on these 2 places
https://www.linuxcapable.com/how-to-upgrade-from-debian-10-buster-to-debian-11-bullseye/
https://linuxize.com/post/how-to-upgrade-debian-10-to-debian-11/

The beta is available now -

I'm having the same issue on Synology NAS. I'll try the beta, but I'm unfamiliar with the beta install process on Synology nas. I've looked in the beta package center and do not see anything. Please advise how I can install the beta.

The beta is available now -

I'm having the same issue on Synology NAS. I'll try the beta, but I'm unfamiliar with the beta install process on Synology nas. I've looked in the beta package center and do not see anything. Please advise how I can install the beta.

I'm having the same issue over on #1599.  The beta didn't work for me.  My next step is to install the development tools and see if I can rebuild HB.  That said, the latest Node.js doesn't want to be installed 'Non-standard installation path detected<EMAIL_ADDRESS>This feels like it may the the end of the line for native homebridge on my DSM. :(

@BastianZim I took at look at a coupe of my machines, and what your seeing is that the Homebridge APT maintains its own copies/versions of NodeJS and NPM for internal use, and occasionally it leverages the OS installed versions.  And on your RPI, the OS does not NPM installed currently.  This explains the differences between you see in the homebridge terminal vs SSH
You can reinstall npm with the command sudo apt-get install npm

Ahh ok that makes sense. Would it be better for the future then to maybe install that with Homebridge?

I'm a bit confused and can't find a solution.
Can I safely update to Node 20.X.X with the current Docker image (1.61 - not sdk) with Ubuntu 22.04.3 LTS on my Synology NAS???

Are you having the same issues with 4.52.1?

I have the same issues with 4.52.1


refactor (3/3): Introducing local FakeDNS

I removed global fake DNS from controller and replaced it by local DNS server from utils.
I fixed controller unit tests to be interacting with local FakeDNS instances.
Signed-off-by: kuritka<EMAIL_ADDRESS>

@ytsarev , amended.
💯  it will go to gopkg. The idea is to make it run for a while in k8gb. Maybe some changes will need to be implemented and when it settles down a bit, we'll move it into gopkg.


Snyk reports code vulnerability in default startup project

Describe the bug
When starting up a new project with npm init svelte@next, the new Snyk Vulnerability Scanner extension for VS Code reports a code vulnerability on lines 7 and 15 of [uid].json.ts: "Unsanitized input from an HTTP parameter [:7] flows [:7, :7, :7, :19, :27, :27] into fetch [:27], where it is used as an URL to perform a request. This may result in a Server-Side Request Forgery vulnerability."
This obviously doesn't represent a security vulnerability in either Svelte or Sveltekit, and in truth I don't completely understand whether this is an actual vulnerability or just a potential one in the startup project code. However, I think we should encourage people to use security tools like Snyk, and part of that encouragement should be ensuring that the startup code either pass all the security tests or else include an ignore comment and explain why they don't apply.
Reproduction
The kit repository contains the issue in /packages/create-svelte/templates/default.
Logs
No response
System Info
System:
    OS: macOS 10.15.7
    CPU: (8) x64 Intel(R) Core(TM) i7-1060NG7 CPU @ 1.20GHz
    Memory: 491.80 MB / 16.00 GB
    Shell: 5.7.1 - /bin/zsh
  Binaries:
    Node: 14.17.6 - ~/.nvm/versions/node/v14.17.6/bin/node
    npm: 7.24.0 - ~/.nvm/versions/node/v14.17.6/bin/npm
  Browsers:
    Firefox: 94.0.1
    Safari: 15.1
  npmPackages:
    @sveltejs/adapter-auto: next => 1.0.0-next.3
    @sveltejs/kit: next => 1.0.0-next.201
    svelte: ^3.44.0 => 3.44.2

Severity
annoyance
Additional Information
No response

A lot of time has passed since this was opened and the startup project looks completely different now. If something similar persists, please open a new issue - thank you.


[main] Upgrade to latest dependencies

release -dprotaso
/cc knative-sandbox/client-writers
/assign knative-sandbox/client-writers
Produced by: knative-sandbox/knobots/actions/update-deps
Details:
bumping knative.dev/serving 8a2fb54...d79b8bb:
  > d79b8bb upgrade to latest dependencies (# 13246)
bumping knative.dev/eventing cc06bab...a9151b5:
  > a9151b5 upgrade to latest dependencies (# 6495)
  > 291e961 upgrade to latest dependencies (# 6493)
bumping knative.dev/client be439e1...6d86bf7:
  > 6d86bf7 upgrade to latest dependencies (# 1727)

/lgtm
/approve


Fix linting errors in libs/movex-server

[x] running npx nx lint movex-server --quiet will not return any more errors

Closes: #130

@GabrielCTroia it would be great if this issue can be counted in Hacktoberfest or I can work on other issues too. Let me know which one to pick.

I just added the hacktoberfest labels! Thanks for pointing it out 🙏


Implement neg (float/integer) and not IL instructions. Fixes #4524 and #4525

I took some time to implement the neg and not opcode. I also added support to float for neg op because I noticed a BuildFNeg method was available. I don't really know if this it's correct.
Just let me know if this can help you guys ;)

@jacano,
Thanks for having already signed the Contribution License Agreement. Your agreement was validated by .NET Foundation. We will now review your pull request.
Thanks,
.NET Foundation Pull Request Bot

I didn't include a little test in tests/src/Simple/HelloWasm/Program.cs. I'm sorry, I can fix this now

I suspect I also need to handle the NativeInt type...

I made two simple tests that are working:

I was unable to get the neg test on floats working so I'm not pushing it.
I think that it is still missing some code to handle NativeInt type. I mean, check for NativeInt on the argument kind and make a conversion using LLVM.BuildPtrToInt, then neg/not and later LLVM.BuildIntToPtr.

@jacano, now that you've got one in, interested in picking up any more opcodes (or anything else)?

I think I can give a try to the array ops. As I saw in the issue description, you don't need to interact with the runtime nor the GC, so I suppose I can do it. I hope to have some time during the following week 😀


vtk datawidgets

this copies implementation from https://github.com/vidartf/jupyter-vtk-datawidgets

We're not pursuing this any further. pyMOR visualization will use K3d instead.


Download config

Add a subcommand for downloading a JSON dump of the autograder configuration.  It would be really useful for committing to version control so that we can check if the AG has drifted.

For reference, here's how EECS 280 does it.
#!/usr/bin/env python3
"""
Download test suite configurations for a given project from autograder.io
using REST API and save to JSON files.
"""
import os
import sys
import shutil
import json
import requests
import click
import urllib3

def filter_config(config):
    """Remove unwanted properties from AG project configuration JSON"""

    exclude = [
        "pk",            # primary keys naturally change when projects are copied
        "last_modified", # meaningful changes will show up elsewhere
        "project",       # a foreign key a variety of things to a project
        "ag_test_suite", # a foreign key from a test case to test suite
        "ag_test_case",  # a foreign key from a test command to test case
        "course"         # a foreign key from a docker sandbox image to course
    ]

    if isinstance(config, list):
        return [filter_config(elt) for elt in config]
    elif isinstance(config, dict):
        return {k: filter_config(v) for k,v in config.items() if k not in exclude}
    else:
        return config

# List of file paths to check for API token file
API_TOKEN_FILENAMES = ["agtoken", ".agtoken", "~/.agtoken"]

# REST API base url
API_URL_BASE = 'https://autograder.io/api'

@click.command(context_settings={'help_option_names': ['-h', '--help']})
@click.argument(
    'project_pk',
)
@click.option(
    '--output',
    '-o',
    help='Output filename.',
)
@click.option(
    '-v',
    '--verbose',
    count=True,
    help="Verbose output.",
    default=0,
)
def main(project_pk, output=None, verbose=0):
    """Download test suite configurations for an autograder.io project."""

    # Read API token from file
    api_token_filename = None
    for filename in API_TOKEN_FILENAMES:
        filename = os.path.expanduser(filename)  # handle any leading tilde
        if os.path.isfile(filename):
            api_token_filename = filename
            break
    if not api_token_filename:
        print(f"Error: can't find api token.  Tried: {API_TOKEN_FILENAMES}")
        sys.exit(1)
    with open(api_token_filename) as api_token_file:
        api_token = api_token_file.read().strip()
    if verbose:
        print(f"Read token from {api_token_filename}")

    # Default output filename is "ag-config.json"
    if output is None:
        output = "ag-config.json"

    # Set authentication header
    headers = {'Authorization': f'Token {api_token}'}

    # Grab json description of project test suites
    project_config = requests.get(
        f'{API_URL_BASE}/projects/{project_pk}/ag_test_suites/',
        headers=headers, stream=True).json()

    # Remove unwanted properties from config
    project_config = filter_config(project_config)

    # Write config to file
    with open(output, 'w') as f:
        json.dump(project_config, f, indent=2)

if __name__ == '__main__':
    main()


Failed to install/update extension

When I prepare to update or install extensions, this error net::ERR_INVALID_ARGUMENT: always appears, causing me to fail; but I checked that there is no problem with the network.
VS Code version: Code 1.89.1 (Universal) (dc96b837cf6bb4af9cd736aa3af08cf8279f7685, 2024-05-07T05:14:24.611Z)
OS version: Darwin arm64 21.2.0
Modes:

Hi @MoMeakDong ,
Thanks for reaching VS Marketplace Team, could you please share more details about your concern to investigate better.
If you think this issue is specific to vscode, could you please reach out to the VS Code Team https://github.com/microsoft/vscode/issues for further assistance.
Regards,
VS Marketplace Team

Since we have not received the required information, we are closing the issue. Please feel free to reopen or create a new issue if the problem still persists.
Regards,
VS Marketplace Team


Lazy import as much as possible

I tested this two ways:

just having splat as a submodule like usual
replacing the splat module in /usr/local/lib/python3.10/dist-packages/splat with this change

Fixes #331.

this makes using splat as a library a bit of a pain.


Add a component "analysis"

Hi.
Currently RLS is under development.
It uses analysis from https://static.rust-lang.org/dist/index.html
It would be cool if I could execute rustup component add analysis
and each time I do rustup update it would update analysis's files.
How hard is it to implement?
Thanks

If I'm reading this correctly, rustup can install anything that's listed in the channel manifest without needing any change. But the channel manifests currently don't list the analysis files.

@Arnavion,
I am sorry, but I don't understand you.
Could you write what steps I should do to make rustup install analysis files please?

I'm saying you can't do anything in rustup to fix it. The list of components rustup can install comes from multirust-channel-manifest.toml and currently this file doesn't list the analysis files. So something probably needs to change in rust packaging to include the analysis files in this file.

@nrc,
Hi.
I have read Arnavion's comment, but I still don't get it.

2017-02-03's nightly's manifest contains rust-analysis, but it's associated with the wrong target - all the entries are associated with x86_64-unknown-netbsd. Once that's fixed, rustup component add rust-analysis will start working.

@Arnavion,
That's cool.

@KalitaAlexey For now, you can do this:

rustup update nightly to get a nightly >= 2017-02-03
Find ~/.rustup/toolchains/nightly-$triple/lib/rustlib/multirust-channel-manifest.toml
Find the line for pkg = "rust-analysis" inside the section for your triple. Eg: I'm on x86_64-pc-windows-msvc so I found the one in the section named [[pkg.rust.target.x86_64-pc-windows-msvc.extensions]]. Change it from target = "x86_64-unknown-netbsd" to target = "$triple"
rustup component add rust-analysis. Now you should have the JSON files unpacked to ~/.rustup/toolchains/nightly-$triple\lib\rustlib\x86_64-pc-windows-msvc\analysis

We'll also need to update RLS to use this path instead of its custom one.

This is work in progress, but I don't think there is anything left to do on the Rustup side (just RLS stuff to address).

Hello @nrc,
Why does multirust-channel-manifest.toml have wrong target (x86_64-unknown-netbsd)?
I suppose it is the only problem between RLS and rustup.
I want to help, could you provide any guidance?

@KalitaAlexey this should be fixed now, I think there was a PR a while ago which addressed it.

@nrc,
To check that I should reinstall rustup and check the manifest, right?

I'm not entirely sure, I wouldn't think you need to reinstall Rustup, but perhaps?

It was fixed for some time after my PR, but newer nightlies' manifests don't have the extension at all.

<Arnavion> acrichto or anyone else: With the new travis-based release infrastructure, is it that everything that used to be done by buildbot should now be done by `x.py dist` ?
<@acrichto> Arnavion: correct

So @nrc's change needs to be ported to x.py

https://github.com/rust-lang/rust/pull/40082


E2379. Reimplement authorization_helper.rb

There is a DRY problem with the code and the authorization logic could be placed in a service class or concerns.


Html example blog post

Since I was at it, I also fixed a couple of grammatical errors in the markdown file and added a couple missing entries to the TOC.

since I was at it I also fixed a couple of grammatical errors in the markdown template and added some missing entries to the TOC

I think this is finally ready. Please take a look @busycalibrating

gentle ping @busycalibrating , as I think its important to have this feature before announcing widely

Sorry for the delay, I'll check on this today asap!

Awesome, thanks!
On Thu, Sep 28, 2023, 15:58 busycalibrating @.***>
wrote:

Sorry for the delay, I'll check on this today asap!
—
Reply to this email directly, view it on GitHub
https://github.com/iclr-blogposts/2024/pull/6#issuecomment-1739272781,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AACDZB6CJJ5G2UBUXFMBAILX4V7BNANCNFSM6AAAAAA4W6DODI
.
You are receiving this because you authored the thread.Message ID:
@.***>

Sorry for the delay, but looks great! Thanks you for adding this and for catching those details!


openldap: putting keg_only before option

brew audit --strict  openldap returns:
homebrew/dupes/openldap:
 * `keg_only` (line 23) should be put before `option` (line 15)

--

[x] Have you followed the guidelines in our Contributing document?
[x] Have you checked to ensure there aren't other open Pull Requests for the same update/change?

This PR fixes this warning.

Thanks! Merged as 429d4257aa12bef93d0036db0ba045084248ee3b.


[ENHANCEMENT][UI] Hint user to configure proper namespaces before generating a support-bundle

Is your enhancement related to a problem? Please describe.

The support-bundle will collect information from the configured namespace, but there is no clear hint on UI
https://docs.harvesterhci.io/v1.3/troubleshooting/harvester#generate-a-support-bundle

In many cases, the collected support-bundle doesn't include the issue-happening namespaces, after figure out this, the issue may have disappeared, or the related logs have been flushed. Or it takes long time to ping-pong.
Describe the solution you'd like

In the pop-up window, have a clear hint to the user that it is essential to configure the proper namespaces. And also list the already configured namespace. Thus the user will always know which scope of information is collected.
Describe alternatives you've considered

The document has been updated, but seems not enough.
Additional context

Let's make the enhancement to allow users select namespace while collecting a SB.


How to generate the trainval_ans2label.pkl file?

Hi,
Could I ask where to download the trainval_ans2label.pkl file?
Also, I would like to try Oscar + VizWiz on the VizWiz dataset, how could I process the original annotation (.json) file to the .pkl file?
Thank you a lot in advance!

I just downloaded the tranval_ans2label.pkl file from
path/to/azcopy copy 'https://biglmdiag.blob.core.windows.net/vinvl/datasets/TASK_NAME'  --recursive
following https://github.com/microsoft/Oscar/blob/master/VinVL_DOWNLOAD.md
But still need help to generate these annotations for the VizWiz dataset.

@CCYChongyanChen funny finding you here!


React Hooks Support - useRedux()

Hi guys,
at current React Conf Hooks have been announced for React v16.7. What's the plan for supporting them? Will there be a useRedux() any time soon?
https://reactjs.org/docs/hooks-faq.html#what-do-hooks-mean-for-popular-apis-like-redux-connect-and-react-router

Not related to the Redux core.  Please see the relevant discussion in the React-Redux repo here: https://github.com/reduxjs/react-redux/issues/1063 .


[onDeviceUI] Adding on device addons.

This PR is part of #3903.
This adds 3 on device addons: Notes, Knobs, Backgrounds.
They are definitely not the cleanest and up to date addons.
Looking forward @ndelangen suggested that we have to think of the way to display addons as webviews in the app. But for now these are good enough to display that we can have addons in the app.

Nothing seems to be blocking this PR too @ndelangen, @igor-dv.

Let's merge if after the #3903 is ready? We won't use addons without the support for addons, right?

Sure.

merge when ready


The fetch chunks process need to be further checked for stargz case

In do_fetch_chunks() ,  seems the chunkmap bits have not been marked as pending for stargz case , Also we should clear the pending bits when get io error.

https://github.com/dragonflyoss/image-service/pull/833


Pluggable serializers and deserializers

I would like to create two methods on a struct, one that uses serde to serialize and one that uses serde to deserialize, but I want neither of the methods to depend on a specific data interchange format such as JSON. So I don't want the methods to have any direct reference to serde_json.
Instead the methods could rely on traits specified as input parameters to the new function on the struct

If you are still interested in guidance on this, please follow up in one of the resources listed in https://github.com/serde-rs/serde/tree/v1.0.135#getting-help.


[subset] Allow LangSys tags in --layout-scripts

Allow specifying which LangSys tags to accept for each script, using script.lang form. For example:
--layout-scripts=arab.dflt,arab.URD,latn

To keep DefaultLangSys and URD language for arab script, and all languages for latn script.

thanks Khaled


Skybox UI editing

(+ some other small UI features as well)

Implemented in Commit<PHONE_NUMBER>1c1630f3b38684aa480606fd51b9f6 and merged in PR #36