Endpoint validation option not working properly

Description:
Even though the correct endpoint is provided, when the validation option is clicked (the tick), it shows a 404 not found error.

Steps to reproduce:

Follow [1] to create a REST API from an OpenAPI definition by giving the following details.

Field
Sample value

OpenAPI URL
https://petstore3.swagger.io/api/v3/openapi.json

Name
SwaggerPetstore

Context
/petstore

Version
1.0.6

Endpoint
https://petstore3.swagger.io/api/v3

Click the tick next to the endpoint URL option to validate it.

[1] https://apim.docs.wso2.com/en/latest/design/create-api/create-rest-api/create-a-rest-api-from-an-openapi-definition/
Affected Product Version:

Environment details (with versions):

OS:
Client:
Env (Docker/K8s):

Optional Fields
Related Issues:

Suggested Labels:

Suggested Assignees:

@uvindra & @nuwand , please let me know your thoughts with regard to this feature.
I feel that if there is no strong usecase for it that we should look at removing it in API-M 4.1.0 as opposed to just keeping it for the sake of it.

This feature will work as expected under the following conditions,

The root endpoint URL specified must be a supported resource
It should support HEAD requests

But there is no guarantee that the above will be true for all endpoints. There is no way of determining this before hand and it will vary from endpoint to endpoint. So due to violation of at least one of the above conditions, even though the correct endpoint value is specified the validation will fail.

Closing with above comment.


Telepathy Transport, 7000 port issue

I'm not sure if this is a bug. When I change the port to 7777, there is no problem, but when I change it to 7000, it gives an error. I don't actively use this port anywhere else. It was working before. The problem occurred when I upgraded the mirror to v95. When I change the port to something else, there is no problem, only 7000 causes the problem.

OS: Windows
Build target: Windows
Unity version: Unity 6 LTS
Mirror branch: Master V95

please post all the errors

There is no other error. The only error I received is the error in the picture.
I opened a new project and tested it, if you want you can test it too.
When using Insight, when you start the game in the masterServer scene, this line gives an error. When the mirror version is old, it does not give an error, when I use v93 and above, this error occurs.

Let me correct;
I misunderstood the problem at first. It is not related to the port. It appears when you update the mirror version in any case.


Add validation to calculator inputs

Description
Add validation to memory and ssd storage
Changes

Related Issues

https://github.com/threefoldtech/tfgrid-sdk-ts/issues/2202

Checklist

[ ] Tests included
[x] Build pass
[ ] Documentation
[x] Code format and docstrings
[x] Screenshots/Video attached (needed for UI changes)

Please add an isRequired condition to the HDD as well to be consistent with the other fields.

Done.


[WIP] Adds lib/miq_benchmark to benchmark per PR

Purpose
Provide a per PR feedback loop to developers about trends/changes in the overall memory footprint of the application, and other benchmarks.  Currently, there is only a script to analyze memory after eager loading the entire project, but other tests are expected to follow.
mem_full_load_benchmark
This is heavily borrowing the code from derailed_benchmarks project, specifically, the perf:mem task from the tool.  This currently doesn't make a request against a booted app, but does eager_load the entire application into memory to get a better picture of what is taking up the most amount of memory (if we didn't eager load, we would only see about 120 MiB allocated when booting up the application, v.s. alomst 300 MiB).
To see the report, you can currently run:
$ bundle exec ruby lib/miq_benchmark/mem_full_load_benchmark.rb

And you should see some output like this:
$ bundle exec ruby lib/miq_benchmark/mem_full_load_benchmark.rb
TOP: 281.1094 MiB
  config/application: 77.625 MiB
    omniauth-google-oauth2: 13.8086 MiB
      omniauth/google_oauth2: 13.7305 MiB
        omniauth/strategies/google_oauth2: 13.6563 MiB
          omniauth/strategies/oauth2: 9.1367 MiB
            oauth2: 6.3398 MiB
              oauth2/client: 3.8125 MiB
                faraday: 3.5742 MiB (Also required by: manageiq/api/client, faraday_middleware)
                  /Users/nicklamuro/.gem/ruby/2.3.3/gems/faraday-0.9.2/lib/faraday/upload_io: 0.6914 MiB
                  /Users/nicklamuro/.gem/ruby/2.3.3/gems/faraday-0.9.2/lib/faraday/response: 0.4492 MiB
              oauth2/mac_token: 0.5469 MiB
              oauth2/response: 0.5391 MiB
                multi_xml: 0.3633 MiB
            omniauth/strategy: 1.5313 MiB
              hashie/mash: 1.1719 MiB (Also required by: omniauth/auth_hash)
                hashie/hash: 0.4961 MiB
                hashie/array: 0.3867 MiB
            socket: 0.7617 MiB (Also required by: puma, puma/server, and 12 others)
          addressable/uri: 4.3867 MiB (Also required by: addressable, addressable/template)
            addressable/idna: 3.1523 MiB
              addressable/idna/pure: 2.6484 MiB
    active_record/railtie: 12.8789 MiB (Also required by: rails/all)
...

SUMMARY ( TOTAL COST: 281.1094 MiB )
-------------------------------------------------------------------------------------------------------------------------------------
config/application                                                                                | 77.6250 MiB
manageiq-providers-amazon/app/models/manageiq/providers/amazon/cloud_manager                                            | 44.5977 MiB
manageiq-providers-azure/app/models/manageiq/providers/azure/regions                                                    | 38.3359 MiB
manageiq-providers-vmware/app/models/manageiq/providers/vmware/cloud_manager                                            | 27.1094 MiB
vmdb_helper                                                                                | 11.5391 MiB
manageiq-ui-classic/app/presenters/tree_builder_buttons                                                                 |  3.0312 MiB
manageiq-ui-classic/app/controllers/miq_policy_controller                                                               |  2.9062 MiB
manageiq-ui-classic/app/controllers/alert_controller                                                                    |  2.5508 MiB
manageiq-providers-amazon/app/models/manageiq/providers/amazon/cloud_manager/orchestration_service_option_converter     |  2.3906 MiB
action_cable/server/base                                                                                |  2.0703 MiB
manageiq-providers-amazon/app/models/manageiq/providers/amazon/cloud_manager/vm                                         |  1.4453 MiB
manageiq-providers-vmware/app/models/manageiq/providers/vmware/infra_manager/refresher                                  |  1.3789 MiB
manageiq-providers-amazon/app/models/manageiq/providers/amazon/cloud_manager/provision                                  |  1.2695 MiB
automation_engine                                                                                |  1.1914 MiB
action_dispatch/routing/mapper                                                                                |  1.1875 MiB
manageiq-ui-classic/app/decorators/manageiq/providers/ansible_tower/automation_manager/configuration_script_decorator   |  1.1641 MiB
manageiq-providers-amazon/app/models/manageiq/providers/amazon/network_manager                                          |  0.9961 MiB
manageiq-providers-amazon/app/models/manageiq/providers/amazon/cloud_manager/event_catcher/runner                       |  0.9297 MiB
config/environments/production.rb                                                                                |  0.9141 MiB
...

Implementation Notes
Some monkey patching was necessary to make this work:

Kernel::require - this is taken from derailed_benchmarks, so pretty well tested.  Nothing really changed in that file from the source.
Rails::Application::Configuration - Needed to force eager_loading even though we don't do it in our project in any environment.  This was the best way I could think of doing it based on my limited knowledge of the Rails setup process and without modifying the configuration directly.  This is done in the lib/miq_benchmark/mem_full_load_benchmark.rb file.

Currently, the code added in this PR lives in lib/miq_benchmark and should only be loaded when the miq_benchmark code is loaded (or rather, at least it wasn't loaded when I ran this in a console locally).  This might be off living in the tools/ dir, or possibly a new top level directory entirely that is not packaged when the appliance is built... not sure...
Also, you might ask:

"Hey Nick, why didn't you just use derailed_benchmarks?"

That gem directly depends on about 5-6 performance focused gems, and while I think they are all solid, they are not something I felt necessary to be in our repository.  Also,the functionality that exists from GetProcessMem already exists in sys-proctable, which already is a dependency of manageiq.  Plus, with the hacks necessary to load the app in the fashion we wanted, we probably would have had to write just as much code to use derailed_benchmarks normally, so extra effort to do it this way seemed silly.
To put it simply, it is an effort to avoid any new dependencies in the project.
A separate Travis job will be added as part of this PR eventually, but there is a bug that needs to be addressed in a separate PR before this could run properly, so that will be implemented later.
Links

https://www.pivotaltracker.com/story/show/141463609
https://github.com/schneems/derailed_benchmarks
https://github.com/ManageIQ/manageiq/pull/14262 (bug fix necessary for this to work)

Steps for Testing/QA
Feel free to run:
$ bundle exec ruby lib/miq_benchmark/mem_full_load_benchmark.rb

From your own machine and compare the results.  There will probably be a bit of a fudge factor of 10-20 MiB from what I have sampled above, but as long as you are in the ballpark, this is probably good.  Also, if a patch hasn't been added, you might also need to update the high-voltage gem to >= 3.0.0 (this was the "bug" I was referring to earlier).

@miq-bot add_label performance test tools

@miq-bot add_label performance, test, tools

^ The gem changes label will need to be removed when that [CHERRY_PICK] commit is removed.

nice, no additional requirements.

👍

Is it possible to get some of these changes back into derailed gem? So we could just use them? (the new improved version of them of course)

@kbrock I actually have a PR against derailed that has been open for months now (104, though trying not to link it here) with the biggest part from that that I really wanted here, which was the fix for require_relative.
Besides that, I think I sum up a lot of the "why" for that in the first commit of this PR (near the bottom).


new func: ig.live.addPostLiveToIgtv()

#1190 feature request
This function saves the live to IGTV.
I will give an example usage.

//Save to IGTV

//Get live thumbnails, required to post on IGTV
r=await ig.live.getPostLiveThumbnails(bc.broadcast_id)

//Download any one
func = callback=>https.get(r.thumbnails[0],res=>{
  ds=[];
  res.on("data",d=>ds.push(d));
  res.on("end",()=>{callback(Buffer.concat(ds))})
})
file = await new Promise(func)

//It will be a png, it must be converted to jpg (I will use a library)
pngToJpeg = require('png-to-jpeg');
file = await pngToJpeg({quality: 90})(file)

//Upload the thumbnail and get uploadId
r=await ig.upload.photo({file})

//Post live to IGTV
await ig.live.addPostLiveToIgtv({broadcastId:bc.broadcast_id,title:"Some title",description:"Some description",coverUploadId:r.upload_id})

func = callback=>https.get(r.thumbnails[0],res=>{
ds=[];
res.on("data",d=>ds.push(d));
res.on("end",()=>{callback(Buffer.concat(ds))})
})
file = await new Promise(func)

We already have request-promise as a dependency.

{"message":"POST /api/v1/live/add_post_live_to_igtv/ - 500 Internal Server Error; ","name":"IgResponseError","response":{"statusCode":500,"body":"Oops, an error occurred.\n","headers":{"content-type":"text/html; charset=utf-8","vary":"Accept-Language, Cookie","content-language":"en","date":"Wed, 17 Jun 2020 10:43:44 GMT, Wed, 17 Jun 2020 10:43:44 GMT","strict-transport-security":"max-age=31536000","cache-control":"private, no-cache, no-store, must-revalidate","pragma":"no-cache","expires":"Sat, 01 Jan 2000 00:00:00 GMT","x-frame-options":"SAMEORIGIN","content-security-policy":"report-uri https://www.instagram.com/security/csp_report/; default-src 'self' https://www.instagram.com; img-src https: data: blob:; font-src https: data:; media-src 'self' blob: https://www.instagram.com https://.cdninstagram.com https://.fbcdn.net; manifest-src 'self' https://www.instagram.com; script-src 'self' https://instagram.com https://www.instagram.com https://.www.instagram.com https://.cdninstagram.com wss://www.instagram.com https://.facebook.com https://.fbcdn.net https://.facebook.net 'unsafe-inline' 'unsafe-eval' blob:; style-src 'self' https://.www.instagram.com https://www.instagram.com 'unsafe-inline'; connect-src 'self' https://instagram.com https://www.instagram.com https://.www.instagram.com https://graph.instagram.com https://.graph.instagram.com https://.cdninstagram.com https://api.instagram.com https://i.instagram.com wss://www.instagram.com wss://edge-chat.instagram.com https://.facebook.com https://.fbcdn.net https://.facebook.net chrome-extension://boadgeojelhgndaghljhdicfkmllpafd blob:; worker-src 'self' blob: https://www.instagram.com; frame-src 'self' https://instagram.com https://www.instagram.com https://staticxx.facebook.com https://www.facebook.com https://web.facebook.com https://connect.facebook.net https://m.facebook.com; object-src 'none'; upgrade-insecure-requests","x-content-type-options":"nosniff","x-xss-protection":"0","x-aed":"15","x-ig-set-www-claim":"hmac.AR3QeK8RHW4GyJg6u7m7cqOZQmjpGE8sG7SGQ5htV8k-OjBF","access-control-expose-headers":"X-IG-Set-WWW-Claim","set-cookie":["csrftoken=6SRnZoKfXGfvTLiJyXdqdKiimUfPGBjw; Domain=.instagram.com; expires=Wed, 16-Jun-2021 10:43:44 GMT; Max-Age=31449600; Path=/; Secure","urlgen="{\"<IP_ADDRESS>\": 3356}:1jlVXk:4smQzRq2K7H0-EaOgvFmEf6LUp0"; Domain=.instagram.com; HttpOnly; Path=/; Secure"],"connection":"close","content-length":"25"},"request":{"uri":{"protocol":"https:","slashes":true,"auth":null,"host":"i.instagram.com","port":443,"hostname":"i.instagram.com","hash":null,"search":null,"query":null,"pathname":"/api/v1/live/add_post_live_to_igtv/","path":"/api/v1/live/add_post_live_to_igtv/","href":"https://i.instagram.com/api/v1/live/add_post_live_to_igtv/"},"method":"POST","headers":{"User-Agent":"Instagram <IP_ADDRESS>.119 Android (27/8.1.0; 480dpi; 1080x1920; Xiaomi/xiaomi; Mi A1; tissot_sprout; qcom; en_US; 185203708)","X-Ads-Opt-Out":"0","X-CM-Bandwidth-KBPS":"-1.000","X-CM-Latency":"-1.000","X-IG-App-Locale":"en_US","X-IG-Device-Locale":"en_US","X-Pigeon-Session-Id":"79b0bf79-acb4-51bb-95cb-e063bf7c7e35","X-Pigeon-Rawclienttime":"1592390622.426","X-IG-Connection-Speed":"2442kbps","X-IG-Bandwidth-Speed-KBPS":"-1.000","X-IG-Bandwidth-TotalBytes-B":"0","X-IG-Bandwidth-TotalTime-MS":"0","X-IG-Extended-CDN-Thumbnail-Cache-Busting-Value":"1000","X-Bloks-Version-Id":"1b030ce63a06c25f3e4de6aaaf6802fe1e76401bc5ab6e5fb85ed6c2d333e0c7","X-MID":"XunadgABAAFXuWk098L0LNVsIteC","X-IG-WWW-Claim":"hmac.AR3QeK8RHW4GyJg6u7m7cqOZQmjpGE8sG7SGQ5htV8k-OjBF","X-Bloks-Is-Layout-RTL":"false","X-IG-Connection-Type":"WIFI","X-IG-Capabilities":"3brTvwE=","X-IG-App-ID":"567067343352427","X-IG-Device-ID":"b519c3ed-d897-571f-89fb-965ac0feb283","X-IG-Android-ID":"android-4585d2741a15bd6d","Accept-Language":"en-US","X-FB-HTTP-Engine":"Liger","Host":"i.instagram.com","Accept-Encoding":"gzip","Connection":"close","cookie":"csrftoken=6SRnZoKfXGfvTLiJyXdqdKiimUfPGBjw; mid=XunadgABAAFXuWk098L0LNVsIteC; ds_user=summer_chen1; ds_user_id=37307922685; urlgen="{\"<IP_ADDRESS>\": 3356}:1jlVXb:cTaA8cANKqJjUKt5gXPvVBGKKK4"; sessionid=37307922685%3APtMhVaL8zNVils%3A7","content-type":"application/x-www-form-urlencoded","content-length":528}}},"errorCode":"error"}

message: "POST /api/v1/live/add_post_live_to_igtv/ - 500 Internal Server Error; "
name: "IgResponseError"
How should I solve this problem？

addPostLiveToIgtv
message: "POST /api/v1/live/add_post_live_to_igtv/ - 500 Internal Server Error; "
name: "IgResponseError"
How should I solve this problem？

hm, do you find a way to solve the problem ?

addPostLiveToIgtv
message: "POST /api/v1/live/add_post_live_to_igtv/ - 500 Internal Server Error; "
name: "IgResponseError"
How should I solve this problem？

Same error for me, maybe instagram changed this endpoint because I checked other instagram api libraries and they are using the same endpoint and parameters... I don't know how to find the new endpoint/parameters.

I just found a solution for the 500 error... It was just the cover upload format, it must be 1080x1920, a vertical thumbnail...
I used "sharp" to resize the PNG.
`
let {thumbnails} = await ig.live.getPostLiveThumbnails(broadcastId)
let file = await new Promise((resolve) => https.get(thumbnails[0],(download) => {
let ds = [];
download.on("data",(d) => ds.push(d));
download.on("end",() => resolve(Buffer.concat(ds)))
}))
file = await sharp(file)
.resize(1080, 1920)
.png()
.toBuffer()
file = await pngToJpeg({quality: 100})(file)
let upload = await ig.upload.photo({file})
await ig.live.addPostLiveToIgtv({broadcastId: broadcastId, title: "Some title", description: "Some description", coverUploadId: upload.upload_id, igtvSharePreviewToFeed: 1})
`
FYI @tyghaykal

I just found a solution for the 500 error... It was just the cover upload format, it must be 1080x1920, a vertical thumbnail...
I used "sharp" to resize the PNG.
`
let {thumbnails} = await ig.live.getPostLiveThumbnails(broadcastId)
let file = await new Promise((resolve) => https.get(thumbnails[0],(download) => {
let ds = [];
download.on("data",(d) => ds.push(d));
download.on("end",() => resolve(Buffer.concat(ds)))
}))
file = await sharp(file)
.resize(1080, 1920)
.png()
.toBuffer()
file = await pngToJpeg({quality: 100})(file)
let upload = await ig.upload.photo({file})
await ig.live.addPostLiveToIgtv({broadcastId: broadcastId, title: "Some title", description: "Some description", coverUploadId: upload.upload_id, igtvSharePreviewToFeed: 1})
`
FYI @tyghaykal

after using your code i got : POST /api/v1/live/add_post_live_to_igtv/ - 404 Not Found;
at Request.handleResponseError (/Users/youssef/Workspace/Web projects/InstagramLive/live-stream-interface/igAPI/node_modules/instagram-private-api/dist/core/request.js:102:20)
at Request.send (/Users/youssef/Workspace/Web projects/InstagramLive/live-stream-interface/igAPI/node_modules/instagram-private-api/dist/core/request.js:53:28)
at async LiveRepository.addPostLiveToIgtv (/Users/youssef/Workspace/Web projects/InstagramLive/live-stream-interface/igAPI/node_modules/instagram-private-api/dist/repositories/live.repository.js:214:26)
at async IgClient.savetoIGTV (/Users/youssef/Workspace/Web projects/InstagramLive/live-stream-interface/igAPI/igClass.js:218:5)
at async IgClient.stopbroadcast (/Users/youssef/Workspace/Web projects/InstagramLive/live-stream-interface/igAPI/igClass.js:232:27)

love to know that, i will test it later on my project, thanks alot bro.


Update helm.md

README should link to opendistro-build
Description of changes:
Doc update to correct old link.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Thanks a bunch @drewmarshburn!


ArcticDB v5.1.1

Checklist

[x] Used a personal fork of the feedstock to propose changes
[ ] Bumped the build number (if the version is unchanged)
[x] Reset the build number to 0 (if the version changed)
[x] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

Check for py < 3.9 removed as per this comment

@conda-forge-admin, please rerender

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found it was in an excellent condition.
I do have some suggestions for making it better though...
For recipe/meta.yaml:

ℹ The recipe is not parsable by parser conda-souschef (grayskull). Your recipe may not receive automatic updates and/or may not be compatible with conda-forge's infrastructure. Please check the logs for more information and ensure your recipe can be parsed.

This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/12164249036. Examine the logs at this URL for more detail.


20230130

Copied from "https://github.com/ocello3/playground/tree/main/src/20230115"
In the above sketch, additive synthesis was used to create sound. In this sketch, another synthesis method is to be tested.

[ ] list available params for synthesis
[ ] consider alternative synthesis method

available params
rect.rates

pairIndex
rectIndex
area


Write unit and integration tests.

Hello,
I really liked and like to contribute to this project and I'll keep an eye to inform unit tests according to new developments and merges, so even if integration tests are implemented the issue can't be closed but only as the last one. As for the integration tests I leave some placeholder test classes with rest assured library if wanted and needed in order for someone else to implement them as I'm not an expert for this.
Thanks,
Panagiotis

@panagiotisbellias
Thanks for your input and efforts on the unit tests. Your contributions are appreciated.

@jcilacad Can you tell me how you run the new integration tests in order to automate their execution in CI workflow?

@panagiotisbellias The mvn command to run the integration tests is mvn failsafe:integration-test.

Utilize TestConstants class for integration testing.

@panagiotisbellias The mvn command to run the integration tests is mvn failsafe:integration-test.

@panagiotisbellias I forgot to mention, for it to work, the Docker service must also be running.

Nice

I think this can be closed since test execution is automated


CoreFx is being built twice with the second being built as portable

Per @weshaggard:

The second build is intended to build NETStandard.Library.NETframework support package that the SDK consumes.
For the second leg we don't actually need to do the native build at all.
There are two fixes that come to mind. First we call build-managed.sh directly for the netframework leg. Or we pass in portable=false for that leg to at least let the native build happen the same way.

The second build being native-portable removes direct linking to libs.
/cc @omajid

cc @aslicerh

In my quick tests, this works:
diff -ruN dotnet/targets/corefx.targets dotnet/targets/corefx.targets
--- dotnet/targets/corefx.targets   2017-10-25 20:40:18.000000000 -0400
+++ dotnet/targets/corefx.targets   2017-11-10 12:39:18.045215772 -0500
@@ -16,7 +16,7 @@

   <Target Name="BuildNetStandardLibraryNetFramework"
           BeforeTargets="Package">
-    <Exec Command="$(ProjectDirectory)/build$(ShellExtension) -$(Configuration) -Framework=netfx -OSGroup=Windows    _NT -- /p:ILLinkTrimAssembly=false"
+    <Exec Command="$(ProjectDirectory)/build$(ShellExtension) -$(Configuration) -Framework=netfx -OSGroup=Windows    _NT -portable=false -- /p:ILLinkTrimAssembly=false"
           WorkingDirectory="$(ProjectDirectory)"
           EnvironmentVariables="@(EnvironmentVariables)" />
   </Target>

The build log then contains:
/builddir/build/BUILD/dotnet/src/corefx/build.sh -Release -Framework=netfx -OSGroup=Windows_NT -portable=false -- /p:ILLinkTrimAssembly=false
Tools are already initialized
Running: /builddir/build/BUILD/dotnet/src/corefx/src/Native/build-native.sh  --TargetGroup=netfx --OSGroup=Windows_NT  x64  Release  Linux  --numproc 32  false  toolSetDir=c:\tools\clr /p:ILLinkTrimAssembly=false
/builddir/build/BUILD/dotnet/src/corefx/src/Native/build-native.sh: line 369: lsb_release: command not found
Setting up directories for build
Checking pre-requisites...
Commencing build of corefx native components for Linux.x64.Release
Invoking cmake with arguments: "/builddir/build/BUILD/dotnet/src/corefx/src/Native/Unix" RELEASE  -DFEATURE_DISTRO_AGNOSTIC_SSL=0 -DCMAKE_STATIC_LIB_LINK=0

This is the second invocation, and since the configuration is identical to the first invocation, nothing is rebuilt via cmake.

I approve of setting portableBuilds=false. Do we need to prevent the second invocation?

Thansk @omajid

/builddir/build/BUILD/dotnet/src/corefx/src/Native/build-native.sh: line 369: lsb_release: command not found

Is that error always there and ignored?

Is that error always there and ignored?

Hm. This is really the first time I have noticed this error. But the way we build code in the Fedora buildsystem, we always start with a fresh "system", if you will, so yeah, this has always been missing.

That will eventually go away as we are moving our branches to 3.9 for everything so I guess as long as it isn't blocking anything we can safely ignore it.

@crummel Please fix this for 2.0.4

https://github.com/dotnet/source-build/pull/302 fixes this, hopefully.

It looks like this has been fixed and ported to all required branches.


dataclass and decorators for gfx.show

While improving show in #380 I made two suggestions that we may want to track for future reference:
First, we could consider wrapping gfx.show into a dataclass:
@dataclass
class Display:
    canvas: object = None
    renderer: gfx.Renderer = None
    camera: gfx.Camera = None
    ...

    def show(self, scene, up):
        ...

This way we can create a disp = Display() that can be customized as the program executes. We then only need to call disp.show(scene) in the end. This would make managing a custom setup easier, as we have all the data in one object instead of having to manually track multiple objects.
Secondly, we could consider creating a decorator for the callback functions that can be set in gfx.show. I.e., instead of calling gfx.show(scene, before_render=animate) we would do:

@gfx.show.before_render
def animate():
    ...

# calls `animate` before rendering
gfx.show()

This would mostly be syntactic sugar and make our life a bit easier. The downside of this is that it introduces global state for gfx.show, since we would have to track the callback once it was registered.

Interesting idea, it's somewhat similar to how I thought about the Subplot class in fastplotlib.
Do you think camera should be part of Display, it is possible to have multiple scenes and cameras (with viewports) on the same canvas using the same renderer.


MathJax.SVG.Augment.initSVG not called

I have just upgraded to mathjax-node-page. Part of my configuration includes a MathJax.SVG.Augment.initSVG override (mostly used to monkey-patch lookupChar). In general the configuration seems to work, but this method does not appear to be called (however I am not getting missing glyph warnings either).
Is that an expected new behaviour?

Part of my configuration includes a MathJax.SVG.Augment.initSVG override

You are referring to https://github.com/mathjax/MathJax/issues/1091#issuecomment-269653429, right?

Is that an expected new behaviour?

Hm... sounds like a bug. I'll take a look.

After chasing it around a bit, I think this is a simple bug but I'll double check.

Yes, that is indeed the use case. However bumping to 1.2.7 does not seem to address the issue. I have:
  mjpage(
    jsdom.serializeDocument(document),
    {
      format: 'MathML',
      MathJax: {
        SVG: {
          font:             'STIX-Web',
          useGlobalCache:   false,
          undefinedFamily:  '"Arial Unicode MS", Arial, sans-serif',
          Augment: {
            initSVG () {
              console.log('INITING');
              // ...
            }
          }
        },
      },
    },
    {
      svg:            true,
      useGlobalCache: false,
    },
    (result) => {
      jsdom.env(result, (err, win) => {
         // ...
      });
    }
  );

But the console.log never shows. It seems like the configuration is taking place but the init is still not being called.

Hm. Works for me. https://runkit.com/58ad7e09f01e9600147143f3/58f63a39f41b5b001249bc34

@darobin did this resolve for you as well?


JSON errors get escaped

I have a simple API
  class Root < Grape::API
    content_type :json, 'application/json; charset=UTF-8'
    default_format :json

    rescue_from ActiveRecord::RecordNotFound do
      error!({ error: :not_found }, 404)
    end
  end

When an ActiveRecord::RecordNotFound is raised, I expect my API returns "{"error":"not_found"} as JSON, but it retures {"error":"not_found"}
It worked well in 1.0.3 version but broken in 1.1.0
Is there any workaround for it?
It's related to #1763

What is the content-type returned in the error response @Kukunin? I am going to guess it's text/plain.
Your default format for when the content type is not specified is json, but your default format otherwise is not. Without testing, I would try either adding format :json or default_error_formatter :json. Does that make a difference?

You were right. The content-type was 'text/html'. Replacing default_format :json to format :json helped, and not everything is fine

Happy to help. Let's close this.


Add nullValue being respected when parsing CSVs

This change makes it so that we look for a user specified nullValue
through the CSV parsing. This allows for handling CSVs that might use
something else other than an empty string to represent nulls.
It reuses the same flag as CSV saving, nullValue. This change should
be non-breaking.
This also pushes this behavior into inferSchema so that inferred schemas
will properly reflect the user given null value.

Current coverage is 85.82%

Merging #224 into master will not affect coverage as of 16070f3

@@            master    #224   diff @@
======================================
  Files           11      11
  Stmts          501     501
  Branches       148     148
  Methods          0       0
======================================
  Hit            430     430
  Partial          0       0
  Missed          71      71

Review entire Coverage Diff as of 16070f3

Powered by Codecov. Updated on successful CI builds.

Just now noticed #76 does the same thing :facepalm:
It seems like that is pretty stale and might mess with inferSchema for those cases... But does accept a range of null values (not sure how likely it is that a single CSV will have multiple types of null?)
But as is mentioned in that PR and in other things, it really seems like this should be a part of CSV handling as we have large CSV files where it would be too expensive to remap just for remapping nulls.

Thanks @addisonj this looks good. I am going to merge it.

Thanks! Currently running from a fork, any ETA on when you will be cutting a new release?

Is this part of release?

Not working on Databricks notebook.. I tried to load csv data with ? as null values.

So this seems to still not be working in 2.0.0?


update Russian translation

Coverage remained the same at 92.775% when pulling 483923f50af07b661e8ea51de326f2ba55db9491 on DDDIM:staging into 008ff5203e41fc2fcda1aa29328dc247b9c0dbd1 on FarmBot:staging.

Thanks!


Feature request: deployment to other desktop environments

First of all, I'm a non-programmer Gnu/Linux user, so excuse me if what I'm asking is too much.
I have been seeing your QRedshift manager and I think it's one of the greatest tools anyone could find for any desktop, but for non-Cinnamon users it's a shame not having it. I, myself, use Xfce and would love to have it on my notification area, tray.
(Excuse my english)
Thanks.

Maybe some day.... Needs to rewrite everything from scratch...


If a scan is 70m, then how come 100m or 120m will take only 1 scan?

This is related to:
https://github.com/favll/pogom/issues/298
So when we add a series of locations along a long road (which is about 1000m), should be just add about 10 locations that are 100m radius, or 8 or 9 locations that are 120m radius?
If one scan is only or 70m radius, how come it can cover 100m or 120m?

Please stick to the issues you already opened.


copy&paste not working in fields (and objects)

copy&paste not working in fields (and objects)
on Mac OSX Yosemite (10.10.5)

Hello @bartoleo.
Could you please specify the place where copy & paste don't work ?

All property fields (right panel)
Inside tasks
On objects (tasks, events, gateways... etc)

I found this post about electron & clipboard...
http://www.pracucci.com/atom-electron-enable-copy-and-paste.html


Multiple cookies are not set on endpoints

… #3460

[fix] can no longer return multiple set-cookie headers from endpoints

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

[x] It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
[x] This message body should clearly illustrate what problems it solves.
[x] Ideally, include a test that fails without this PR but passes with it.

Tests

[x] Run the tests with pnpm test and lint the project with pnpm lint and pnpm check

Changesets

[x] If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running pnpx changeset and following the prompts. All changesets should be patch until SvelteKit 1.0

thanks!


Add property variantName to KoverReport interface

What is your use-case and why do you need this feature?
Property variantName will help to filter Kover tasks by selecting those that relate to specific variant.
So, to find the HTML report for debug Android build variant:
tasks.withType<KoverHtmlReport>().matching {
    it.variantName == "debug"
}

Implemented in 0.8.0


Signable

Replace TypedData, Message with EthereumMessage, EthereumTypedMessage both implementing Signable interface.
I carefully tweaked and repushed a few times to make sure this one is mergeable to actvity-refactor.

Merge path:

activity-refactor
this-one
either make a new PR from signable-stage-2 to master, or merge this one  https://github.com/AlphaWallet/alpha-wallet-android/pull/1562 then merge from activity-refactor again to master

(travis expected to fail between 2 and 3 despite both 2 and 3 pass travis by themselves)

Have you tested this signing transactions from dapp? Places to check are:
http://thetokenfactory.com
https://tf.alphawallet.com

Highlight:
[quote]
Merge path:

activity-refactor
this-one
either make a new PR from signable-stage-2 to master, or merge this one  https://github.com/AlphaWallet/alpha-wallet-android/pull/1562 then merge from activity-refactor again to master

(travis expected to fail between 2 and 3 despite both 2 and 3 pass travis by themselves
[/quote]


Some keyboards don't have home and end keys

Some smaller keyboards, e.g. on laptops don't have home and end keys.

I added an "h" and "e" key in addition to home and end keys for jumping to the beginning and end of a screen.


Tooo Slow

Bug description
I did try loading the Vicuna model
Steps to reproduce
Good news that it did work
Bad news is that it takes up to minutes to write words
Environment Information
I have a Ryzen 3600 and 16gb ddr4 ram
Screenshots
No response
Relevant log output
No response
Confirmations

[X] I'm running the latest version of the main branch.
[X] I checked existing issues to see if this has already been described.

What OS are you using ?

Win 11

Using docker with WSL2 ?
Also if the model is too big for your memory (which could be the case, 16GB + win 11 + a 13B model), then the model would be loaded in swap which depending on your hard drive could slow everything to a crawl.
Can you try using the 7B-native model for example, to see if you get better performance? Please monitor your memory usage when running the model, if it ever hits the limit and uses swap then you're out of luck.

Yes I did install docker and wsl2
Ok I will try a 7b model with this repo
(I did try the gpt4all repo already and it did work pretty well)
Also I have a nvme gen 3
Can I force it to load their instead of the hdd?

Using docker with WSL2 ?
Also if the model is too big for your memory (which could be the case, 16GB + win 11 + a 13B model), then the model would be loaded in swap which depending on your hard drive could slow everything to a crawl.
Can you try using the 7B-native model for example, to see if you get better performance? Please monitor your memory usage when running the model, if it ever hits the limit and uses swap then you're out of luck.

This is a comparison between vicuna on lamma cpp and serge
gpt4all does work fine with serge tho
https://user-images.githubusercontent.com/117460296/230155599-3c0ec82b-8b7d-477a-97ff-4d5c18f8b31a.mp4
https://user-images.githubusercontent.com/117460296/230155807-547d136a-6317-48f6-8cfd-3522e567e7b1.mp4

@Gyro0o Can you try the latest image and check if there's any difference? Also, does your CPU support AVX2 ?

@gaby  Seems like AMD doesn't publish whether or not the Ryzen 5 3600 has AVX2, but multiple sites report it does:
https://www.techpowerup.com/cpu-specs/ryzen-5-3600.c2132
I've seen a couple of sites report that Ryzen's FPU is half the width of Intel's for AVX2, so peak throughput may be lower than Intel's: https://www.reddit.com/r/Amd/comments/7s8grk/an_inane_question_about_avx2_and_ryzen/
########
@Gyro0o A fair amount has changed since you last posted, not a HUGE amount, but it may make a difference. Is it still exceedingly slow?

Xeon E5-2630L V4 10cores (AVX2 supported) + 256GB RAM + Alpaca 30B or Open Assistant 30B takes about 2-3 minutes to begin generate response and few seconds for every single word. It's veeeeeeeeeeeryyy sloooooowww...

@QBANIN This is a llama.cpp issue,  not Serge. May wanna open an issue there

im using dual CPU E5-2630 v3 @ 2.40GHz. Its very slow. Is there a way to use gpu? I have a titan black and a 980ti that can be dedicated. Is it possible?

Now gpu is supporten?

Not yet


Added functionality to handle unseen levels in MeanResponseTransformer

Added functionality to handle unseen levels in MeanResponseTransformer. User can choose on of the following unseen_levels for imputing unseen levels : 'Mean', 'Median', 'Lowest', 'Highest' or can provide an arbitrary int/float value to impute all unseen levels. The default value of 'None' will output error if the data to use transform on contains unseen levels.

Thanks for the contribution Ritunjai! There are a few things to add before this can be merged in:

add testing of new functionality
update the changelog with the change (add in a 0.3.5 unreleased section please as explained in the changelog doc)
add an example to the example notebook for this transformer

I have updated changelog to include 0.3.5 unreleased section in commit 7993cbc

a note on tests - We are looking to remove tests on implementation and just focus on testing functionality.  Current testing of implementation can inflate coverage.  Please delete the following rather than updating:
test_arguments
test_inheritance
test_class_methods
test_xxxx_called (with exception of test_super_init_called as this covers some error handling)

Thanks for the note on tests. Will delete the required tests.

I have added code for testing unseen level handling in the commit: d28550e
I have also added an example of how to use the unseen level handling functionality in the example notebook in the commit: 4be9961

Please add in some testing that self.unseen_levels_encoding_dict is correctly populated in fit.  Currently only testing as part of the full fit transform cycle outputs.

please update the version in version.py to 0.3.5

Hi! I have re-added the required tests, added testing to ensure that unseen_levels_encoding_dict is correctly populated in fit and updated version.py to 0.3.5 in commit  e614207


(user profiles) create sample user profile page

Closing Statement:
This task is done. Implemented fixture file with sample users, including an admin user.

Issue Score: Satisfactory
Comments:
Good fixture that was super helpful for testing. This issue spanned sprint 1 and 2, and there's no description, so I'm giving it a satisfactory.


Show secundary spans for errors

Especially for borrowck errors it is very hard to see the problem by just looking at the primary error message and span. For those the secondary error messages and spans (those with -- instead of ^^) are often necessary to understand the error.
Another option would be to show the rendered error as computed by rustc.

Would DiagnosticRelatedInformation https://microsoft.github.io/language-server-protocol/specifications/specification-current/#diagnostic help?

We already provide the related information based on secondary spans from cargo, so in editors supporting showing those in a meaningful way that helps.
I'd be open to showing the full error message on hover, if that is possible, but doing it in the problems pane is problematic if the editor is using a non-monospace font.

Add an option so it can be disabled if needed.
Another way might be to show the cargo check output in a dedicated terminal.

Another way might be to show the cargo check output in a dedicated terminal.

Showing the cargo check output directly won't work, as we request the output to be formatted as json to be able to parse it much more easily.

It's still not obvious, but we now show these:

It's still not obvious, but we now show these:


Bit of proposed re-organization to let things grow out conceptually

Since this could be quickly going down a few paths involving a bit more complexity (e.g.: stdin efficiency, abstractions on adding/managing templates via YAML or something); I thought maybe re-organizing the package a bit into more distinct components might be useful?

Is there a reason to nest it under /pkg/templating vs just /templating?
My next steps (after fixing bugs I thought of last night) was going be adding a directory for the exe code so I can test the input into the exe. That wouldn't belong in the pkg directory I don't think?

Idea behind the pkg/ convention is to keep the root file space intuitive. Anything in pkg is going to be go code (a common convention). Supposin you wanted to add a directory called 'config' or 'templates' that was not really go centric - you gotta ferret them away somewhere, and IMHO putting them in with go code is kinda ... ugly.
As a codebase grows it gets a bit more difficult to grok structurally:
tgrep/parser
may someday turn into:
tgrep/config/parser
tgrep/template/parser

or (this wouldn't be smart given config and template parsing would be different beasts):
tgrep/parser/config
tgrep/parser/template

The other thing I noticed is that tgrep -is- your module already.
Thus the code shows up like this now:
import (
	...
	"github.com/oliverisaac/tgrep/tgrep"
)

If you consider how that may look as things grow:
Keep everything under tgrep directory in code root:
import (
	...
	"github.com/oliverisaac/tgrep/tgrep/template/parser",
        "github.com/oliverisaac/tgrep/tgrep/config/parser"
)

or, directories under the code root - which looks good with the exception of polluting the directory as described above:
import (
	...
	"github.com/oliverisaac/tgrep/template/parser",
        "github.com/oliverisaac/tgrep/config/parser"
)

with the pkg path, it turns into this, which is really close to above, just trades off the addition of the extra directory to keep your root directory more flexible:
import (
	...
	"github.com/oliverisaac/tgrep/pkg/template/parser",
        "github.com/oliverisaac/tgrep/pkg/config/parser"
)

There is another option of flipping it on it's head, whereby the convention is that all directories can/should contain go code under the code base root directory, but then you'll likely need to hunt out an exception process for things that are assets of sorts, e.g.: yaml/config files, etc.
Ok... maybe I just have OCD...

For the exe part I'm assuming you're talking about the stdin reading? It could very much so be a part of a parsing or streams or io "package".

Something that go into my head was a YAML format to define the regex templates, e.g.:
templates:
- name: ipv4
  template: ([1334].regex)
  tests:
  - it: "Should match 4 octets"
    passingInputs:
      - "<IP_ADDRESS>"
      - "<IP_ADDRESS>"
    failingInputs:
      - "2<IP_ADDRESS>"
      - "<IP_ADDRESS>.1"
      - "shit"
      - "one.two.three.four"

We could slurp it into a type and use it to generate help output, e.g.: "available built-in templates", and drive the tests.
Then, we could eventually introduce a flag to allow someone to extend with their own templates in this format.

Oh! One last thing , you could also do 'internal':
https://github.com/golang-standards/project-layout

Okay, cool, that all makes sense. If you merge in origin/main this should be mergable :)

I love the idea of a yaml file to define the templates and generating the code/tests for that. Would be a super clean way to handle all of it :)


CPU limit not shown under status field

Hi,
I am testing the kube-startup-cpu-boost operator on my macbook pro m1 max with minikube (version  v1.34.0). I can confirm the kubernetes version in the reply.  The operator is install with the following command with the default settings
kubectl apply -f https://github.com/google/kube-startup-cpu-boost/releases/download/v0.11.0/manifests.yaml

I am aware the kube-startup-cpu-boost would take out the CPU limit during boosting time because REMOVE_LIMITS  was set to true by default. The boost seems working fine and the startup time was only 50% with 100% CPU boost. Everything works fine!
The boost object:
spec:
  durationPolicy:
    podCondition:
      status: 'True'
      type: Ready
  resourcePolicy:
    containerPolicies:
      - containerName: ...
        percentageIncrease:
          value: 100

The only question is that after the boost time, the CPU limit should go back to the pod definition and it did.  However, when we look at the status section, the CPU limit is not there. I am not sure if kubernetes is actually using the CPU limit.
❯ kubectl get pod ... -o yaml
apiVersion: v1
kind: Pod
....
  containers:
 ...
    resizePolicy:
    - resourceName: cpu
      restartPolicy: NotRequired
    - resourceName: memory
      restartPolicy: NotRequired
    resources:
      limits:
        cpu: "1"     <---- CPU limit is set
        memory: 1Gi
      requests:
        cpu: 500m
        memory: 1Gi
    ...
status:
  ...
  containerStatuses:
  - allocatedResources:
      cpu: 500m
      memory: 1Gi
...
    lastState: {}
    name: ...
    ready: true
    resources:
      limits:      <----  not showing CPU limit
        memory: 1Gi
      requests:
        cpu: "1"
        memory: 1Gi
    restartCount: 0
...
  resize: InProgress...

Kubernetes version should be V1.31
❯ kubectl version
...
Server Version: v1.31.0

Hi @alexchauhk, thanks for the question - thats a valid observation.
Indeed the kube-startup-cpu-boost operator seems to be working fine as the CPU resource limit is back in the POD's definition.
Apparently the limit was not yes re-established by the Kubernetes.
Given that resize: InProgress.., can you please verify if limit will be present after resize is done ?

Hi @mikouaj ! Thanks for the reply.
I have given 100% boost until the pod is ready. While the default setting of REMOVE_LIMITS is true. I believe what will happen is CPU limit will be taken away until the pod become ready again.
The above snapshot was token when the pod is ready.
The resize status get stuck in resize: InProgress.. even after the pod is ready. Feels like something is not quite right.
I can confirm that before the pod is ready, the container spec doesn't have the CPU limit. It should be added after the pod became ready.

I have set the feature flag REMOVE_LIMITS to false. I can see the resources are being doubled. Even the pod is ready, the resize still get stuck in "InProgress" and the resources are still in doubled (Normally, it should request 0.5 CPU and limit 1 CPU). Is my durationPolicy incorrect?
  - allocatedResources:
      cpu: 500m
      memory: 1Gi
...
    lastState: {}
    name: ...
    ready: true
    resources:
      limits:
        cpu: "2"
        memory: 1Gi
      requests:
        cpu: "1"
        memory: 1Gi
...
  qosClass: Burstable
  resize: InProgress
  startTime: "2024-12-06T14:16:07Z"

@alexchauhk do you know which container runtime is used by your minicube cluster?
Can you try with containerd ? (minikube start --container-runtime=containerd)
The in-place pod resource resize feature is still in alpha state and may be not working well with all container runtimes.
Some extra care may be needed for minikube / docker desktop on MacOS.

I am using docker as the driver. It should be using containerd as the underlying runtime. I will try containerd and report back.
minikube start --driver=docker --cpus 8 --memory 8192 --feature-gates=InPlacePodVerticalScaling=true --insecure-registry "<IP_ADDRESS>/24"
❯ docker version
Client:
Version:           27.3.1
API version:       1.47
Go version:        go1.22.7
Git commit:        ce12230
Built:             Fri Sep 20 11:38:18 2024
OS/Arch:           darwin/arm64
Context:           default
Server: Docker Engine - Community
Engine:
Version:          27.2.0
API version:      1.47 (minimum version 1.24)
Go version:       go1.21.13
Git commit:       3ab5c7d
Built:            Tue Aug 27 14:15:32 2024
OS/Arch:          linux/arm64
Experimental:     false
containerd:
Version:          1.7.21
GitCommit:        472731909fa34bd7bc9c087e4c27943f9835f111
runc:
Version:          1.1.13
GitCommit:        v1.1.13-0-g58aa920
docker-init:
Version:          0.19.0
GitCommit:        de40ad0

After switching to containerd as container runtime. Minikube is no longer able to run any amd64 image now.
The biggest issue here is not having the kube-startup-cpu-boost image on the arm64 platform. For the testing container, i can replace them with a simple nginx deployment.
❯ docker pull --platform linux/arm64 ghcr.io/google/kube-startup-cpu-boost
Using default tag: latest
latest: Pulling from google/kube-startup-cpu-boost
Digest: sha256:ae5537d3daeb4d5c7aa6659da2230d00dc5d55615eee234b715488e058f9ef01
Status: Downloaded newer image for ghcr.io/google/kube-startup-cpu-boost:latest
image with reference ghcr.io/google/kube-startup-cpu-boost:latest was found but does not match the specified platform: wanted linux/arm64, actual: linux/amd64

I'm working on adding multi-platform docker images to the project to support arm64 as well.

The arm64 is supported by kube-startup-cpu-boost container images from v0.11.2.
docker pull --platform linux/arm64 ghcr.io/google/kube-startup-cpu-boost:v0.11.2
or just use latest tag:
docker pull --platform linux/arm64 ghcr.io/google/kube-startup-cpu-boost

Thanks @mikouaj ! I will try again and report back.

Looks like it works very well with containerd! Thank you so much @mikouaj !
Policy:
apiVersion: autoscaling.x-k8s.io/v1alpha1
kind: StartupCPUBoost
metadata:
  name: nginx-cpu-boost
selector:
  matchExpressions:
  - key: app
    operator: In
    values: ["nginx"]
spec:
  resourcePolicy:
    containerPolicies:
    - containerName: nginx
      percentageIncrease:
        value: 100
  durationPolicy:
    podCondition:
      type: Ready
      status: "True"

Pod:
❯ k get pod nginx-deployment-d8686b57f-sv5gt -o yaml
apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: "2024-12-18T11:51:52Z"
  generateName: nginx-deployment-d8686b57f-
  labels:
    app: nginx
    pod-template-hash: d8686b57f
  name: nginx-deployment-d8686b57f-sv5gt
  namespace: default
  ownerReferences:
  - apiVersion: apps/v1
    blockOwnerDeletion: true
    controller: true
    kind: ReplicaSet
    name: nginx-deployment-d8686b57f
    uid: bd3800d7-a96d-4d34-9f2c-1c4d88aaa6c8
  resourceVersion: "16689"
  uid: 4a46f2f2-3f3e-4f5e-acd8-97c9417d064a
spec:
  containers:
  - image: nginx:1.14.2
    imagePullPolicy: IfNotPresent
    name: nginx
    ports:
    - containerPort: 80
      protocol: TCP
    resizePolicy:
    - resourceName: cpu
      restartPolicy: NotRequired
    - resourceName: memory
      restartPolicy: NotRequired
    resources:
      limits:
        cpu: 500m
        memory: 128Mi
      requests:
        cpu: 250m
        memory: 64Mi
    terminationMessagePath: /dev/termination-log
    terminationMessagePolicy: File
    volumeMounts:
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: kube-api-access-6t2lp
      readOnly: true
  dnsPolicy: ClusterFirst
  enableServiceLinks: true
  nodeName: minikube
  preemptionPolicy: PreemptLowerPriority
  priority: 0
  restartPolicy: Always
  schedulerName: default-scheduler
  securityContext: {}
  serviceAccount: default
  serviceAccountName: default
  terminationGracePeriodSeconds: 30
  tolerations:
  - effect: NoExecute
    key: node.kubernetes.io/not-ready
    operator: Exists
    tolerationSeconds: 300
  - effect: NoExecute
    key: node.kubernetes.io/unreachable
    operator: Exists
    tolerationSeconds: 300
  volumes:
  - name: kube-api-access-6t2lp
    projected:
      defaultMode: 420
      sources:
      - serviceAccountToken:
          expirationSeconds: 3607
          path: token
      - configMap:
          items:
          - key: ca.crt
            path: ca.crt
          name: kube-root-ca.crt
      - downwardAPI:
          items:
          - fieldRef:
              apiVersion: v1
              fieldPath: metadata.namespace
            path: namespace
status:
  conditions:
  - lastProbeTime: null
    lastTransitionTime: "2024-12-18T11:51:53Z"
    status: "True"
    type: PodReadyToStartContainers
  - lastProbeTime: null
    lastTransitionTime: "2024-12-18T11:51:52Z"
    status: "True"
    type: Initialized
  - lastProbeTime: null
    lastTransitionTime: "2024-12-18T11:51:53Z"
    status: "True"
    type: Ready
  - lastProbeTime: null
    lastTransitionTime: "2024-12-18T11:51:53Z"
    status: "True"
    type: ContainersReady
  - lastProbeTime: null
    lastTransitionTime: "2024-12-18T11:51:52Z"
    status: "True"
    type: PodScheduled
  containerStatuses:
  - allocatedResources:
      cpu: 250m
      memory: 64Mi
    containerID: containerd://6bd9bdb6dd6ad1989f28d1c10943a3d9cf06e9bd87e90a0693daae5ad4d4cd5b
    image: docker.io/library/nginx:1.14.2
    imageID: docker.io/library/nginx@sha256:f7988fb6c02e0ce69257d9bd9cf37ae20a60f1df7563c3a2a6abe24160306b8d
    lastState: {}
    name: nginx
    ready: true
    resources:
      limits:
        memory: 128Mi
      requests:
        cpu: 500m
        memory: 64Mi
    restartCount: 0
    started: true
    state:
      running:
        startedAt: "2024-12-18T11:51:53Z"
    volumeMounts:
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: kube-api-access-6t2lp
      readOnly: true
      recursiveReadOnly: Disabled
  hostIP: <IP_ADDRESS>
  hostIPs:
  - ip: <IP_ADDRESS>
  phase: Running
  podIP: <IP_ADDRESS>
  podIPs:
  - ip: <IP_ADDRESS>
  qosClass: Burstable
  resize: InProgress
  startTime: "2024-12-18T11:51:52Z"

  =====

  a minute later:

  ❯ k get pod nginx-deployment-d8686b57f-sv5gt -o yaml
apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: "2024-12-18T11:51:52Z"
  generateName: nginx-deployment-d8686b57f-
  labels:
    app: nginx
    pod-template-hash: d8686b57f
  name: nginx-deployment-d8686b57f-sv5gt
  namespace: default
  ownerReferences:
  - apiVersion: apps/v1
    blockOwnerDeletion: true
    controller: true
    kind: ReplicaSet
    name: nginx-deployment-d8686b57f
    uid: bd3800d7-a96d-4d34-9f2c-1c4d88aaa6c8
  resourceVersion: "16850"
  uid: 4a46f2f2-3f3e-4f5e-acd8-97c9417d064a
spec:
  containers:
  - image: nginx:1.14.2
    imagePullPolicy: IfNotPresent
    name: nginx
    ports:
    - containerPort: 80
      protocol: TCP
    resizePolicy:
    - resourceName: cpu
      restartPolicy: NotRequired
    - resourceName: memory
      restartPolicy: NotRequired
    resources:
      limits:
        cpu: 500m
        memory: 128Mi
      requests:
        cpu: 250m
        memory: 64Mi
    terminationMessagePath: /dev/termination-log
    terminationMessagePolicy: File
    volumeMounts:
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: kube-api-access-6t2lp
      readOnly: true
  dnsPolicy: ClusterFirst
  enableServiceLinks: true
  nodeName: minikube
  preemptionPolicy: PreemptLowerPriority
  priority: 0
  restartPolicy: Always
  schedulerName: default-scheduler
  securityContext: {}
  serviceAccount: default
  serviceAccountName: default
  terminationGracePeriodSeconds: 30
  tolerations:
  - effect: NoExecute
    key: node.kubernetes.io/not-ready
    operator: Exists
    tolerationSeconds: 300
  - effect: NoExecute
    key: node.kubernetes.io/unreachable
    operator: Exists
    tolerationSeconds: 300
  volumes:
  - name: kube-api-access-6t2lp
    projected:
      defaultMode: 420
      sources:
      - serviceAccountToken:
          expirationSeconds: 3607
          path: token
      - configMap:
          items:
          - key: ca.crt
            path: ca.crt
          name: kube-root-ca.crt
      - downwardAPI:
          items:
          - fieldRef:
              apiVersion: v1
              fieldPath: metadata.namespace
            path: namespace
status:
  conditions:
  - lastProbeTime: null
    lastTransitionTime: "2024-12-18T11:51:53Z"
    status: "True"
    type: PodReadyToStartContainers
  - lastProbeTime: null
    lastTransitionTime: "2024-12-18T11:51:52Z"
    status: "True"
    type: Initialized
  - lastProbeTime: null
    lastTransitionTime: "2024-12-18T11:51:53Z"
    status: "True"
    type: Ready
  - lastProbeTime: null
    lastTransitionTime: "2024-12-18T11:51:53Z"
    status: "True"
    type: ContainersReady
  - lastProbeTime: null
    lastTransitionTime: "2024-12-18T11:51:52Z"
    status: "True"
    type: PodScheduled
  containerStatuses:
  - allocatedResources:
      cpu: 250m
      memory: 64Mi
    containerID: containerd://6bd9bdb6dd6ad1989f28d1c10943a3d9cf06e9bd87e90a0693daae5ad4d4cd5b
    image: docker.io/library/nginx:1.14.2
    imageID: docker.io/library/nginx@sha256:f7988fb6c02e0ce69257d9bd9cf37ae20a60f1df7563c3a2a6abe24160306b8d
    lastState: {}
    name: nginx
    ready: true
    resources:
      limits:
        cpu: 500m
        memory: 128Mi
      requests:
        cpu: 250m
        memory: 64Mi
    restartCount: 0
    started: true
    state:
      running:
        startedAt: "2024-12-18T11:51:53Z"
    volumeMounts:
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: kube-api-access-6t2lp
      readOnly: true
      recursiveReadOnly: Disabled
  hostIP: <IP_ADDRESS>
  hostIPs:
  - ip: <IP_ADDRESS>
  phase: Running
  podIP: <IP_ADDRESS>
  podIPs:
  - ip: <IP_ADDRESS>
  qosClass: Burstable
  startTime: "2024-12-18T11:51:52Z"


Automate via PowerShell

Is there a way to automate this for 100's of resource groups or have the settings inherit down from a management group?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: caec76df-16e4-f418-14c3-6c83528134c7
Version Independent ID: 813b93bb-1b61-c31a-a277-0b56a3f51d4a
Content: Configure Azure resource role settings in Privileged Identity Management - Azure Active Directory
Content Source: articles/active-directory/privileged-identity-management/pim-resource-roles-configure-role-settings.md
Service: active-directory
Sub-service: pim
GitHub Login: @curtand
Microsoft Alias: curtand

@Roblarson Thank you for your query. We will check and update on this soon.

@Roblarson, see https://azsk.azurewebsites.net/01-Subscription-Security/Readme.html#azsk-privileged-identity-management-pim-helper-cmdlets.

@Roblarson Hope the above link helped. We will now close this issue. If you have further queries , please tag me to your reply or open a new issue referencing this one in case I am unavailable and the team will help you with the same.


Is it possible to integrate the Ackee with NextJS as inbuilt analytics.

I want to know if its possible to integrate ackee within a NextJS project as inbuilt analytics dashboard?

You can use Ackee in your Next.js projects (there's also a React hook available), but I'm not sure what you mean with "inbuilt analytics dashboard". If you want to show your Ackee statistics in your Next.js app then the API of Ackee might be what you're looking for. You however can't embed the dashboard of Ackee directly.


 Plug reports smth as temperature but it doesn't like smth related to real device or room temperature. Do you know the nature of that value?

my Xiaomi plug is out in the garden. The temperature that comes from that is almost a real value.
And if necessary, you can correct the temperature in Domoticz!
Would be cool if you would include it in your plug-in!

Available in latest plugin


Added Hand-written-character-recognition project

Description
This script scans the human handwritten character in the form of image, and tells which character is in that photo.
Fixes #1697

Type of change
Please delete options that are not relevant.

[X] New feature (non-breaking change which adds functionality)

Checklist:

[X] My code follows the style guidelines(Clean Code) of this project
[X] I have performed a self-review of my own code
[X] I have commented my code, particularly in hard-to-understand areas
[X] I have created a helpful and easy to understand README.md
[X] My documentation follows Template for README.md

Project Metadata
If there is no-file/nothing to fill the below fields with, then type: none
Example: If no requirements.txt needed/present, then type none in Requirments.
Category:

[ ] Calculators
[X] AI/ML
[ ] Scrappers
[ ] Social_Media
[ ] PDF
[X] Image_Processing
[ ] Video_Processing
[ ] Games
[ ] Networking
[ ] OS_Utilities
[ ] Automation
[ ] Cryptography
[X] Computer_Vision
[ ] Fun
[ ] Others

Title:  Handwritten_character_recog
Folder: Handwritten-Character-Recognition
Requirements: None
Script: Handwritten_character_recog.py
Arguments: None
Contributor: Mukesh751
Description: This project tells which character is in the input image (image will be of a alphabetical character written by human hand).

@avinashkranjan @Yashbhadiyadra @1e9abhi1e10 Please merge this PR, so that I can add more scripts and also add label for GSSOC'23.

Why are you tampering with Repo's README file

Why are you tampering with Repo's README file

I have fixed the conflicts and requested for new PR, please check #1984.


[FEATURE] Support CSI volume cloning

Describe the solution you'd like
Cloning support (VolumePVCDataSource) for the longhorn CSI driver, currently this is not implemented and returns the following error when trying to use it:
failed to provision volume with StorageClass "longhorn": CSI driver does not support clone operations: controller CLONE_VOLUME capability is not reported

Describe alternatives you've considered
Manually cloning the volume, e.g. attaching the old and new volume to the same pod and copying everything over. However this is cumbersome and inelegant.
I've also looked at the possiblity of creating a new volume from the backup of an existing volume, however this doesn't seem possible as of now (or at least I could not find out how to). If this is or could be possible I would also be satisfied.
Additional context
Here are some links to official documenation on the topic:

Official Documentation
Kubernetes CSI Developer documentation

@NULLx76 You can create a new volume from a backup of an existing volume. You can restore it from the backup into a new volume in Longhorn, then create PV/PVC for the volume, and finally use the PVC with the workload. You can see it from my demo at https://www.youtube.com/watch?v=zJY2uxLtwUk
I will still keep this open to track the volume cloning feature.

really wishing longhorn could do clone operation things.  i'm in the process of switching my cluster from local-storage volumes to longhorn, and was expecting (hoping) i could apply this solution: https://kubernetes.io/docs/concepts/storage/volume-pvc-datasource/

+1
I need to switch from local-path volumes (default in K3S), too.

+1
I need to switch from local-path volumes (default in K3S), too.

We currently don't support volume cloning, but for data migration we have an example kubernetes job that you can modify to copy the data from the local-path volume to the new longhorn volume.
https://github.com/longhorn/longhorn-manager/blob/master/examples/data_migration.yaml

We currently don't support volume cloning, but for data migration we have an example kubernetes job that you can modify to copy the data from the local-path volume to the new longhorn volume.
https://github.com/longhorn/longhorn-manager/blob/master/examples/data_migration.yaml

@joshimoo Do you know a way of using the data_migration.yaml copy/pasting from volumes in two different namespaces?

High Needed!!! Please Support !!!

@travnewmatic @osddeitf
Regarding to the goal:

switching my cluster from local-storage volumes to longhorn

I don't think CSI volume cloning feature can achieve this goal. From the document you mentioned, the 2 PVC must have the same storageclass

@ayr-ton The steps at https://github.com/longhorn/longhorn/issues/1815#issuecomment-781609692 seems good to me

Test plan
Clone volume that doesn't have backing image

Create a PVC:apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: source-pvc
spec:
  storageClassName: longhorn
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi

Specify the source-pvc in a pod yaml and start the pod
Wait for the pod to be running, write some data to the mount path of the volume
Clone a volume by creating the PVC:apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: cloned-pvc
spec:
  storageClassName: longhorn
  dataSource:
    name: source-pvc
    kind: PersistentVolumeClaim
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi

Specify the cloned-pvc in a cloned pod yaml and deploy the cloned pod
Wait for the CloneStatus.State in cloned-pvc to be completed
In 3-min retry loop, wait for the cloned pod to be running
Verify the data in cloned-pvc is the same as in source-pvc
In 2-min retry loop, verify the volume of the clone-pvc eventually becomes healthy
Cleanup the cloned pod, cloned-pvc. Wait for the cleaning to finish
Scale down the source pod so the source-pvc is detached.
Wait for the source-pvc to be in detached state
Clone a volume by creating the PVC:apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: cloned-pvc
spec:
  storageClassName: longhorn
  dataSource:
    name: source-pvc
    kind: PersistentVolumeClaim
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi

Specify the cloned-pvc in a cloned pod yaml and deploy the cloned pod
Wait for source-pvc to be attached
Wait for a new snapshot created in source-pvc volume created
Wait for the CloneStatus.State in cloned-pvc to be completed
Wait for source-pvc to be detached
In 3-min retry loop, wait for the cloned pod to be running
Verify the data in cloned-pvc is the same as in source-pvc
In 2-min retry loop, verify the volume of the clone-pvc eventually becomes healthy
Cleanup the test

Clone volume that has backing image

Deploy a storage class that has backing image parameter

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: longhorn-bi-parrot
provisioner: driver.longhorn.io
allowVolumeExpansion: true
parameters:
  numberOfReplicas: "3"
  staleReplicaTimeout: "2880" # 48 hours in minutes
  backingImage: "bi-parrot"
  backingImageURL: "https://longhorn-backing-image.s3-us-west-1.amazonaws.com/parrot.qcow2"

Repeat the Clone volume that doesn't have backing image test with source-pvc and cloned-pvc use longhorn-bi-parrot instead of longhorn storageclass
Interrupt volume clone process

Create a PVC:apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: source-pvc
spec:
  storageClassName: longhorn
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi

Specify the source-pvc in a pod yaml and start the pod
Wait for the pod to be running, write 1GB of data to the mount path of the volume
Clone a volume by creating the PVC:apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: cloned-pvc
spec:
  storageClassName: longhorn
  dataSource:
    name: source-pvc
    kind: PersistentVolumeClaim
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi

Specify the cloned-pvc in a cloned pod yaml and deploy the cloned pod
Wait for the CloneStatus.State in cloned-pvc to be initiated
Kill all replicas process of the source-pvc
Wait for the CloneStatus.State in cloned-pvc to be failed
In 2-min retry loop, verify cloned pod cannot start
Clean up cloned pod and clone-pvc
Redeploy cloned-pvc and clone pod
In 3-min retry loop, verify cloned pod become running
cloned-pvc has the same data as source-pvc
Cleanup the test

Question about the implementation (I can't find the answer in the docs): Does this do some kind of fast/instant copy-on-write, or is all data copied up front? I need a way to create near-instant clones of volumes, and I was wondering whether CSI volume cloning in Longhorn will be a good fit.

@rudolfbyker This should not be faster than creating a new replica in an existing volume, I believe. So no instant copy-on-write.
Have you tested the existing snapshot functionality?

Like @ayr-ton mentioned, this is NOT instant copy-on-write.
Data are copied over to a new volume before the new volume is available for use. After cloning old volume and new volume are completely non-related.

I need a way to create near-instant clones of volumes

If your use case is that you have pre-existing data and you want to instantly create a new Longhorn volume (or many Longhorn volumes) that contains those data, you may want to take a look at the backing image feature https://longhorn.io/docs/1.2.2/advanced-resources/backing-image/#create-and-use-a-backing-image-via-storageclass-and-pvc.

Is it possible to clone volume from another namespace? I don't found documentation regarding this, I tried setting the namespace in the source without success.


Unable to resolve some modules: "canvas" and "jsdom"

Hello there,
After installing react-konva I tried to run my application. However, I got this message:

Unable to resolve some modules:
"canvas" in /Users///node_modules/konva/konva.js
(web.browser)
"jsdom" in /Users///node_modules/konva/konva.js
(web.browser)

It can still render the shapes normally. I'm wondering how I can ommit this warning??
Thanks

What are you using for bundling you code?
"canvas" and "jsdom" are dependencies for use in NodeJS environment. In they should be ignored for browser build. It is defined in package.json in browser section. https://github.com/konvajs/konva/blob/master/package.json
Browserify and webpack understand that configuration.

I use it in my Meteor app, installed it by:
meteor npm install react-konva --save
I got that message each time i run my application by running meteor command
However, it still works normally.

@hoangdo94 For now I am not sure how to resolve it. This warning come from konva.js source. Probably you can just ignore it: https://github.com/meteor/meteor/issues/6601#issuecomment-202999523

@lavrton thanks so much for your information and sorry for late reply. I will close the issue now xD


[WIP] Rerun failures

(Note: this PR has changed significantly compared to when it was first opened.  See this comment for current status).
This is the start of the implementation of a new --rerun-failures CLI flag that runs just the failures from the last run.  This leverages the new example IDs to ensure it selects the exact examples that failed the last time.  My hope with this feature is that it "just works" the first time a user decides they want to run just the failures from the last run, w/o having to configure anything in advance to enable it.
As part of the implementation, this creates a new .rspec_last_run directory in the users's home directory that persists the list of failures from the last run so we can use it on the next run.  I can imagine us finding other uses for this directory in the future.
There are a lot of open questions:

[x] Do we always want to write out the failures to .rspec_last_run?  Specific cases I can think of where we may not want to:

All specs pass -- do we blow away what was there before and replace it with nothing?
The user uses --fail-fast -- in that case it's going to abort after one failure and the user may want to get all failures, and then use --rerun-failures --fail-fast to repeatedly run just one of the remaining failing specs...but if we replaced the persisted failures with a single --fail-fast spec it wouldn't support this workflow.
The user runs only one example (via a location or id filter).

[x] What do we do if we can't write out the failures list to disk?  Emitting an error or warning on every run would be very annoying/noisy for users who don't want to use this option.
[x] What do we do if --rerun-failures is passed and there is no persisted failures from a prior run?  Do we abort with an error or treat it like "all examples filtered out" and respect the run_all_when_everything_filtered config option?
[x] What do we do if the user tries to pass --rerun-failures and also specifies specific spec files to load, or locations/ids to run?  Should we disallow that or try to combine them somehow?  For example, maybe we could take the intersection of the two?  So rspec spec/models --rerun-failures would run just the failures in the model specs.  This situation may also relate to whether or not we update the persisted failures every time.
[x] The recorded example ids may no longer be valid or may refer to different examples than they did when they were recorded (such as when changing branches or pulling new commits).  Should we try to detect this and do anything about it?

/cc @rspec/rspec

[ ] Do we always want to write out the failures to .rspec_last_run?  Specific cases I can think of where we may not want to:

All specs pass -- do we blow away what was there before and replace it with nothing?
The user uses --fail-fast -- in that case it's going to abort after one failure and the user may want to get all failures, and then use --rerun-failures --fail-fast to repeatedly run just one of the remaining failing specs...but if we replaced the persisted failures with a single --fail-fast spec it wouldn't support this workflow.
The user runs only one example (via a location or id filter).

I don't think we should write to this directory unless the users opt in, it'd pretty rude to just start writing to disk and I can think of a few scenarios where this would be undesirable (for example CI systems)

[ ] What do we do if we can't write out the failures list to disk?  Emitting an error or warning on every run would be very annoying/noisy for users who don't want to use this option.

I think if we only write when told to it's ok to omit an error when we can't.

[ ] What do we do if --rerun-failures is passed and there is no persisted failures from a prior run?  Do we abort with an error or treat it like "all examples filtered out" and respect the run_all_when_everything_filtered config option?

I like the alter idea.

[ ] What do we do if the user tries to pass --rerun-failures and also specifies specific spec files to load, or locations/ids to run?  Should we disallow that or try to combine them somehow?  For example, maybe we could take the intersection of the two?  So rspec spec/models --rerun-failures would run just the failures in the model specs.  This situation may also relate to whether or not we update the persisted failures every time.

Combine them, but we'd need to not blow away any existing cache at this point, I'd use this feature this way.

[ ] The recorded example ids may no longer be valid or may refer to different examples than they did when they were recorded (such as when changing branches or pulling new commits).  Should we try to detect this and do anything about it?

I think we should try, maybe hash the file contents?

I don't think we should write to this directory unless the users opt in, it'd pretty rude to just start writing to disk and I can think of a few scenarios where this would be undesirable (for example CI systems)

My hope was to make this feature usable w/o requiring the user to have the forethought to configure it.  They could run rspec --help, notice the --rerun-failures flag and use it immediately.
That said, it makes it hard to report write errors w/o appearing to nag the user about something they haven't opted-in to, so I think I'm coming around to the idea of:

Adding a config.persistence_directory option that specifies where we should write to. When not set we would avoid writing out the failures and emit an error when the user tries to use --rerun-failures instructing them to set the config option first.
Adding this option to the recommended settings section of spec_helper.rb generated by rspec --init.

Combine them, but we'd need to not blow away any existing cache at this point, I'd use this feature this way.

By "combine them" do you mean "take the intersection"?
As for not blowing away the existing cache...I think it's confusing for us to only update the persisted failures sometimes but it's definitely desirable not to lose the state about other examples that weren't part of the run...which gives me an idea for a different direction we could take this feature that I think would work much, much better:

Rather than persisting a list of examples that failed on the last run, use persistence to keep track of the status (e.g. pass/fail/pending) of each example the last time it ran (which may or may not have been part of the last run).
When the suite completes, we would update the persisted example list using the following logic:

For examples that ran as part of that run, we would overwrite their last_run_result (or store the example for the first time if its new).
For examples that did not run that time, we would either leave the last_run_result as-is if the example may still exist or delete the example's record from the file if we are sure it no longer exists.

If the example's rerun_file_path was one of the loaded spec files, then we can see if the id matches the id of any of the loaded examples (including ones that did not run due to filtering or --fail-fast or whatever).  If there's a loaded example with the same id, we'd leave the last_run_result record as-is.  Otherwise we can delete the record because we know the example no longer exists.
If the example's rerun_file_path was not one of the loaded spec files, we would check and see if File.exist?(rerun_file_path) and either leave the last_run_result record alone, if the file does exist, or delete the record if the file does not exist.

The semantics (and --help description) of --rerun-failures would change from "run just the examples that failed on the last run" to "run just the examples that failed the last time they ran".  --rerun-failures becomes just another filter.  In fact, we may want to call it --only-failures to make it more clear how it works in conjunction with specifying some files or directories.  IMO, rspec spec/models --only-failures is clear that it's running the failures from spec/models, where as a user could reasonably think that rspec spec/models --rerun-failures may run all specs in spec/models and all failures (that is, set union rather than set intersection).
I can imagine other uses for persisting the last_run_result of each example.  For example, in our formatter output we could draw attention to examples that are newly failing or newly passing as opposed to failing again or passing again.  Sometimes I find myself scrolling between the output from the prior run and the last run to figure out what the diff is, but we could have our formatters do that work!  Obviously, I consider this out of scope for this PR--it's more just one idea of something else we might do with this data once we have it.  I may even add metadata[:last_run_result] to expose this directly on example metadata (and then --only-failures would become a simple filter on last_run_result == :failed).

I think we should try, maybe hash the file contents?

Problem is, the user is going to want to edit the spec file to address the failures, and then rerun them...which would produce a different checksum just like changing branches would.  I think the best we could do is to store the example description w/ the id, and use that to as a signal to infer if the id refers to the same example as before or not.
That would probably work better....but I'm concerned that it is simply a heuristic and may make this feature act in confusing, inconsistent ways.  For example, the user may change the doc string to correct a typo and they would still consider it to be the same example.  Ultimately, I think "is this the same example as before?" is a question that can only be answered by human judgement, and we're better off trying to avoid guessing.  The downsides of running the wrong examples after changing branches aren't really that high -- it would just run some passing examples and skip some failed ones.  We can always revisit if someone comes up with a way to detect this that we're satisfied with.
Thoughts on the alternate direction I've proposed above?

By "combine them" do you mean "take the intersection"?

Yes

so I think I'm coming around to the idea of:

Adding a config.persistence_directory option that specifies where we should write to. When not set we would avoid writing out the failures and emit an error when the user tries to use --rerun-failures instructing them to set the config option first.
Adding this option to the recommended settings section of spec_helper.rb generated by rspec --init.

Yep, ok I'm ok with this, and when not said we should disable all of the below for performance.

As for not blowing away the existing cache...I think it's confusing for us to only update the persisted failures sometimes but it's definitely desirable not to lose the state about other examples that weren't part of the run...which gives me an idea for a different direction we could take this feature that I think would work much, much better:

Rather than persisting a list of examples that failed on the last run, use persistence to keep track of the status (e.g. pass/fail/pending) of each example the last time it ran (which may or may not have been part of the last run).

And the last time it ran maybe? We could log a quick stat line pass/fail, #{Time.now}, #{time_taken}

When the suite completes, we would update the persisted example list using the following logic:

For examples that ran as part of that run, we would overwrite their last_run_result (or store the example for the first time if its new).
For examples that did not run that time, we would either leave the last_run_result as-is if the example may still exist or delete the example's record from the file if we are sure it no longer exists.

If the example's rerun_file_path was one of the loaded spec files, then we can see if the id matches the id of any of the loaded examples (including ones that did not run due to filtering or --fail-fast or whatever).  If there's a loaded example with the same id, we'd leave the last_run_result record as-is.  Otherwise we can delete the record because we know the example no longer exists.
If the example's rerun_file_path was not one of the loaded spec files, we would check and see if File.exist?(rerun_file_path) and either leave the last_run_result record alone, if the file does exist, or delete the record if the file does not exist.

As long as we can turn all this off in case it adds a large performance overhead (which is what I mean by turn it off when persistance_directory isn't set above :) )

The semantics (and --help description) of --rerun-failures would change from "run just the examples that failed on the last run" to "run just the examples that failed the last time they ran".  --rerun-failures becomes just another filter.  In fact, we may want to call it --only-failures to make it more clear how it works in conjunction with specifying some files or directories.  IMO, rspec spec/models --only-failures is clear that it's running the failures from spec/models, where as a user could reasonably think that rspec spec/models --rerun-failures may run all specs in spec/models and all failures (that is, set union rather than set intersection).

This makes more sense

Problem is, the user is going to want to edit the spec file to address the failures, and then rerun them...which would produce a different checksum just like changing branches would. I think the best we could do is to store the example description w/ the id, and use that to as a signal to infer if the id refers to the same example as before or not.

Sure, that works :) We can just warn them when it changes or

And the last time it ran maybe? We could log a quick stat line pass/fail, #{Time.now}, #{time_taken}.

I'm thinking we may want to add more data like that but I'd rather wait to add that until we have a use for it.  For now I just want to get a serialization format in place that will allow us to easily add that in the future.  Or maybe I'll change my mind and add it now :).
This does bring up a key question: how should we serialize this?  JSON would be a natural choice but we'd like to avoid loading that stdlib, of course.  We could vendor okjson, perhaps...although I'm interested in other ideas.  A single JSON string in a file isn't terribly readable if you pop it open in an editor :(.

Sure, that works :) We can just warn them when it changes or

Or what?
Anyhow, I advocate putting no effort into "example id references a different example than before" detection.  Too many open questions, edge cases, etc.  We can revisit in the future.

Er, or not run them, not sure how that got truncated!

This does bring up a key question: how should we serialize this? JSON would be a natural choice but we'd like to avoid loading that stdlib, of course. We could vendor okjson, perhaps...although I'm interested in other ideas. A single JSON string in a file isn't terribly readable if you pop it open in an editor :(.

I'd stick with something simpler, I mean one example per line a few values may as well be csv!

I'd stick with something simpler, I mean one example per line a few values may as well be csv!

That would probably work.  I worry a bit about dealing with quoting/escaping (e.g. a file name that has a comma in it...or should we not support that?), though.  To do proper CSV parsing with all the edge cases we'd probably have to load the CSV stdlib but maybe we can get away with a simple File.read(...).lines.map { |line| line.split(",") }.

Well we don't have to use , of course, we could pick a char less likely to be in filenames (although , is probably pretty rare it is valid in a filename).

OK, I've pushed what I've done so far for this.  It's not quite done yet but I wanted to get Travis builds going and give people a chance to review what I have so far.
Still TODO:

[ ] Make --only-failures skip the loading of files that have no failures (this can make it significantly faster!).
[ ] Set example.metadata[:last_run_status] to "unknown" when example_status_persistence_file_path is not configured. Currently it is set to nil, but unknown is what we use for examples for which we don't know the status yet (e.g. they are filtered out or have never run for some reason) so to be consistent we should set it to "unknown".
[ ] Emit a useful error message when --only-failures is used and example_status_persistence_path has not been configured.  (This is tricky, though: when the CLI option is processed, spec_helper probably hasn't been loaded yet and that's where example_status_peristence_path would usually be set).
[ ] Emit a useful error message when we try to read from or write to the persistence file and it fails for some reason (user permissions or whatever).  Just letting it fail with the full RSpec backtrace won't be very useful friendly as the backtrace will entirely be our code, so we want a friendlier error.
[ ] Update the generated spec_helper.rb so that it sets example_status_persistence_path in the recommended settings section.

Oh my is this finally going to be there then :dancers:

/cc @JonRowe

OK, this is ready for a review, @rspec/rspec.  I've done all the stuff I planned to do.

I've had two passes over this now, and can't fault it, but you know what they say about large PRs ;)

Thanks, @JonRowe.  I guess I should have left some extra trailing blank lines on some files so you'd have something to point out? Anyhow, I got it green and merged it.

I was referring to the saying:

Ask a programmer to review 10 lines of code, he'll find 10 issues. Ask him to do 500 lines and he'll say it looks good.

:P


Scrolling up to the top of popups.

After I changed browser window hight (smaller than before. Like mobile portrait to landscape) you can not scroll up to the top of popups.

Side effect of modals not resizing. Will be fixed with #8

cancelled


NON ISSUE: So Fancy :)

The new video info page feels so fancy, cool job!
It would be nice if the playing opens a new tab.
The next step should be playing in the thumbnails (via some play play)  :) That would be even fancier

It would be nice if the playing opens a new tab.
That is a good idea, pretty simple to fix.

The next step should be playing in the thumbnails (via some play play) :) That would be even fancier
This is pretty difficult to do. I think FFMPEG might be able to generate thumbnails of downloaded videos, but it might take a significant amount of time to implement it, it won't work on videos that are not downloaded (they might have to be downloaded first). I'm not going to do this, but if anyone is willing to make a PR, I would gladly accept it.

Fixed in commit https://github.com/chibicitiberiu/ytsm/commit/18f2557cb9d21ec7da673566c2aaabb8b85d4c5d.


installation error

php spark bf:install
Warning: chdir(): No such file or directory (errno 2) in \bonfire\spark on line 42
Call Stack:
0.2042     398816   1. {main}() \bonfire\spark:0
0.2054     403224   2. chdir() \bonfire\spark:42
Fatal error: Uncaught TypeError: Argument 1 passed to CodeIgniter\CLI\Console::__construct() must be an instance of CodeIgniter\CodeIgniter, int given, called in \bonfire\spark on line 48 and defined in \bonfire\vendor\codeigniter4\framework\system\CLI\Console.php on line 29
TypeError: Argument 1 passed to CodeIgniter\CLI\Console::__construct() must be an instance of CodeIgniter\CodeIgniter, int given, called in \bonfire\spark on line 48 in \bonfire\vendor\codeigniter4\framework\system\CLI\Console.php on line 29
Call Stack:
0.2042     398816   1. {main}() \bonfire\spark:0
0.2201     815520   2. CodeIgniter\CLI\Console->__construct() \bonfire\spark:48

Oh, this probably needs to be updated to work with the changes in CI 4.2. I'll be working to get Bonfire in a really good spot next week so will tackle this then.

This has been fixed to work with CodeIgniter 4.2 and now requires it as a minimum version.


[doc, testplan] Update chip testplan for sysrst_ctrl

This commit addresses the comments and updates from the testplan
review meeting held on 08/27/2021.
The meeting notes are below:
https://docs.google.com/document/d/1OhPP-HjciwKpIh0wWt1xqPqPf0Y0powmmww6xekwMeE/
Updated the sysrst-ctrl section of the testplan based on new design
changes.

Signed-off-by: Srikrishna Iyer<EMAIL_ADDRESS>

Thanks, merging now.


elixir_ls: 0.14.6 -> 0.15.1

Description of changes
First LSP release with proper support for Erlang/OTP 26. 26.0.2 or later required for actual use.
For more info:
https://github.com/elixir-lsp/elixir-ls/releases/tag/v0.15.1
https://github.com/elixir-lsp/elixir-ls/issues/886
https://github.com/elixir-lsp/elixir-ls/pull/923
Things done

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

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

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

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

[X] Fits CONTRIBUTING.md.

Thank you !

This is still marked as draft, do you have more changes planned or do you want to do more testing ?

This is still marked as draft, do you have more changes planned or do you want to do more testing ?

I forgot to circle back after doing said testing 😸

After updating my elixir-ls has stopped working. I'm getting the following when running it.
running /nix/store/f2sgzwbiz6s963zw0z4ssamskz2jyxag-elixir-ls-0.15.1/bin/launch.sh
Looking for ASDF install in /home/saturn/.asdf/asdf.sh
Content-Length: 103

{"jsonrpc":"2.0","method":"window/logMessage","params":{"message":"Started ElixirLS v0.15.1","type":3}}Content-Length: 115

{"jsonrpc":"2.0","method":"window/logMessage","params":{"message":"Running in /home/saturn/nixos-config","type":3}}Content-Length: 130

{"jsonrpc":"2.0","method":"window/logMessage","params":{"message":"ElixirLS built with elixir \"1.15.2\" on OTP \"25\"","type":3}}Content-Length: 151

{"jsonrpc":"2.0","method":"window/logMessage","params":{"message":"Running on elixir \"1.15.2 (compiled with Erlang/OTP 25)\" on OTP \"25\"","type":3}}Content-Length: 109

{"jsonrpc":"2.0","method":"window/logMessage","params":{"message":"Protocols are not consolidated","type":3}}Content-Length: 176

{"jsonrpc":"2.0","method":"window/logMessage","params":{"message":"Elixir sources not found (checking in /build/source). Code navigation to Elixir modules disabled.","type":3}}

Hello @shanesveller,
Thanks for taking the time to reply to me. I'm not using asdf either, but i guess the log about is only for information. I've tried to force a specfic version of elixir in the elixir-ls by doing the following.
    packages = with pkgs; [
      ... packages
    ] ++ (
      let
       elixir-ls = pkgs.elixir_ls.override {
         elixir = elixir_1_15;
      };
    in [
      elixir-ls
    ]);

I see that elixir_1_15 is compiled with OTP 25 and not 26, could this be the issue?
Do i somehow need to specify the elixir path for elixir-ls now? Just wondering by the looks of the error Elixir sources not found (checking in /build/source).

The upgrade of the default erlang version from 25 to 26 has to be done at some point, but since it needs a bit of testing stuff, no one really has had the time for it.

I will have a look this weekend, most of the problems should be fixed by now


Alternative to non maintained Minimist package

Minimist is not maintained by their authors. They have 33 open issues not answered, 21 open PR and last commit was 2 years ago.
This situation is raising issues to Vorpal.
Community would appreciate if you find an alternative to replace it. My recommendation it is https://github.com/tj/commander.js which has an active community of developers.

Commander and Vorpal are equivalent libraries. They could even be considered competitors.
That being said, we have plans to rework argument parsing in v2.

Thanks for your fast reply. Hence I've changed the title to the real purpose of my issue. Hope you can find a way to get rid of that package.

dashdash is an excellent arg parser, although I assume you have already chosen an argument parser for Vorpal version 2.
https://github.com/trentm/node-dashdash

Unanswered.


[Request] Config files for setting shine effects on modded custom blocks, tools, and armor

the current config already does it, or you meant something else?