404 Not Found on runtime invocation after precompilation tests

We've move to use package_compile=true and our build is throwing after running the the Julia tests. Could be to do with the fact that we're running Jot within an Ubuntu Docker and are missing a package.
Error message
value.(c) = [1.0]
     Testing MyPackage tests passed
Starting runtime at http://<IP_ADDRESS>:9001/2018-06-01/runtime/invocation/
DEBUG: 2022-11-03T17:04:49.979 3f27 ➡   "71698432475048495645485445484947114117110116105109101471051101181119997116105111110471101011201163272848480474946491310721111151165832495055464846484649585748484913106599991011121165832424742131085115101114456510310111011658327284848046106108474946564650131067111110116101110116457610111010311610458324813101310" (write)
DEBUG: 2022-11-03T17:04:50.920 3f27 ⬅   "HTTP/1.1 404 Not Found\r\n" (readuntil)
DEBUG:                                  "Transfer-Encoding: chunked\r\n"
DEBUG:                                  "\r\n"
DEBUG: 2022-11-03T17:04:50.946 3f27 ⬅   "0\r\n" (readuntil)
DEBUG: 2022-11-03T17:04:50.987 3f27 ⬅   "\r\n" (readuntil)
ERROR: LoadError: HTTP.ExceptionRequest.StatusError(404, "GET", "/2018-06-01/runtime/invocation/next", HTTP.Messages.Response:
"""
HTTP/1.1 404 Not Found
Transfer-Encoding: chunked

Deploy Script
import Pkg;
Pkg.add(url="https://github.com/harris-chris/Jot.jl#main");
using Jot

cd("./src/MyPackage")

Pkg.activate("./")
Pkg.instantiate()

using MyPackage

# Build the Lambda responder and image --
responder = get_responder(MyPackage, :my_package, Dict)
local_image = create_local_image(responder; image_suffix="my_package", package_compile=true)
remote_image = push_to_ecr!(local_image)
lambda_function = create_lambda_function(remote_image)

Tests
println("Running tests...")

using Test;
import MyPackage;

result = MyPackage.say_hello()

OK, sorry to hear you're having trouble there. Is this with the same
package as you showed me before? And I guess you're getting this when you
use the Jot.jl run_test function?
Running Julia from within a container shouldn't make a difference, I used
to do that myself. What do you mean when you say you're missing a package?
On Fri, Nov 4, 2022 at 3:06 AM Matt Doak @.***> wrote:

We've move to use package_compile=true and our build is throwing after
running the the Julia tests. Could be to do with the fact that we're
running Jot within an Ubuntu Docker and are missing a package.
Error message
value.(c) = [1.0]
 Testing MyPackage tests passed

Starting runtime at http://<IP_ADDRESS>:9001/2018-06-01/runtime/invocation/
DEBUG: 2022-11-03T17:04:49.979 3f27 ➡   "71698432475048495645485445484947114117110116105109101471051101181119997116105111110471101011201163272848480474946491310721111151165832495055464846484649585748484913106599991011121165832424742131085115101114456510310111011658327284848046106108474946564650131067111110116101110116457610111010311610458324813101310" (write)
DEBUG: 2022-11-03T17:04:50.920 3f27 ⬅   "HTTP/1.1 404 Not Found\r\n" (readuntil)
DEBUG:                                  "Transfer-Encoding: chunked\r\n"
DEBUG:                                  "\r\n"
DEBUG: 2022-11-03T17:04:50.946 3f27 ⬅   "0\r\n" (readuntil)
DEBUG: 2022-11-03T17:04:50.987 3f27 ⬅   "\r\n" (readuntil)
ERROR: LoadError: HTTP.ExceptionRequest.StatusError(404, "GET", "/2018-06-01/runtime/invocation/next", HTTP.Messages.Response:
"""
HTTP/1.1 404 Not Found
Transfer-Encoding: chunked
Deploy Script
import Pkg;
Pkg.add(url="https://github.com/harris-chris/Jot.jl#main");
using Jot
cd("./src/MyPackage")
Pkg.activate("./")
Pkg.instantiate()
using MyPackage
Build the Lambda responder and image --
responder = get_responder(MyPackage, :my_package, Dict)
local_image = create_local_image(responder; image_suffix="my_package", package_compile=true)
remote_image = push_to_ecr!(local_image)
lambda_function = create_lambda_function(remote_image)
Tests
println("Running tests...")
using Test;
import MyPackage;
result = MyPackage.say_hello()
—
Reply to this email directly, view it on GitHub
https://github.com/harris-chris/Jot.jl/issues/36, or unsubscribe
https://github.com/notifications/unsubscribe-auth/ALDMVSEFDXQUNUAFMDJ37XLWGP5L5ANCNFSM6AAAAAARWNCX3A
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

OK. Prima facie, there's nothing about that setup that should cause Jot to
break, particularly not if it works with package_compile off. I should
get some time for this tomorrow, I'll try to re-create your problem then.
On Fri, Nov 4, 2022 at 11:56 AM Matt Doak @.***> wrote:

Correct, same package as before.
I'm not using the run_test function directly. I have the full Jot.jl
process working and I've moved on to precompilation. The difference between
a working and non-working build is just the addition of
package_compile=true on this line.
local_image = create_local_image(responder; image_suffix="my_package", package_compile=true)
When I remove that parameter, everything succeeds again.
About the missing package -- I just thought that because it's a fresh
Ubuntu install I might have to apt-get something in the Dockerfile. Aside
from aws and julia, this is all I'm installing on the Docker:
RUN apt update; apt-get install -y wget curl python3 python3-pip unzip ca-certificates
Using this image so that docker in docker works (i.e the outer Docker
makes docker commands available to Jot):
FROM teracy/ubuntu:20.04-dind-20.10.13
—
Reply to this email directly, view it on GitHub
https://github.com/harris-chris/Jot.jl/issues/36#issuecomment-1302891918,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ALDMVSBINAGUPHYOOCBJLM3WGR3MBANCNFSM6AAAAAARWNCX3A
.
You are receiving this because you commented.Message ID: <harris-chris/Jot
<EMAIL_ADDRESS>

I've created a public repository with a replication of the issue: https://github.com/sklink/jot-precompilation-test

Thanks - I've cloned your repo and got it working locally. The changes I had to make were:

A julia testsuite needs to be an @testset containing one or more @test assertions, so I've edited your runtests.jl accordingly. If you can run Pkg.test("MyPackage") then you know you have a test suite defined.
The second argument of get_responder needs to be the name of the responder function, rather than the package, otherwise Jot cannot know which function should be used to respond to calls
The third argument of get_responder needs to be the type of the input parameter of your responder function, in your original code it was Dict whereas the responder function took no arguments.
The validity of the arguments to get_responder can be checked at run-time and I should probably add some validation for them so that meaningful errors are produced.
I'll make a pull request on your repo to share these changes at some point tomorrow, I've got to go and do something now.
Looking at this did reveal a bug which I was unaware of so it's been a useful exercise.

Actually, I haven't got this working. As you say, setting package_compile to true causes it to break. There's some kind of error showing as to what went wrong, but it's occurring from within the docker build process so it's not easy to see what's going on.
I'm going to:

Refactor the unit tests, which should have picked this up
Upgrade Jot to use PackageCompiler v2
... then make things work again
All in all this could take a couple of weeks. Are you OK to run the function without package compilation up until that point?

My fork here: https://github.com/harris-chris/jot-precompilation-test

OK, I have my fork working (with package_compile as true). The issue seems to be that PackageCompiler v1 isn't compatible with Julia 1.8.2, so I've reverted the default Julia version to 1.6.7 until I can upgrade to PackageCompiler v2.

Great, compiling for me now as well -- we're returning a result in ~20ms, so excited! Thanks for taking the time!


URL bar button dropdowns moving when placing mouse on them

Sanity checks (must complete)

[x] I have read and followed the installation instructions in the README
[x] I have not modified the userChrome.css file
[x] I have tested the latest release or commit on master

Describe the bug
Because all the buttons in the url bar slide to the right when the mouse isn't on the url bar, all dropdowns opened from these do the same when you move your mouse outside the url bar.

To Reproduce
Steps to reproduce the behavior:

Click any menu button in the url bar that has a dropdown menu
Observe the menu moving away as you get your mouse on it.

System info

OS: macOS 10.11.6
Firefox version: 70.0.1

Please test 6141249 when you get a chance.

Works perfectly.


Is there anyway to use global linter for all filetype for simple warning like trailing space?

vim-airline is warned about trailing space but only after the file is saved and it only show the first one.

I am using set list in my config but it easy to miss,  when code is big.
Is there anyway to have these kind of linters that can be use on any filetype.

trailing space
mixed space and tab

I personally use a function which automatically removes trailing spaces, and I draw tab characters.
set listchars=tab:>~
set list

fun! TrimWhitespace()
    let line_no = line('.')
    let col_no = col('.')

    %s/\s*$//

    call cursor(line_no, col_no)
endf

" Do auto whitespace trimming.
autocmd FileWritePre * :call TrimWhitespace()
autocmd FileAppendPre * :call TrimWhitespace()
autocmd FilterWritePre * :call TrimWhitespace()
autocmd BufWritePre * :call TrimWhitespace()

I wrote those lines a long, long time ago, and I've been using that for ages.

A mix of tabs and spaces isn't necessarily an error for every type of file. It might be required for some formats.

autocommand is a good solution.


Use vite for bin handling

It would be nice if we could get rid of our postbuild hooks in bootstrap and nx-spawn by using vite to handle making their bins executable

I couldn't get npm's link-bins library working how it needed to, and I'd prefer not managing the behavior ourselves - especially as this is a use-case that's really specific to our repository and not something consumers should need (the only reason I'm not running the commands with nx is because they're automatically written by our generators, and the whole benefit to having them linked is to test the generators). That said, there is a little bit of simplification we can do.


Partially specifying copy to change doesn't work

The code seems to expect that you either don't customize any of the text, or you customize all of it - which makes it harder to provide a simple configuration. For instance, if you change the header text, but then don't provide levels because you want to just use the default one, it errors.

now it should thanks to #90


Panic due to api body size.

Hello,
We've encountered an interesting issue while deploying one of our stacks.
I can't go into specifics of the configuration for obvious reasons but I'll try to explain the best I can.
We are trying to deploy a aws_api_gateway_rest_api resource with the body being a rendered openapi template file.
We didn't experience any issues up until now when there were some changes done to the openapi file.
The openapi file is now about 3500 lines big and is causing the panic. We tested that this is the issue using a smaller openapi file and it worked fine.
I would like to as if there is any limitation to this we should take into account going forward and how we could get it resolved.
Added a TF_LOG=trace to extract some logs. It happens here when it tries to create the tf state file for this module in s3. Every module has it's own tfstate file.
In the respective bucket the api-gateway key is missing in entirety.
[terragrunt] [/config/account/region/environment/api-gateway] 2020/03/04 16:30:12 Running command: terraform init -backend-config=bucket=bucket-name -backend-config=dynamodb_table=dynamo-db-table -backend-config=encrypt=true -backend-config=key=12345/environment/api-gateway/terraform.tfstate -backend-config=region=region
Here is the panig message:
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x18 pc=0xd37d71]
goroutine 53 [running]:
github.com/gruntwork-io/terragrunt/cli.runTerraformWithRetry(0xc0000db600, 0xc0000db600, 0xc0002f8900)
/go/src/github.com/gruntwork-io/terragrunt/cli/cli_app.go:531 +0x121
github.com/gruntwork-io/terragrunt/cli.runTerragruntWithConfig.func1(0x0, 0x0)
/go/src/github.com/gruntwork-io/terragrunt/cli/cli_app.go:484 +0x2a
github.com/gruntwork-io/terragrunt/cli.runActionWithHooks(0xf9a250, 0x9, 0xc0000db600, 0xc0002a8140, 0xc00043bc20, 0xc0004ee500, 0xc00060a140)
/go/src/github.com/gruntwork-io/terragrunt/cli/cli_app.go:495 +0x2ae
github.com/gruntwork-io/terragrunt/cli.runTerragruntWithConfig(0xc0000db600, 0xc0002a8140, 0x0, 0x0, 0x0)
/go/src/github.com/gruntwork-io/terragrunt/cli/cli_app.go:483 +0x2c7
github.com/gruntwork-io/terragrunt/cli.RunTerragrunt(0xc0000db600, 0xfa49a3, 0x15)
/go/src/github.com/gruntwork-io/terragrunt/cli/cli_app.go:370 +0x79c
github.com/gruntwork-io/terragrunt/configstack.(*runningModule).runNow(0xc0005c7c20, 0x0, 0x0)
/go/src/github.com/gruntwork-io/terragrunt/configstack/running_module.go:238 +0x17a
github.com/gruntwork-io/terragrunt/configstack.(*runningModule).runModuleWhenReady(0xc0005c7c20)
/go/src/github.com/gruntwork-io/terragrunt/configstack/running_module.go:201 +0x6a
github.com/gruntwork-io/terragrunt/configstack.runModules.func1(0xc00009f150, 0xc0005c7c20)
/go/src/github.com/gruntwork-io/terragrunt/configstack/running_module.go:171 +0x51
created by github.com/gruntwork-io/terragrunt/configstack.runModules
/go/src/github.com/gruntwork-io/terragrunt/configstack/running_module.go:169 +0xe1
Makefile:68: recipe for target 'apply' failed
make: *** [apply] Error 2
I had a issue opened on terraform github and was redirected here.
This is the issue:
https://github.com/hashicorp/terraform/issues/24240

Apologies for the ping ponging here since I was the original one to kick you over to terraform. The stack trace helps a lot in clarifying what is going on here.
I still think this is a terraform error under the hood, but the terraform error is being masked by a different terragrunt bug, which is poor error handling in the retry logic. I'll be investigating if there is a easy fix for that.
In the meantime, can you rerun your config with just terraform, no terragrunt and see if you can see the underlying error? You can do this by using a tfvars file instead of terragrunt.

Hi.
Thanks for the reply.
I will try and do that tomorrow at the office and come back here.

Not sure if you had a chance to test this, but I have fixed the source of panic in terragrunt. If you use v0.23.1, you should now see the underlying terraform error as opposed to the terragrunt panic even going through terragrunt.


Uses more and more RAM with each passing experiment

I noticed that the training progress was using more and more RAM with each passing experiment.
After a quick search I found that this could be avoided by adding tf.reset_default_graph() at the end of the try_net method in the training.py .
With this change the code should be able to run on machines with way less available memory.

Thanks! I don't know why I removed that line at some point!


Accessing rmq.color.custom_color crashes in AppDelegate on_load

Error:
custom_color not defined in rmq.'s color class.

sounds like application_setup wasn't run on your stylesheet yet.  Are you initializing a controller to display before calling this color method?  Where is the stylesheet set in that controller?

class AppDelegate < PM::Delegate
  include CDQ

  status_bar true, animation: :fade

  def on_load(app, options)
    cdq.setup
    open LoginScreen.new(nav_bar: true)
    puts rmq.color.theme_500
  end
end

Not sure where it's initialized, it's pretty a plain project that I just started.

@squidpunch it's crashing on puts rmq.color.theme_500

so theme_500 is defined in application stylesheet?  I would expect this to be fine because the LoginScreen initialization should call the stylesheet and then call setup.
I will throw together a quick app and see if I can recreate the bug and try and work through it :+1:

Yeah, this an architecture failure on my part. You have to open a controller before ApplicationStylesheet#setup is run. However as David notes, it should be there after the LoginScreen is loaded.
A work around if you need colors before any screen is loaded you can do:
ApplicationStylesheet.new.application_setup

We're not getting a response, so closing.


Delete version 1 of Lookout

Commit 061aa822d237331d09b3686f89bc1564aba8d2c4 is the part of #3038 that makes lookoutv2 serve the Lookout UI; the subsequent commits delete all the code of version 1 of Lookout that is not shared with version 2 of Lookout.

Just to check, have you verified this works with mage localdev full ui, and that lookout becomes available on localhost?
@dejanzele this might also affect the operator

Just to check, have you verified this works with mage localdev full ui, and that lookout becomes available on localhost?

It does work,[^1] because I am updating docker-compose.yaml and magefiles/developer.go as part of this PR. The Lookout UI is served on localhost:1000, together with version 2 of the Lookout UI.
[^1]: Strictly speaking I did encounter a problem with the sed version used by mage buildpython, but that is unrelated to this change; I'll create a separate PR.


How i will change kong configuration ?

I need to change logging configuration. How can i change this ?

@viswaram1997 we're in the process of deprecating the Kong offering in the marketplace. We might replace it later by a newer and better version, but nothing decided yet.
I would advise not to use it.


Multi-GPU support

Is it possible to use Weaviate with multi-GPUs? For example, we can see only one of the GPUs being used in our machine.

The modules just use a single GPU but you can run multi modules and load balance between them. @antas-marcin  has an example of this.

Dear @antas-marcin ,
Is there any chance you could share the example @trengrj  mentions, please? It would be amazing to learn how to run multi modules? Or any other methods to reduce the search and question answering time, with multi GPUs or without extra GPUs. Many Thanks in advance.


/multiprocessing/connection.py", line 379, in _recv     chunk = read(handle, remaining) ConnectionResetError: [Errno 104] Connection reset by peer

how to solve this?
Every time I train the model, when it ran into the end of one epoch, it will happen, how to solve this?

It's weird... I didn't met this problem, can you provide more information?

I meet the same error ,but I don't know how to solve this problem, so could you give me some suggestion? thx a lot

It's weird... I didn't met this problem, can you provide more information?
I meet the same error ,but I don't know how to solve this problem, so could you give me some suggestion? thx a lot

Someone know to fix it ?


feat(render): add serializer for jpql isNotNull

Motivation:
Modifications:
Add JpqlIsNotNullSerializer
Add tests

List the modifications you've made in detail.

Commit Convention Rule

Please commit your modification based by conventional commit
This commit convention is referred from angular convention

Commit type
Description

feat
New Feature

fix
Fix bug

docs
Documentation only changed

ci
Change CI configuration

refactor
Not a bug fix or add feature, just refactoring code

test
Add Test case or fix wrong test case

style
Only change the code style(ex. white-space, formatting)

chore
It refers to minor tasks such as library version upgrade, typo correction, etc.

If you want to add some more commit type please describe it on the Pull Request

Result:
Closes
#371

Describe the consequences that a user will face after this PR is merged.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Your first contribution will be greatly appreciated!


Change tab icons

Currently, the first three icons are the ones created automatically by the Ionic create script. We should change these to something that fits the purpose of each tab.

Ok i'll take a look at this.


Discord Unban

Hello,
So I have gotten back into Oblique recently again, and wanted to apply for an unban on the discord server. I was originally banned for an accidental self promo, which I take the blame for but was not necessarily my fault. Last year, when I played this server, I had been into streaming and wanted to grow, so I had sent my server to every person on my friends list. What I did not know was discord had the menu set up to friends of friends, recommended friends, etc. One of the people on this list had happened to be a moderator on oblique, which the most likely scenario for this was me DM'ing mods with concerns, and discord recommending them on this list. I had never had the intent of breaking a rule, but take responsibility for the actions that took place. I am deeply sorry for the breaking of this specific rule, but not being able to interact on the server is an annoyance and makes me lose motivation to play on the server more than I already do.
I would like for whoever is reading this to consider unbanning me, because it really was just an honest mistake.
Again I am very sorry for my actions, this will not happen again (also due to the fact I don't share my server anymore because of this reason LOL)
-ThyRedWolf
ThyRedWolf#4456 is my discord

Sorry for the delayed response. I'm satisfied this was an honest mistake and I'm happy to say you're unbanned from the Oblique Discord, just please be more careful next time!


hash/fnv  has collision cause the wait container process not as expected  when create  workflow as same name

Checklist

[ ] Double-checked my configuration.
[ ] Tested using the latest version.
[ ] Used the Emissary executor.

Summary
What happened/what you expected to happen?
wait container can wait correct main container
What version are you running?
v3.3.8
Diagnostics
every day, we has more than 1000000 data process task process by argo workflow, use workflowtemplate to create workflow as generateName to dynamic generate workflow name,  sometime we found less workflow step's pod is NotReady, we check the wait container log, we found the node has same pod name's wait and main container wthis Exit(0) status, so when the same pod of new created on the node,  and the new pod's wait container up,  the wait container to use command docker ps --all --no-trunc --format='{{.Status}}|{{.Label "io.kubernetes.container.name"}}|{{.ID}}|{{.CreatedAt}}' --filter=label=io.kubernetes.pod.namespace=argo --filter=label=io.kubernetes.pod.name=PodName to found main container, the new pod main conatiner has not been created,  the command get the old pod's main, but it's already exit 0, so the new pod's wait container do the finish the rest of logic quikly and succeeded exit 0.  but late the new pod's main container created and up.

# Logs from the workflow controller:
kubectl logs -n argo deploy/workflow-controller | grep ${workflow}

# If the workflow's pods have not been created, you can skip the rest of the diagnostics.

# The workflow's pods that are problematic:
kubectl get pod -o yaml -l workflows.argoproj.io/workflow=${workflow},workflow.argoproj.io/phase!=Succeeded

# Logs from in your workflow's wait container, something like:

time="2022-07-08T07:44:38.641Z" level=info msg="Starting deadline monitor"
time="2022-07-08T07:44:38.670Z" level=info msg="mapped container name "main" to container ID "798a0c237789c0efc2c214a859d53195b55682c4645cf709ac8cb8f679ee6f9e" (created at 2022-07-06 02:00:25 +0000 UTC, status Exited)"
time="2022-07-08T07:44:38.670Z" level=info msg="mapped container name "wait" to container ID "4c9e4492375a2418e282ec49c5f0889fa4d42d1073f3fb22d74ce442fe2689b2" (created at 2022-07-08 07:44:38 +0000 UTC, status Up)"
time="2022-07-08T07:44:38.670Z" level=info msg="mapped container name "wait" to container ID "237b4d73b9059ed1f2b30192c24b1c3062b70d5d2b3cf90e6c70542d09ea760b" (created at 2022-07-06 02:00:25 +0000 UTC, status Exited)"
time="2022-07-08T07:44:39.665Z" level=info msg="Main container completed"
time="2022-07-08T07:44:39.665Z" level=info msg="No Script output reference in workflow. Capturing script output ignored"
time="2022-07-08T07:44:39.665Z" level=info msg="Capturing script exit code"
time="2022-07-08T07:44:39.686Z" level=info msg="Saving logs"
time="2022-07-08T07:44:39.686Z" level=info msg="[docker logs 798a0c237789c0efc2c214a859d53195b55682c4645cf709ac8cb8f679ee6f9e]"
time="2022-07-08T07:44:39.693Z" level=info msg="mapped container name "main" to container ID "48b5a6924c96c6cc42e043535b5fa0d3081135f77615efd98a8aa46c8f45a802" (created at 2022-07-08 07:44:38 +0000 UTC, status Up)"
time="2022-07-08T07:44:39.693Z" level=info msg="mapped container name "wait" to container ID "4c9e4492375a2418e282ec49c5f0889fa4d42d1073f3fb22d74ce442fe2689b2" (created at 2022-07-08 07:44:38 +0000 UTC, status Up)"
time="2022-07-08T07:44:39.992Z" level=info msg="S3 Save path: /tmp/argo/outputs/logs/main.log, key: /*/main.log"
time="2022-07-08T07:44:39.992Z" level=info msg="Creating minio client ******** using static credentials"
time="2022-07-08T07:44:39.992Z" level=info msg="Saving from ****************
time="2022-07-08T07:44:40.475Z" level=info msg="not deleting local artifact" localArtPath=/tmp/argo/outputs/logs/main.log
time="2022-07-08T07:44:40.475Z" level=info msg="Successfully saved file: /tmp/argo/outputs/logs/main.log"
time="2022-07-08T07:44:40.475Z" level=info msg="No output parameters"
time="2022-07-08T07:44:40.475Z" level=info msg="No output artifacts"
time="2022-07-08T07:44:40.475Z" level=info msg="Annotating pod with output"
time="2022-07-08T07:44:40.584Z" level=info msg="Patch pods 200"
time="2022-07-08T07:44:40.619Z" level=info msg="Killing sidecars []"
time="2022-07-08T07:44:40.619Z" level=info msg="Alloc=5666 TotalAlloc=12662 Sys=76625 NumGC=5 Goroutines=12"

Message from the maintainers:
Impacted by this bug? Give it a 👍. We prioritise the issues with the most 👍.

@alexec docker ps cmd should use pod uid as filter label:  --filter=label=io.kubernetes.pod.uid=podUid

The Docker executor has been deprecated and not longer supported. Please try the Emissary executor.

@sarabala1979 l can't use emissary executor to do in prod env, because every day we has more than 1000000 prod data process task to do with argo workflow, l I haven't tested it with emissary executor  for a lot of tasks.  first of all, I need to ensure the stability of production task processing.


Include note about comptime and further elaboration on inferred variable assignment

In Chapter 1, Section 1:

Assignment
Value assignment has the following syntax: (const|var) identifier[: type] = value.

const indicates that identifier is a constant that stores an immutable value.
var indicates that identifier is a variable that stores a mutable value.
: type is a type annotation for identifier, and may be omitted if the data type of value can be inferred.

const constant: i32 = 5;  // signed 32-bit constant
var variable: u32 = 5000; // unsigned 32-bit variable

// @as performs an explicit type coercion
const inferred_constant = @as(i32, 5);
var inferred_variable = @as(u32, 5000);

I think it would be better to elaborate on how type inference works over here by showing all of the methods available to do so. In my limited knowledge of Zig, these are the three methods I know of:
// 1. Explicit coercion (as shown above in your example):
    var inferred_variable = @as(u32, 5000);

// 2. Inference from existing variables
    var a: i32 = 1;
    var b = a + 1; // Inferred as i32

// 3. Using the comptime directive to force a comptime_int
    comptime var a = 1;

I think showing the second method out of the three would be the best display of the use of inferred assignment in Zig, and thus should be shown first.
This is also I think a good place to show to the reader early how compile time evaluation works and what comptime_int is in Zig. A short description of both components and a link to the later section about comptime would be sufficient, considering that this tutorial is directed toward people already familiar with a programming language.

Some issues with this:

1 and 2 are equivalent; from the perspective of assignment + type inference, they're the same
3 is more complicated, in that var acts as comptime var when in a comptime block

I'm working on restructuring some things at the moment, and I agree a good idea to introduce comptime sooner, but I don't think this is a good solution.

Some issues with this:

1 and 2 are equivalent; from the perspective of assignment + type inference, they're the same

I agree that they achieve the same thing here, however my intent was to show the reader that it is possible to write such idioms as presented in method 2. Method 2 may not be as obvious to the reader if only method 1 is presented to them. Also, I don't think a user is likely to use explicit coercion everytime inferrred assignment is used, thus rendering method 1 an illustration of a valid use, but a bit useless. Illustration bth method 1 and 2 would be a good idea imo.

3 is more complicated, in that var acts as comptime var when in a comptime block

I'm working on restructuring some things at the moment, and I agree a good idea to introduce comptime sooner, but I don't think this is a good solution.

Yes, I agree that a better approach than what I suggested for this would be a more suitable solution.


Updated from 2.0.14 to 2.17.0 and broke test

Description

Steps to reproduce
See above
Additional context
No response
Hedera network
testnet
Version
2.17.0
Operating system
No response

Closing for now as customer did not provide any additional details to reproduce


Dropping metric using Promscale's SQP API leads to corrupted prom_info.metric_stats view

Some time ago I dropped a metric using Promscale's SQL API
SELECT prom_api.drop_metric('some_metric');

Today I ran
SELECT * FROM prom_info.metric_stats;

and got an error
ERROR:  relation "prom_series.some_metric" does not exist

It may be related to #617.

Thank you for the issue. It seems that the prom_api.drop_metric(text) is not deleting entry from metric table as per expectations, so clearly a bug.

@Harkishen-Singh what's the update on this?

We tried and we not reproduced. The conclusion was that there was some other thing which caused this issue. We can hence close this.


Question about function classify_counts() in horsefuzz

Hi author, I wonder why you disable the optimization classify_counts() in horsefuzz. Could you please provide an example with more details? It seems that the the function has_new_bits() will also be misled to some extent.
Thank you for replying!

Thanks!
I have read your paper before. I think the workflow is
i. func_id[] records the relations between edges and functions(cksum)
ii. in apply_mask you check all covered edges and see if they correspond to target functions.
iii. for those functions not targeted, you set the location in coverage bitmap to 0.
Since the task-aware algorithm focuses on if an edge i is covered(trace_bits[i] = 0 or not ), while the classify_counts only adjust the exact number of trace_bits[i] which stands for the execution num of an edge i, I wonder how classify_counts disturbed the map between edges and functions.
Looking forward to your replying!

Thanks! I think you are right. We mainly did that because of this comment in the classify_counts function: https://github.com/MelbourneFuzzingHub/horsefuzz/blob/master/afl-fuzz.c#L1277.


update vendor/mob to latest #3132

Current dependencies on/for this PR:

main

PR #21   👈

PR #22

This comment was auto-generated by Graphite.


Bugfix/invokable factory options affect multiple instantiations

Fix issue #126
I don't really like checking instanceof InvokableFactory, but at least it works.

Any word on this? It's still an issue.

Thanks, @AndrolGenhald! Released with 2.7.7

It seem this breaks default initialization of Zend\Filter\Boolean
First parameter of constructor must be null, not an empty array for default initialization
https://github.com/zendframework/zend-filter/blob/master/src/Boolean.php#L62

@weierophinney ping (BC break)


[6241] Confirm placement details page UI

Context
Confirm placement details page UI
Changes proposed in this pull request
Bare minimum to show the page
Guidance to review
There is/will be  a follow up PR to flesh this out the reminders, this PR is only concerned with UI only
Important business
Nope

[ ] Does this PR introduce any PII fields that need to be overwritten or deleted in db/scripts/sanitise.sql?
[ ] Does this PR change the database schema? If so, have you updated the config/analytics.yml file and considered whether you need to send 'import_entity' events?
[ ] Do we need to send any updates to DQT as part of the work in this PR?
[ ] Does this PR need an ADR?

NB: Please notify the #twd_data_insights team and ask for a review if new fields are being added to analytics.yml

 Confirm placement details page UI


Adding this repository to Home Assistant fails

Tried to add this https://github.com/erik73/addon-mailfilter/ as a new repository in Home Assistant Add-on Store but it brings an error and doesn‘t work:
https://github.com/erik73/addon-mailfilter is not a valid add-on repository
What I’m I doing wrong?

The repo is at: https://github.com/erik73/hassio-addons


[SPARK-37302][BUILD] Explicitly downloads guava and jetty-io in test-dependencies.sh.

What changes were proposed in this pull request?

This PR change dev/test-dependencies.sh to download guava and jetty-io explicitly.
dev/run-tests.py fails if Scala 2.13 is used and guava or jetty-io is not in the both of Maven and Coursier local repository.
$ rm -rf ~/.m2/repository/*
$ # For Linux
$ rm -rf ~/.cache/coursier/v1/*
$ # For macOS
$ rm -rf ~/Library/Caches/Coursier/v1/*
$ dev/change-scala-version.sh 2.13
$ dev/test-dependencies.sh
$ build/sbt -Pscala-2.13 clean compile
...
[error] /home/kou/work/oss/spark-scala-2.13/common/network-common/src/main/java/org/apache/spark/network/util/TransportConf.java:24:1:  error: package com.google.common.primitives does not exist
[error] import com.google.common.primitives.Ints;
[error]                                    ^
[error] /home/kou/work/oss/spark-scala-2.13/common/network-common/src/main/java/org/apache/spark/network/client/TransportClientFactory.java:30:1:  error: package com.google.common.annotations does not exist
[error] import com.google.common.annotations.VisibleForTesting;
[error]                                     ^
[error] /home/kou/work/oss/spark-scala-2.13/common/network-common/src/main/java/org/apache/spark/network/client/TransportClientFactory.java:31:1:  error: package com.google.common.base does not exist
[error] import com.google.common.base.Preconditions;
...

[error] /home/kou/work/oss/spark-scala-2.13/core/src/main/scala/org/apache/spark/deploy/rest/RestSubmissionServer.scala:87:25: Class org.eclipse.jetty.io.ByteBufferPool not found - continuing with a stub.
[error]     val connector = new ServerConnector(
[error]                         ^
[error] /home/kou/work/oss/spark-scala-2.13/core/src/main/scala/org/apache/spark/deploy/rest/RestSubmissionServer.scala:87:21: multiple constructors for ServerConnector with alternatives:
[error]   (x$1: org.eclipse.jetty.server.Server,x$2: java.util.concurrent.Executor,x$3: org.eclipse.jetty.util.thread.Scheduler,x$4: org.eclipse.jetty.io.ByteBufferPool,x$5: Int,x$6: Int,x$7: org.eclipse.jetty.server.ConnectionFactory*)org.eclipse.jetty.server.ServerConnector <and>
[error]   (x$1: org.eclipse.jetty.server.Server,x$2: org.eclipse.jetty.util.ssl.SslContextFactory,x$3: org.eclipse.jetty.server.ConnectionFactory*)org.eclipse.jetty.server.ServerConnector <and>
[error]   (x$1: org.eclipse.jetty.server.Server,x$2: org.eclipse.jetty.server.ConnectionFactory*)org.eclipse.jetty.server.ServerConnector <and>
[error]   (x$1: org.eclipse.jetty.server.Server,x$2: Int,x$3: Int,x$4: org.eclipse.jetty.server.ConnectionFactory*)org.eclipse.jetty.server.ServerConnector
[error]  cannot be invoked with (org.eclipse.jetty.server.Server, Null, org.eclipse.jetty.util.thread.ScheduledExecutorScheduler, Null, Int, Int, org.eclipse.jetty.server.HttpConnectionFactory)
[error]     val connector = new ServerConnector(
[error]                     ^
[error] /home/kou/work/oss/spark-scala-2.13/core/src/main/scala/org/apache/spark/ui/JettyUtils.scala:207:13: Class org.eclipse.jetty.io.ClientConnectionFactory not found - continuing with a stub.
[error]         new HttpClient(new HttpClientTransportOverHTTP(numSelectors), null)
[error]             ^
[error] /home/kou/work/oss/spark-scala-2.13/core/src/main/scala/org/apache/spark/ui/JettyUtils.scala:287:25: multiple constructors for ServerConnector with alternatives:
[error]   (x$1: org.eclipse.jetty.server.Server,x$2: java.util.concurrent.Executor,x$3: org.eclipse.jetty.util.thread.Scheduler,x$4: org.eclipse.jetty.io.ByteBufferPool,x$5: Int,x$6: Int,x$7: org.eclipse.jetty.server.ConnectionFactory*)org.eclipse.jetty.server.ServerConnector <and>
[error]   (x$1: org.eclipse.jetty.server.Server,x$2: org.eclipse.jetty.util.ssl.SslContextFactory,x$3: org.eclipse.jetty.server.ConnectionFactory*)org.eclipse.jetty.server.ServerConnector <and>
[error]   (x$1: org.eclipse.jetty.server.Server,x$2: org.eclipse.jetty.server.ConnectionFactory*)org.eclipse.jetty.server.ServerConnector <and>
[error]   (x$1: org.eclipse.jetty.server.Server,x$2: Int,x$3: Int,x$4: org.eclipse.jetty.server.ConnectionFactory*)org.eclipse.jetty.server.ServerConnector
[error]  cannot be invoked with (org.eclipse.jetty.server.Server, Null, org.eclipse.jetty.util.thread.ScheduledExecutorScheduler, Null, Int, Int, org.eclipse.jetty.server.ConnectionFactory)
[error]         val connector = new ServerConnector(

The reason is that exec-maven-plugin used in test-dependencies.sh downloads pom of guava and jetty-io but doesn't downloads the corresponding jars, and skip dependency testing if Scala 2.13 is used (if dependency testing runs, Maven downloads those jars).
if [[ "$SCALA_BINARY_VERSION" != "2.12" ]]; then
  # TODO(SPARK-36168) Support Scala 2.13 in dev/test-dependencies.sh
  echo "Skip dependency testing on $SCALA_BINARY_VERSION"
  exit 0
fi

$ find ~/.m2 -name "guava*"
...
/home/kou/.m2/repository/com/google/guava/guava/14.0.1/guava-14.0.1.pom
/home/kou/.m2/repository/com/google/guava/guava/14.0.1/guava-14.0.1.pom.sha1
...
/home/kou/.m2/repository/com/google/guava/guava-parent/14.0.1/guava-parent-14.0.1.pom
/home/kou/.m2/repository/com/google/guava/guava-parent/14.0.1/guava-parent-14.0.1.pom.sha1
...

$ find ~/.m2 -name "jetty*"
...
/home/kou/.m2/repository/org/eclipse/jetty/jetty-io/9.4.43.v20210629/jetty-io-9.4.43.v20210629.pom
/home/kou/.m2/repository/org/eclipse/jetty/jetty-io/9.4.43.v20210629/jetty-io-9.4.43.v20210629.pom.sha1
...

Under the circumstances, building Spark using SBT fails.
run-tests.py builds Spark using SBT after the dependency testing so run-tests.py fails with Scala 2.13.
Further, I noticed that this issue can even happen with Sala 2.12 if the script exit at the following part.
OLD_VERSION=$($MVN -q \
    -Dexec.executable="echo" \
    -Dexec.args='${project.version}' \
    --non-recursive \
    org.codehaus.mojo:exec-maven-plugin:1.6.0:exec | grep -E '[0-9]+\.[0-9]+\.[0-9]+')
if [ $? != 0 ]; then
    echo -e "Error while getting version string from Maven:\n$OLD_VERSION"
    exit 1
fi

This phenomenon is similar to SPARK-34762 (#31862).
So the fix is to get guava and jetty-io explicitly by mvn dependency:get.
Why are the changes needed?

To keep the Maven local repository sanity. Then, we can avoid such confusable build error.
Does this PR introduce any user-facing change?

No.
How was this patch tested?

Confirmed that we can successfully compile code with the following commands.
rm -rf ~/.m2/repository/*
# For Linux
rm -rf ~/.cache/coursier/v1/*
# For macOS
rm -rf ~/Library/Caches/Coursier/v1/*
dev/change-scala-version.sh 2.13
dev/test-dependencies.sh
./build/sbt -Pyarn -Pmesos -Pkubernetes -Phive -Phive-thriftserver -Phadoop-cloud -Pkinesis-asl -Pdocker-integration-tests -Pkubernetes-integration-tests -Pspark-ganglia-lgpl -Pscala-2.13 compile test:compile

Test build #145157 has started for PR 34570 at commit 9e24167.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/49628/

Kubernetes integration test status failure
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/49628/

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

Test build #145157 has finished for PR 34570 at commit 9e24167.

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

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

@dongjoon-hyun Oh, I forgot to add them. Thank you.

Hmm, it's funny. How about ~/.ivy2 ?
I didn't notice at that time but if guava is present on ~/.ivy2, this issue might not happen.

@dongjoon-hyun
BTW, the following commands are executed after dev/test-dependencies?
$ find ~/Library/Caches/Coursier/v1 -name "guava*"
$ find ~/.m2 -name "guava*"

If so,  guava-14.0.1.pom should be present on ~/.m2 but the result of find it doesn't appear in the result you showed.
If guava-14.0.1.pom is present but guava-14.0.1.jar is not, this issue happens.

Thanks. Let me retry step-by-step~

@dongjoon-hyun
Thank you for verifying and merging !


Adding further deserialization tests taken from https://github.com/ethereum/bls12-381-tests

Added some testing coverage on the G1 and G2 deserialization taken from https://github.com/ethereum/bls12-381-tests

LGTM, the linter is failing on one of these CI build so running cargo fmt should solve that


TargetPort does not match the listening port

The TargetPort 80 does not match the listening port 9001. The TargetPort 80 does not match any of the listening ports: [9001 9000].
This issue is a:

[x] bug report
[ ] documentation issue or request
[ ] regression (a behavior that used to work and stopped in a new release)

Issue description
I created a custom Dockerfile image that already exposes port 80. I also tested it locally to ensure port 80 is open.

Dockerfile

Port Exposed

Inspect Docker Image

However, when I tried to run the container app and bind it to port 80, I got an error in Azure Container Apps.

Expected behavior
Should no issue when running container apps
Actual behavior
The TargetPort 80 does not match the listening port 9001. The TargetPort 80 does not match any of the listening ports: [9001 9000].

Nginx config error, not azure bug


[IMPROVEMENT] Instance manager spdk_tgt resilience

Is your improvement request related to a feature? Please describe (👍 if you like this request)
Somehow it's possible that spdk_tgt crashed and spdk volume gets stuck in attaching state:
Error starting pvc-1deb58b5-c8b8-4cf2-bb10-02c83877abd6-e-7b4b0d54:
failed to create instance:
rpc error: code = Unknown desc = failed to start SPDK engine:
rpc error: code = Unknown desc = error sending message, id 70374, method bdev_raid_create,
params {pvc-1deb58b5-c8b8-4cf2-bb10-02c83877abd6-e-7b4b0d54 1 0 [pvc-1deb58b5-c8b8-4cf2-bb10-02c83877abd6-r-8eb29e9bn1 disk-1/pvc-1deb58b5-c8b8-4cf2-bb10-02c83877abd6-r-b7cafc48]}:
write unix @->/var/tmp/spdk.sock: write: broken pipe

It's hard to reproduce and currently unable to find a reliable way to reproduce it. The possible reproducing steps are:

Create a 3-nodes k3s cluster, enable spdk, and add block type disk for each node
Create spdk volume from Longhorn UI, and create PV/PVC for this volume from Longhorn UI. But forget to fill in the right storage class name, leave it blank
Create a workload to use this volume, the volume will be stuck in attaching state:

apiVersion: v1
kind: Pod
metadata:
  name: test-pod-1
spec:
  containers:
    - name: sleep
      image: busybox
      imagePullPolicy: IfNotPresent
      args: ["/bin/sh", "-c", "while true;do date;sleep 5; done"]
      volumeMounts:
        - name: pod-data
          mountPath: /data
  volumes:
    - name: pod-data
      persistentVolumeClaim:
        claimName: test-1

Create spdk storageclass:

kubectl apply -f https://raw.githubusercontent.com/longhorn/longhorn/master/examples/v2/storageclass.yaml

Create a statefulset using spdk volume:

# statefulset.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: statefulset-pvc
  namespace: default
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: longhorn-v2-data-engine
  resources:
    requests:
      storage: 20Gi
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: test-statefulset
  namespace: default
spec:
  selector:
    matchLabels:
      app: test-statefulset
  serviceName: test-statefulset
  replicas: 1
  template:
    metadata:
      labels:
        app: test-statefulset
    spec:
      terminationGracePeriodSeconds: 10
      nodeSelector:
        node-role.kubernetes.io/control-plane: 'true'
      containers:
        - image: busybox
          imagePullPolicy: IfNotPresent
          name: sleep
          args: ['/bin/sh', '-c', 'while true;do date;sleep 5; done']
          volumeMounts:
            - name: test-pod
              mountPath: /data
      volumes:
        - name: test-pod
          persistentVolumeClaim:
            claimName: statefulset-pvc

# kubectl apply -f statefulset.yaml

spdk volume can be created and attached, and the workload is running without problem, then write some data into the volume
Delete replicas of this volume from Longhorn UI
Scale down the statefulset to 0 to detach the volume
The volume can be attached automatically and replica rebuilding triggered
After all replicas rebuilt, the volume detached automatically
scale up the statefulset to 1 to attach the volume again => The volume gets stuck in attaching state forever with error message:

Error starting pvc-1deb58b5-c8b8-4cf2-bb10-02c83877abd6-e-7b4b0d54:
failed to create instance:
rpc error: code = Unknown desc = failed to start SPDK engine:
rpc error: code = Unknown desc = error sending message, id 70374, method bdev_raid_create,
params {pvc-1deb58b5-c8b8-4cf2-bb10-02c83877abd6-e-7b4b0d54 1 0 [pvc-1deb58b5-c8b8-4cf2-bb10-02c83877abd6-r-8eb29e9bn1 disk-1/pvc-1deb58b5-c8b8-4cf2-bb10-02c83877abd6-r-b7cafc48]}:
write unix @->/var/tmp/spdk.sock: write: broken pipe

Describe alternatives you've considered
Since it's hard to reproduce, we can improve the resilience of instance manager first instead of struggling to reproducing it.
Additional context
Detailed support bundle and logs can be found in https://github.com/longhorn/longhorn/issues/6071

To create "broken pipe" error, we can create and attach a volume with three replicas. Then, simply kill -9 spdk_tgt in one of instance manager pods. The SPDK service verify function will emit
[longhorn-instance-manager] time="2023-06-19T07:55:53Z" level=error msg="SPDK Server: failed to verify and update replica cache, will retry later" error="error sending message, id 70405, method bdev_lvol_get_lvstores, params { }: write unix @->/var/tmp/spdk.sock: write: broken pipe"

If running into broken pipe error, we can mark replicas and engines as error. Is it reasonable and feasible?
cc @shuo-wu @innobead

Can you provide a coredump of spdk_tgt as suggested by @derekbit ? I need more details to understand the crash ...

@yangchiu can you provide a coredump of spdk_tgt as suggested by @derekbit ? I need more details to understand the crash ...

The environment has been destroyed, but it would be appreciated if you can elaborate more on how/where can I get the coredump file so next time I encounter this I can keep it for you. Many thanks.

To enable core dump on the machine, add following line to the file /etc/security/limits.conf :
* soft core unlimited

The path of the core dump file depends on the system you are using, but you can discover it reading the file /proc/sys/kernel/core_pattern. On my Tumbleweed (which uses systemd)  I have:
damiano@dhcppc11:~/Development/spdk> cat /proc/sys/kernel/core_pattern
|/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h

and this means that core dump files will be stored in /var/lib/systemd/coredump/
However, if you read man core you can have all the details you need.

Tested on v1.5.x-head (longhorn-instance-manager 3cfa0eb). Hit volume stuck in attaching state issue again by following the original test steps 5 ~ 11. But I'm not sure if it's caused by the same condition we encountered before.
I followed the steps to enable coredump before testing, but still not sure if it's generated correctly.
I keep the environment on equinix. The cluster is yang-test-04 ~ yang-test-06. yang-test-04 is the control plane. And Longhorn UI has a nodeport at 30007. @derekbit @DamiaSan I believe you can ssh access these machines if you can log into equinix.
Also left the support bundle here for reference:
supportbundle_e8daae4a-108e-404b-8da6-8c9a0bed3bd1_2023-06-21T02-45-55Z.zip

Tested on v1.5.x-head (longhorn-instance-manager 3cfa0eb). Hit volume stuck in attaching state issue again by following the original test steps 5 ~ 11. But I'm not sure if it's caused by the same condition we encountered before.
I followed the steps to enable coredump before testing, but still not sure if it's generated correctly.
I keep the environment on equinix. The cluster is yang-test-04 ~ yang-test-06. yang-test-04 is the control plane. And Longhorn UI has a nodeport at 30007. @derekbit @DamiaSan I believe you can ssh access these machines if you can log into equinix.
Also left the support bundle here for reference: supportbundle_e8daae4a-108e-404b-8da6-8c9a0bed3bd1_2023-06-21T02-45-55Z.zip

Always hit the issue?
From the issue, the engine is in error state (which is expected as the implementation in the PR), but the volume is somehow   stuck at attaching state.
Need to check the logic in instance state transition.

Before figuring out the root cause, the workaround is deleting the workload and recreate it.

It looks longhorn-manager doesn't handle the case (code)
e.Status.CurrentState == longhorn.InstanceStateError && v.Status.CurrentNodeID == ""

From a resilience perspective, if a spdk volume is stuck in attaching state or the spdk_tgt is somehow broken. What a user can do for now is deleting the workload and detach the volume unlink the previous behavior (always undetachable). cc @yangchiu Can you help check this?

Somehow the original problematic statefulset/pod/volume is missing/disappeared. I repeat the same steps again (original test steps 5 ~ 11), hit the same issue.

On all the 3 machines we don't have the correct value for the core dump creation:
root@yang-test-04:~# ulimit -a
real-time non-blocking time  (microseconds, -R) unlimited
core file size              (blocks, -c) 0
...

The file /etc/security/limits.conf contains the right row, maybe haven't you rebooted the machine after having updated this file?
The correct value should be:
damiano@dhcppc11:~/Development/spdk> ulimit -a
real-time non-blocking time  (microseconds, -R) unlimited
core file size              (blocks, -c) unlimited
...

We can also set this value with the command
ulimit -S -c unlimited

but it is related to the current session, it is not permanent

Let's focus on verifying if the crashed spdk tgt server can be restarted. For other resilience cases, create other issues to track instead if possible.

Verified passed on master-head (longhorn-manager deb1802) following the test steps. After killed the spdk_tgt, detach the volume can still trigger the offline rebuilding, and the data is intact.


RingWINAPI: Add new functions for resources, temp files and uuid

The newly added functions are:

rGetTempPath
rGetTempFilename
rwaCreateUUID
rwaReadBinaryResource

A sample (testresource.ring) was added to demonstrate the use of the rGetTempPath, rGetTempFilename and rwaReadBinaryResource
Documentation was updated to include the new functions.

Thank you for improving the extension with these nice features
Keep up the GREAT WORK


Advanced device reflection and global setting

LGTM, advanced device enabled, started the advanced Device in the config call in the Sandbox_Swift_UIApp, added debug logging to dump selector in checkThenCaptureAdvancedDevice()
NeuroID.configure(clientKey: "key_live_suj4CX90v0un2k1ufGrbItT5", isAdvancedDevice: true)
added to the login
_ = NeuroID.startSession("fgsdhjklg”)
_ = NeuroID.startAppFlow(siteID: "form_A1b2C345")
Seeing result:
(NeuroID Debug)  ["found selector, captureAdvancedDevice:"]
(NeuroID Info)  ["NeuroID Payload: NeuroHTTPRequest(clientId: "BFE73E05-253E-48CB-8250-7D5819F1AC68", environment: "LIVE", sdkVersion: "5.ios-3.2.0", pageTag: "UNKNOWN", responseId: "1A59A402", siteId: "", userId: nil, registeredUserId: nil, jsonEvents: [NeuroID.NIDEvent, NeuroID.NIDEvent, NeuroID.NIDEvent, NeuroID.NIDEvent], tabId: "B916A96243FB", pageId: "FEB702575549", url: "ios://", jsVersion: "5.0.0", linkedSiteId: Optional("form_A1b2C345"))"]
Ship it!

but I see you already shipped it.


Remove set_trainer method and trainer attribute from the ChatBot class

This makes the following changes:

Removes the set_trainer method from the ChatBot class.

Removes the trainer attribute from the ChatBot class.

Updates the documentation to show to initialize an instance of a training class with a ChatBot instance.

+1


feat: expose monadic quote errors to the user

Description
We implemented monadic errors for trade quotes, but didn't finish propogating them to the user.
This PR implements that (for a limited set of error codes - we can expand these cases at Product's discretion).
Pull Request Type

[ ] :bug: Bug fix (Non-breaking Change: Fixes an issue)
[ ] :hammer_and_wrench: Chore (Non-breaking Change: Doc updates, pkg upgrades, typos, etc..)
[x] :nail_care: New Feature (Breaking/Non-breaking Change)

Issue (if applicable)
N/A
Risk
Medium regression risk to the display of available swappers.
Testing
Get a set of trade quotes, and see that we now show swappers (though greyed out and unselectable) when their quotes have the following error codes:

SwapErrorType.TRADING_HALTED
SwapErrorType.UNSUPPORTED_PAIR

Engineering
☝
Operations
☝
Screenshots (if applicable)

Current dependencies on/for this PR:

develop

PR #5055   👈

This comment was auto-generated by Graphite.


Ghost text: Fire throttled display event

Description
Sends an event when the ghost text becomes visible.
Fires no more than once every 30 seconds to reduce telemetry spam
Test plan

Make a selection, check that the event is fired
Make another selection immediately after, check no event
Make a selection after 30 seconds of waiting, check event is fired again

@chenkc805 Here's a proposal for firing display events for the ghost text. It is limited to fire no more than once every 30 seconds. I think this is sensible as:

It still gives us a good indication as to how often the ghost text shows
It avoids sending lots of telemetry events every single time a user makes a selection, or changes an existing one

Sounds good. Thanks Tom


Rebuild FilterExtensions

Author changed online AVC file only for KSP version bump.

A failed test. the included .version file needs to be changed.


generalization experiments dataset

Hello Sir.
This is a interest work.
When will the generalized dataset be publicly available?
Sincerely.

Thanks for your interest, the generalization  datasets will be posted this week.

@Toneyaya Hello, you are forgot to provide the dataset.

Sorry, It will be ready in a day. Thank you for reminding me.

The dataset files are uploading. You can also follow the tutorial to customize your datasets.


Warn if formData hash values are not strings, to prevent source.on is not a function

In request/request#1495, the example code gets an error like source.on is not a function because one of the values in the formData has for a request or request-promise options hash is not a string.
The form-data module should detect this error and tell the user to ensure all formdata hash values are strings, or writeStreams, or whatever else is valid.

Yeah, looks like legit issue. Do you mind to create a PR? Thank you

@alexindigo That was four months ago. I'm not using the library anymore...

Ok. I'll close this issue then. :) Thanks.

Why would you close an issue without a solution?

You said, you're no longer interested in this issue. So it was logical to close it.
Please let me know if/when you want to get back to it. Thank you.

I meant that I can't really make a pull request for it.
It's still an issue potentially to a lot of people, even if they don't complain about it. It's an instance where the code doesn't check its inputs, which is a defect.

I'd suggest leaving it open so we can track the defect.

Ok.

Thanks @alexindigo!

I'll take a look at this when we do https://github.com/form-data/form-data/issues/137.

Closing as a duplicate of https://github.com/form-data/form-data/issues/137.
Work is being done in https://github.com/form-data/form-data/pull/362.

Also, specifically for converting objects to use formdata syntax see q-flat.


⚠ Bofrost.com has degraded performance

In a317134, Bofrost.com (https://www.bofrost.com) experienced degraded performance:

HTTP code: 200
Response time: 434 ms

Resolved: Bofrost.com performance has improved in 974a84f.


Selection Principles update

This incorporates all changes made in https://github.com/pi-base/data/pull/328 and partially addresses https://github.com/pi-base/data/issues/327.

Updates to https://topology.pi-base.org/spaces/S000022.
Updated https://topology.pi-base.org/theorems/T000141 to sigma-compact implies omega-Menger. (Note that T362 asserts that omega-Menger implies Menger, so nothing is lost in this change.)
Added T363 to deduce that S22 is not Markov omega-Menger.
Added a topological group S179 that is Lindelof but not an epsilon-space.

I have not looked at selection principles before, so here is a basic question.
The notion of $\omega$-cover was introduced by Gerlits and Nagy in https://www.sciencedirect.com/science/article/pii/0166864182900657 with the definition that you have.  Scheepers in https://www.sciencedirect.com/science/article/pii/0166864195000674 defines it with the additional condition that no element of the cover contains $X$ (which seems the same as saying $X$ does not belong to the cover?).  Does this difference matter?

Yeah, the latter is the most common definition. I'm not totally sure off the top of my head what kind of trivialities in terms of the selection principles can arise that are really "problematic." I went with the current formulation since that's what's analogous to https://topology.pi-base.org/properties/P000128, but I will make the changes for non-trivial covers, since that's what's most common in the literature now.

For T362 (omega-Menger ==> Menger), is it really clear?  Why does $\mathsf S_{\mathrm{fin}}(\Omega,\Omega)$ imply $S_{fin}(\mathcal{O},\mathcal{O})$, since an open cover is not an $\omega$-cover in general?  What am I missing?

Yeah, the latter is the most common definition. I'm not totally sure off the top of my head what kind of trivialities in terms of the selection principles can arise that are really "problematic." I went with the current formulation since that's what's analogous to https://topology.pi-base.org/properties/P000128, but I will make the changes for non-trivial covers, since that's what's most common in the literature now.

I would be good to understand.  If a cover contains $X$, isn't it automatically an $\omega$-cover?  And in that case, by choosing $X$ in the selection, one generates something that is also an $\omega$-cover, so it's all trivial.  So wouldn't the definitions of $\omega$-Menger, etc be the same with or without the extra condition?

For T362 (omega-Menger ==> Menger), is it really clear? Why does Sfin(Ω,Ω) imply Sfin(O,O), since an open cover is not an ω-cover in general? What am I missing?

I think here all you have to do is close your open cover under finite unions and apply the $\Omega$ selection principle. Since a finite selection of finite unions can be unraveled into a finite selection, that settles it. The single selection case is not so clear and is a result of Sakai, the paper cited for that particular definition. If you want, I can be more clear and say "by Theorem x" in the definition.

Yeah, the latter is the most common definition. I'm not totally sure off the top of my head what kind of trivialities in terms of the selection principles can arise that are really "problematic." I went with the current formulation since that's what's analogous to https://topology.pi-base.org/properties/P000128, but I will make the changes for non-trivial covers, since that's what's most common in the literature now.

I would be good to understand. If a cover contains X, isn't it automatically an ω-cover? And in that case, by choosing X in the selection, one generates something that is also an ω-cover, so it's all trivial. So wouldn't the definitions of ω-Menger, etc be the same with or without the extra condition?

You're definition right on that, but I think some combinatorial things come up. If you assume that $X$ isn't in the cover, then the covers need be "large," namely, that any finite set is contained in infinitely many distinct open sets of the $\omega$-cover. This is sometimes used and is clearly not necessarily the case if your cover is just {X}, or any finite cover of the space for that matter.

I can be more clear and say "by Theorem x" in the definition.

I think that would be helpful.

Okay, I think I've addressed all of the covers being so that $X$ itself isn't in them and also updated the $\omega$-blank properties with references to page numbers/numbered theorems.

Oh, I updated the results in the properties themselves. E.g. $\omega$-Rothberger is equivalent to the space being Rothberger in each of its finite powers. Therefore, an $\omega$-Rothberger space is Rothberger, using that definition. Should I copy the lines from the properties to the theorem statements?

Oh, I updated the results in the properties themselves. E.g. ω-Rothberger is equivalent to the space being Rothberger in each of its finite powers. Therefore, an ω-Rothberger space is Rothberger, using that definition. Should I copy the lines from the properties to the theorem statements?

Either way, but it's probably ok the way it is.  With this equivalence, the implication $\omega$-Menger ==> Menger, etc is indeed evident.
Btw, for $\epsilon$-space, shouldn't the definition be that $\omega$-covers have countable $\omega$-subcovers (instead of finite)?

Btw, for ϵ-space, shouldn't the definition be that ω-covers have countable ω-subcovers (instead of finite)?

Yes, of course. I fixed that.

What does the settings.json file do?

What does the settings.json file do?

Actually, I was wondering that myself. It loaded up as soon as I opened the branch. I'm not sure if it has something do with how I was interfacing, but I'm sure it can be deleted.

Well, that's all for my comments.  Looks pretty good from what I can see, but I know nothing about games and have not looked at that part.  Hope Lynn or Steven can take a look and approve.
One thing I was curious though.  Comparing P128 ($k$-Lindelöf) and P149 ($\varepsilon$-space = $\omega$-Lindelöf), they both have something with "Lindelöf" in one of their names, but the former has finite subcovers and the latter has countable subcovers.  No consistency there, and I don't have access to the paper for P128, but maybe you can confirm?

One thing I was curious though. Comparing P128 (k-Lindelöf) and P149 (ε-space = ω-Lindelöf), they both have something with "Lindelöf" in one of their names, but the former has finite subcovers and the latter has countable subcovers. No consistency there, and I don't have access to the paper for P128, but maybe you can confirm?

Ah, so that's where my mistake in $\varepsilon$-space originated from. I had copy-pasted from $k$-Lindelof. So I don't have access to the referenced articles (apparently it appears in a book), but taking a look at https://arxiv.org/abs/1201.1576 corroborates the suspicion that it should be countable. I've always seen $k$-Lindelof defined as having countable sub-$k$-covers, so I've made that chance. Perhaps we can update this reference in the future with something a little more accessible.

One basic observation.  In a finite set $X$ there is no $\omega$-cover $\mathcal U$, since $X$ finite would have to belong to $\mathcal U$, but $ \mathcal U$ cannot contain $X$.  So finite sets are vacuously $\omega$-Rothberger and all the other $\omega$ properties.  And that matches the characterization of $\omega$-Rothberger in terms of finite powers of $X$ being Rothberger.  (Of course, for finite sets it's not interesting).
Now for countable, there is https://topology.pi-base.org/theorems/T000341 [countable ==> Rothberger].  So by finite power of countable is countable, we would have [countable ==> $\omega$-Rothberger].  (or not hard to prove also from the other definition).  And presumably countable would imply even stronger properties, up to P152 (Markov $\omega$-Rothberger)?  In any case, should T341 be updated?
And similarly, there are no $k$-covers on a compact space.  So any compact space would be $k$-Rothberger or stronger?

Yes, that would be a sensible thing to do. On this note, I did want to write T141 as "sigma-compact -> Markov omega-Menger", but since that's not the statement in the paper, I didn't want to go too far off the reference list. However, the proof sketched does show that it's a Markov strategy. Would it be acceptable to strengthen T141 this way with the same proof sketch?

Not sure if you mean TR141 or T341?  In any case, for such a situation I think it's perfectly fine to generalize.  We can say something like the paper proves it in the case of ... but the same argument works for .....

Yes, that would be a sensible thing to do. On this note, I did want to write T141 as "sigma-compact -> Markov omega-Menger", but since that's not the statement in the paper, I didn't want to go too far off the reference list. However, the proof sketched does show that it's a Markov strategy. Would it be acceptable to strengthen T141 this way with the same proof sketch?

Not sure if you mean TR141 or T341? In any case, for such a situation I think it's perfectly fine to generalize. We can say something like the paper proves it in the case of ... but the same argument works for .....

I will update both T141 and T341. T141 will be "sigma-compact -> Markov omega-Menger" and T341 will  be "countable -> Markov omega-Rothberger".

The search for an $\omega$-Lindelof space which is not $k$-Lindelof continues. As noted at https://math.stackexchange.com/questions/4717613, all separable metrizable spaces are $k$-Lindelof, which I've added here as T376.

By the argument used for the Fortissimo space (S22), isn't it the case that for anticompact spaces the $\omega$-properties are equivalent to the corresponding $k$-properties? (omega-covers are the same as k-covers).  So one could replace the trait with a theorem.  There would actually be a bunch of such theorems: [$\varepsilon$-space + anticompact ==> $k$-Lindelof], etc, etc At least add the one needed for S22, I'd say.  Kind of tedious to add them all though.  Not sure if we want to.  There is no short-circuit for it, right?

I am not familiar with the Vietoris topology.  What do you recommend as a general reference?  And in particular for the fact that it's also separable metrizable in the case in question.

I am not familiar with the Vietoris topology. What do you recommend as a general reference? And in particular for the fact that it's also separable metrizable in the case in question (may want to add a reference to that in T376).

Yes, that's an excellent question. I'll have to find a good reference other than Michael's paper https://www.ams.org/journals/tran/1951-071-01/S0002-9947-1951-0042109-4/S0002-9947-1951-0042109-4.pdf. In the meantime, there is https://math.stackexchange.com/questions/791334 which basically shows the metrizability criterion (the metric space need not be compact for this to work since defining it for the compact sets only still allows you to define the Hausdorff metric). Separability follows from the separability of the "ground" space since you can fit finite subsets of a dense set into any Vietoris neighborhood. I could have sworn these were in Engelking, but I'm only finding questions about continuous mappings and the Vietoris space in there. It is probably in Kechris' Classical Descriptive Set Theory. I'll check that and find an MR number in the relatively near future if it has the results in question.

By the argument used for the Fortissimo space (S22), isn't it the case that for anticompact spaces the ω-properties are equivalent to the corresponding k-properties? (omega-covers are the same as k-covers). So one could replace the trait with a theorem. There would actually be a bunch of such theorems: (ε-space + anticompact ==> k-Lindelof), etc, etc At least add the one needed for S22, I'd say. Kind of tedious to add them all though. Not sure if we want to. There is no short-circuit for it, right?

Ah, that's a good point! I had wondered about that and forgot about the anticompact property. I'll make that edit along with the Vietoris reference(s). It would be nice to have a sort of schema generator function to apply such a "X + Y -> f(X)" theorem family...

For future reference, Theorem 4.22 in Kechris' Classical Descriptive Set Theory states "If X is a metrizable space, so is K(X). If X is separable, so is K(X)." I'll add this reference in along with an MR number as soon as I can visit my office and have access to MathSciNet.

Also, @prabau since I live my life in a land where all spaces are $T_2$, I get weary around lower separation axioms. I think T374 here might not need $T_1$. The reason I included that hypothesis is because most of the papers I read include a clause like "suppose all spaces are Hausdorff," but also because the proof referenced says basically the following: assume X is not locally compact (but they just need to avoid having a compact neighborhood, so this is weakly locally compact as we currently have) and first-countable. Given a compact K and a neighborhood U of x, $U \setminus (K \cup {x}) \neq \emptyset$ so there is some $y \in U \setminus (K \cup { x })$. Now, they say you can find an open set that contains $K \cup {x}$ that does not contain $y$. Assuming $T_1$, just take $X \setminus {y}$, but maybe you can just take $X \setminus \overline{{y}}$. However, I'm not sure why the closure of ${y}$ needs to be disjoint from $K \cup { x }$ if the space isn't at least $T_1$.

I'm tempted to change T373 to "hemicompact + not compact -> Markov k-Rothberger" for the following reason, which relates to the @prabau 's comment relating to the issue of trivial covers.
Since we are adopting the notion of non-trivial open covers, if $X$ is compact, then the $k$-covers will be so that they only cover proper compact subsets of $X$. Now, I'm not sure, but maybe the Fort space on the reals creates a problem here since the proof of "hemicompact -> k-Rothberger" would basically say to pick an open set $U$ so that $X \subseteq U$. But if we are excluding such open sets, such a move doesn't work. So the issue now is, is there a sequence of proper compact subsets of the Fort space on the reals that does the same thing?

To make things easier in the proof, one can assume wlog that the countable local base $(U_n)$ at $x$ has the $U_n$ strictly decreasing (if there is a minimal nbhd of $x$, that nbhd would be compact, which is contradict the assumption).
But I agree it's hard to conclude without $T_1$ that the closure of $\{y\}$ is disjoint from $K\cup\{x\}$.  At that level of generality, it would not even be true.  For example if $K$ is a single point $z\ne x$, it could be that $z\in\overline{\{y\}}$, so no nbhd of $z$ can avoid $y$.
When we added https://topology.pi-base.org/theorems/T000322, Steven and I had the same discussion in nearly the same context.  We could not figure out how to remove the $T_1$ assumption.  See the reference for that: https://math.stackexchange.com/questions/4585825.

Since we are adopting the notion of non-trivial open covers, if $X$ is compact, then the $k$-covers will be so that they only cover proper compact subsets of $X$. Now, I'm not sure, but maybe the Fort space on the reals creates a problem here since the proof of "hemicompact -> k-Rothberger" would basically say to pick an open set $U$ so that $X \subseteq U$. But if we are excluding such open sets, such a move doesn't work. So the issue now is, is there a sequence of proper compact subsets of the Fort space on the reals that does the same thing?

I don't think there is issue if the space $X$ is compact.  The definition of $k$-cover says it cannot contain $X$ and for every compact subset of $X$ blah blah.  Note that it does not say "for every proper compact subset of $X$".  So if $X$ is compact, no $k$-cover of $X$ exists.  That in turn implies that $X$ is vacuously $k$-Menger, $k$-Rothberger, Markov $k$-Rothberger, etc.  There is no need for any extra assumption in T373.

About T374, I think it would be worth adding a mention of where the $T_1$ assumption is used.  Something like this maybe: "In the proof, the set $O_n(K)$ can be chosen equal to $X\setminus\{x_n(K)\}$, which is open by the $T_1$ property."

According to one of the comments at https://mathoverflow.net/questions/431292 and the linked proof at https://dantopology.wordpress.com/2020/02/18/the-space-of-irrational-numbers-is-not-menger/, the irrational numbers Space 28 is an example of a Lindelof space which is not Menger. I'll get to looking for a peer-reviewed reference, but would a link to https://dantopology.wordpress.com/2020/02/18/the-space-of-irrational-numbers-is-not-menger/ suffice?

We should link to Dan's blog, but here's a direct writeup as well: https://math.stackexchange.com/questions/4727296/is-every-lindelof-space-menger/4727297#4727297

What does the settings.json file do?

Actually, I was wondering that myself. It loaded up as soon as I opened the branch. I'm not sure if it has something do with how I was interfacing, but I'm sure it can be deleted.

Yeah if the github.dev settings get changed, they can be saved to that file. But at least for now we don't want that persisted for all owners of the repo so I've added it to .gitignore (though I should have done that separate to this PR, it's not worth fixing now).

spaces/S000043/properties/P000149.md
Shouldn't this be deducable? E.g. do we have that epsilon-space => Lindelof? If so, this should be deleted.

Well, we have that the Sorgenfrey Line S43 is not an epsilon-space, so I don't think Lindelof is deduced from there. Is it deduced from other properties already in place?

spaces/S000043/properties/P000149.md
Shouldn't this be deducable? E.g. do we have that epsilon-space => Lindelof? If so, this should be deleted.

Well, we have that the Sorgenfrey Line S43 is not an epsilon-space, so I don't think Lindelof is deduced from there. Is it deduced from other properties already in place?

Ah never mind!

While I'm sure it's correct, the proof of spaces/S000022/properties/P000151.md feels like it could be aired out on Math.SE.

What would be the best way to phrase that question? "Is every Fortissimo space strategically $\omega$-Menger?" Also, I recently answered one of my own questions immediately after posting and got a critical comment. I didn't get any downvotes, but it makes me less eager to repeat similar posts.

While I'm sure it's correct, the proof of spaces/S000022/properties/P000151.md feels like it could be aired out on Math.SE.

What would be the best way to phrase that question? "Is every Fortissimo space strategically ω-Menger?" Also, I recently answered one of my own questions immediately after posting and got a critical comment. I didn't get any downvotes, but it makes me less eager to repeat similar posts.

That user needs to read https://math.stackexchange.com/help/self-answer - I've reminded folks of this myself.
In https://math.stackexchange.com/questions/4727296/is-every-lindelof-space-menger/4727297#4727297 I explicitly pointed out my motivation to self-document an answer, maybe that helped.

As for phrasing, maybe just "what selection principles hold for the Fortissimo space" or similar? That also opens the doors for a usser to suggest a stronger selection principle to improve on your answer.

I left a few comments, but importantly everything appears to be correct, so the improvements sugggested could happen in a follow-up PR.
That said, this PR is quite large; it'd have been nice if it was split up into some more managable chunks.

I agree with that. I had originally planned on doing just the $\omega$-principles first. I'm not sure if I had tried to duplicate the PR branch to have a separate PR. Is that something we can do and still push to main? Namely, can I go into a PR branch, copy it, make edits there, and do a PR to main based on the copied branch?

You can make a PR on a branch, then make a second branch directly from it,
and make a PR on that. But you're committing the second PR to assume the
first is successful.
On Thu, Jun 29, 2023, 3:32 PM Chris @.***> wrote:

I left a few comments, but importantly everything appears to be correct,
so the improvements sugggested could happen in a follow-up PR.
That said, this PR is quite large; it'd have been nice if it was split up
into some more managable chunks.
I agree with that. I had originally planned on doing just the $\omega$-principles
first. I'm not sure if I had tried to duplicate the PR branch to have a
separate PR. Is that something we can do and still push to main? Namely,
can I go into a PR branch, copy it, make edits there, and do a PR to main
based on the copied branch?
—
Reply to this email directly, view it on GitHub
https://github.com/pi-base/data/pull/329#issuecomment-1613774308, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAL4YUCCH2ZAWLISZNC4VQ3XNXQ6BANCNFSM6AAAAAAZAULVEE
.
You are receiving this because your review was requested.Message ID:
@.***>

What would be the best way to phrase that question? "Is every Fortissimo space strategically ω-Menger?" Also, I recently answered one of my own questions immediately after posting and got a critical comment. I didn't get any downvotes, but it makes me less eager to repeat similar posts.

I have found that if you post the question, wait a day or two, then answer the question yourself, it goes down very well.

I feel like this has something to do with the fact that the space is not separable, and the finite powers of separable are separable. Is the finite product of metacompact, metacompact? Then https://topology.pi-base.org/theorems/T000024 shows metacompact and separable gives not just Lindelof, but all finite powers lindelof.

The product of two metacompact spaces need not be metacompact.  Example: the Sorgenfrey line and the Sorgenfrey plane:

https://topology.pi-base.org/spaces/S000043/properties/P000031
https://topology.pi-base.org/spaces/S000076/properties/P000031

theorems/T000376.md
https://topology.pi-base.org/spaces?q=Second Countable%2B~%24k%24-Lindelöf is empty, but compare this with https://topology.pi-base.org/theorems/T000061

Now that you mention, second countability clearly implies being $k$-Lindelof. Take your countable basis and close it under finite unions. I'll update T376 to "Second Countable => k-Lindelof" in the PR to address Steven's comments.

theorems/T000376.md
https://topology.pi-base.org/spaces?q=Second Countable%2B~%24k%24-Lindelöf is empty, but compare this with https://topology.pi-base.org/theorems/T000061

Now that you mention, second countability clearly implies being k-Lindelof. Take your countable basis and close it under finite unions. I'll update T376 to "Second Countable => k-Lindelof" in the PR to address Steven's comments.

Beat you to it with https://github.com/pi-base/data/pull/338 though I let the mob do the actual math for me haha.

Was looking around for an example of a Hausdorff space to fit in here: https://topology.pi-base.org/spaces?q=%24\sigma%24-relatively-compact%2B~%24\sigma%24-compact
Example 5.8 in https://doi.org/10.14712/1213-7243.2015.201 claims to do the trick, but I think the proof is faulty. Since the topology on the space includes Euclidean open sets, the open cover of $[-n,n] \setminus \mathbb Q$ consisting of ${ (-\infty, q) : q < n, q \in \mathbb Q }$ has no finite subcover. Am I missing something?


Name vs Email

I noticed that on your log in page it asks for name and password vs the email and password. Was this intentional?

I wondered this too - what happens when two Daves sign up?


chore: add repo homepage

Add repo homepage
Rename github page deploy action
Update cname file location

@mattelen https://shentao.github.io/vue-multiselect/ started working. One more try for https://vue-multiselect.js.org/.


Persistent Volume Radarr

Hello and sorry if this is a dumb question. I don't understand how to add an existing local directory on my kubernetes node as the media volume to the Radarr chart.
I'm pretty new with Kubernetes...

Please join us on discord if you have any questions:
https://discord.gg/hk58BZV


Bump cluster-autoscaler to latest on dev and promote helm chart for autoscaler

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

/lgtm
/approve


Update apm

Requirements for Contributing a Bug Fix

Fill out the template below. Any pull request that does not include enough information to be reviewed in a timely manner may be closed at the maintainers' discretion.
The pull request must only fix an existing bug. To contribute other changes, you must use a different template. You can see all templates at https://github.com/atom/atom/tree/master/.github/PULL_REQUEST_TEMPLATE.
The pull request must update the test suite to demonstrate the changed functionality. For guidance, please see https://flight-manual.atom.io/hacking-atom/sections/writing-specs/.
After you create the pull request, all status checks must be pass before a maintainer reviews your contribution. For more details, please see https://github.com/atom/atom/tree/master/CONTRIBUTING.md#pull-requests.

Identify the Bug
atom/apm#830
Description of the Change
Fixes language package name generation from the template.
Alternate Designs
None.
Possible Drawbacks
None?
Verification Process
See screenshots in atom/apm#830.
Release Notes
N/A

No longer needed.


Add regressions for MS MARCO v2 uniCOIL

Encoding title/body this time.

Codecov Report

Merging #1850 (344831a) into master (4530b59) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master    #1850   +/-   ##
=========================================
  Coverage     57.51%   57.51%
  Complexity     1055     1055
=========================================
  Files           179      179
  Lines         10188    10188
  Branches       1407     1407
=========================================
  Hits           5860     5860
  Misses         3836     3836
  Partials        492      492

Continue to review full report at Codecov.

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


Question : Can't workout -enableAutoWhitelist setting

I am trying to workout a setup with following configuration on a single local machine : -
Zookeeper - 3 isolated instances ( NOT in one ensemble).
	- 1 for helix cluster. 		port 2181
	- 1 for source kafka   		port 2182
	- 1 for destication Kafka          port 2183

Kafka - 2 instances ( 1 broker in each)
	-   1 As source kafka 		port 9092, zk-port 2182
	-   1 As destination Kafka        port 9093, zk-port 2183

helix.properties -
zkServer=localhost:2181
instanceId=testHelixMirrorMaker01
helixClusterName=testMirrorMaker

consumser.properties
zookeeper.connect=<IP_ADDRESS>:2182 // zk instance for source kafka
zookeeper.connection.timeout.ms=30000
zookeeper.session.timeout.ms=30000
group.id=kloak-mirrormaker-test
consumer.id=kloakmms01-sjc1
partition.assignment.strategy=roundrobin
socket.receive.buffer.bytes=1048576
fetch.message.max.bytes=8388608
queued.max.message.chunks=5
auto.offset.reset=smallest

producer.properties
bootstrap.servers=localhost:9093 // destination kafka instance.
client.id=kloak-mirrormaker-test
producer.type=async
compression.codec=none
serializer.class=kafka.serializer.DefaultEncoder
key.serializer=org.apache.kafka.common.serialization.ByteArraySerializer
value.serializer=org.apache.kafka.common.serialization.ByteArraySerializer

uReplicator Controller run arguments:-
startMirrorMakerController -helixClusterName testMirrorMaker -zookeeper localhost:2181 -port 9000 -mode auto -srcKafkaZkPath localhost:2182 -destKafkaZkPath localhost:2183 -enableAutoWhitelist true -autoRebalanceDelayInSeconds 120 -backUpToGit false -localBackupFilePath D:/sambhav/tmp/localBackup
uReplicator worker run argument
startMirrorMakerWorker --consumer.config D:/sambhav/projects/github/uReplicator/config/consumer.properties --producer.config D:/sambhav/projects/github/uReplicator/config/producer.properties --helix.config D:/sambhav/projects/github/uReplicator/config/helix.properties
Questions:-

Should there be a dedicated zk ensemble for helix-cluster or I should share the zk ensemble used by source-kafka|destination kafka ? What is right | recommnded way ?

After running above mentioned components, I am able to replicate topics only after hitting POST http://localhost:9000/topics endpoint. 'enableAutoWhitelist' seems to be not working me. What am I missing here ? I wan't all topics in my source kafka cluster to be replicated to destination cluster.

Thanks.

@ksambhav sorry for the late reply. Does it work now?

zk can be shared. However, I noticed that the zookeeper.connect in consumser.properties didn't include the zk path, e.g. zookeeper.connect=<IP_ADDRESS>:2181/cluster1, which might cause problems.
How long did you wait for the auto-whitelist? Have you created the same topics in destination  cluster? (If a topic is in both source and destination Kafka clusters, the controller auto-whitelists the topic and starts copying data.)

@xhl1988 Yes I am to work it out now. Thanks !


Fix packaging tags to drop Python version support

The recent release of JsonSchema 4.0.0 seems to drop support for Python 2 (and Python 3.5 also but it might been dropped before) but pip is having issues getting the right version depending on the Python version.
The correct information is in the setup.cfg https://github.com/Julian/jsonschema/blob/main/setup.cfg#L23
I think there are two issues for pip to pick the correct version based on the python version:

The python-requires seems to be correctly packaged in the file jsonschema-4.0.0.tar.gz but not in the file jsonschema-4.0.0-py3-none-any.whl. It looks like it's missing the correct metadata in the METADATA file. It should be a line similar to: Requires-Python: >=3.7
For pip to be able to get the correct package version, it needs at least two package versions with the proper package metadata https://packaging.python.org/guides/dropping-older-python-versions/#dropping-a-python-release. I would recommend releasing a version 3.2.1 with the following metadata: python_requires = ">=2.7, !=3.0.*, !=3.1.*, !=3.2.*, !=3.3.*, !=3.4.*".

I believe once both these actions are done, pip should be happy and users should get the proper version of jsonschema installed. I would be happy to help if needed.

@tirkarthi Looks like you are correct, I also think the setup.cfg needs to be corrected.

yes, I just verified it and the metadata is generated correctly.

I just created https://github.com/Julian/jsonschema/pull/846 as a fix.

4.0.0 has been yanked, and 4.0.1 released, which I believe I confirm locally means both pre-3.7 and post 3.7 environments seem to get the correct versions now.
Thanks for the diagnosis and fix @tirkarthi , @Lothiraldan and others.

Thanks @Julian


sqlite checkpointer import error

Checked other resources

[X] I added a very descriptive title to this issue.
[X] I searched the LangGraph/LangChain documentation with the integrated search.
[X] I used the GitHub search to find a similar question and didn't find it.
[X] I am sure that this is a bug in LangGraph/LangChain rather than my code.
[X] I am sure this is better as an issue rather than a GitHub discussion, since this is a LangGraph bug and not a design question.

Example Code
from langgraph.checkpoint.sqlite import SqliteSaver

Error Message and Stack Trace (if applicable)
---------------------------------------------------------------------------
ImportError                               Traceback (most recent call last)
Cell In[46], line 1
----> 1 from langgraph.checkpoint.sqlite import SqliteSaver
      2 # SqliteSaver.config_specs

File ...\Lib\site-packages\langgraph\checkpoint\sqlite\__init__.py:9
      5 from typing import Any, AsyncIterator, Dict, Iterator, Optional, Sequence, Tuple
      7 from langchain_core.runnables import RunnableConfig
----> 9 from langgraph.checkpoint.base import (
     10     WRITES_IDX_MAP,
     11     BaseCheckpointSaver,
     12     ChannelVersions,
     13     Checkpoint,
     14     CheckpointMetadata,
     15     CheckpointTuple,
     16     SerializerProtocol,
     17     get_checkpoint_id,
     18 )
     19 from langgraph.checkpoint.serde.jsonplus import JsonPlusSerializer
     20 from langgraph.checkpoint.serde.types import ChannelProtocol

ImportError: cannot import name 'WRITES_IDX_MAP' from 'langgraph.checkpoint.base'```

Description
Checkpointing is broken-  something broke with internal import statements.
This documentation is also out of date: https://langchain-ai.github.io/langgraph/reference/checkpoints/#sqlitesaver
System Info
System Information

OS:  Windows
OS Version:  10.0.19045
Python Version:  3.11.8 | packaged by conda-forge | (main, Feb 16 2024, 20:40:50) [MSC v.1937 64 bit (AMD64)]

Package Information

langchain_core: 0.2.34
langchain: 0.2.12
langchain_community: 0.2.11
langsmith: 0.1.127
langchain_cli: 0.0.29
langchain_ollama: 0.1.1
langchain_openai: 0.1.22
langchain_text_splitters: 0.2.2
langgraph: 0.2.3
langserve: 0.2.2

Other Dependencies

aiohttp: 3.10.1
async-timeout: 4.0.3
dataclasses-json: 0.6.7
fastapi: 0.112.0
gitpython: 3.1.43
httpx: 0.27.0
jsonpatch: 1.33
langgraph-checkpoint: 1.0.11
langserve[all]: Installed. No version info available.
libcst: 1.4.0
numpy: 1.26.4
ollama: 0.3.1
openai: 1.40.1
orjson: 3.10.6
packaging: 24.1
pydantic: 2.8.2
pyproject-toml: 0.0.10
PyYAML: 6.0.1
requests: 2.31.0
SQLAlchemy: 2.0.32
sse-starlette: 1.8.2
tenacity: 8.5.0
tiktoken: 0.7.0
tomlkit: 0.12.5
typer[all]: Installed. No version info available.
typing-extensions: 4.11.0
uvicorn: 0.23.2

Your dependency list suggests you don't have langgraph-checkpoint-sqlite installed but are trying to import it anyway. I'd suggest installing it with pip install langgraph-checkpoint-sqlite and trying again

mm didn't realize it was unable to install.
ERROR: pip's dependency resolver does not currently take into account all the packages that are installed. This behaviour is the source of the following dependency conflicts.
langchain 0.2.12 requires langchain-core<0.3.0,>=0.2.27, but you have langchain-core 0.3.5 which is incompatible.
langchain-community 0.2.11 requires langchain-core<0.3.0,>=0.2.27, but you have langchain-core 0.3.5 which is incompatible.
langchain-ollama 0.1.1 requires langchain-core<0.3.0,>=0.2.20, but you have langchain-core 0.3.5 which is incompatible.
langchain-openai 0.1.22 requires langchain-core<0.3.0,>=0.2.33, but you have langchain-core 0.3.5 which is incompatible.
langchain-text-splitters 0.2.2 requires langchain-core<0.3.0,>=0.2.10, but you have langchain-core 0.3.5 which is incompatible.
langgraph 0.2.3 requires langchain-core<0.3,>=0.2.27, but you have langchain-core 0.3.5 which is incompatible.
langserve 0.2.2 requires langchain-core<0.3,>=0.1, but you have langchain-core 0.3.5 which is incompatible.

I understand the langchain,langgraph, langsmith ecosystem, but it seems langchain alone being split up into 50 separate libs causes a lot of issues.
It seems it's not on conda. what's the latest working combination of all this stuff?

Langchain 0.3.0 is on conda: https://anaconda.org/conda-forge/langchain

My env  got nuked  uninstalling and reinstalling these packages;  I eventually had to reinstall the 15 GB's of stuff in my env to get  to get it working again. Besides this deprecation warning,  the following versions seem to work. I would recommend following best practices  for packaging ecosystems, or simply having a single langchain lib rather than all these  separate packages.
LangChainDeprecationWarning: As of langchain-core 0.3.0, LangChain uses pydantic v2 internally. The langchain_core.pydantic_v1 module was a compatibility shim
for pydantic v1, and should no longer be used. Please update the code to import from Pydantic directly.

For example, replace imports like: `from langchain_core.pydantic_v1 import BaseModel`
with: `from pydantic import BaseModel`
or the v1 compatibility namespace if you are working in a code base that has not been fully upgraded to
pydantic 2 yet.         from pydantic.v1 import BaseModel

System Information
------------------
> OS:  Windows
> OS Version:  10.0.19045
> Python Version:  3.12.6 | packaged by conda-forge | (main, Sep 22 2024, 14:01:26) [MSC v.1941 64 bit (AMD64)]

Package Information
-------------------
> langchain_core: 0.3.6
> langchain: 0.3.1
> langchain_community: 0.3.1
> langsmith: 0.1.128
> langchain_ollama: 0.2.0
> langchain_openai: 0.2.0
> langchain_text_splitters: 0.3.0
> langgraph: 0.2.28

Optional packages not installed
-------------------------------
> langserve

Other Dependencies
------------------
> aiohttp: 3.10.6
> async-timeout: Installed. No version info available.
> dataclasses-json: 0.6.7
> httpx: 0.27.2
> jsonpatch: 1.33
> langgraph-checkpoint: 1.0.11
> numpy: 1.26.4
> ollama: 0.3.3
> openai: 1.48.0
> orjson: 3.10.7
> packaging: 24.1
> pydantic: 2.8.2
> pydantic-settings: 2.5.2
> PyYAML: 6.0.2
> requests: 2.32.3
> SQLAlchemy: 2.0.35
> tenacity: 8.5.0
> tiktoken: 0.7.0
> typing-extensions: 4.12.2


AudioStreamPlayer not paused on pause mode change

Godot version
3.x 0959ff2
System information
W10
Issue description
When you have AudioStreamPlayer and change its pause_mode, it will not get paused when it should.
Example code:
($AudioStreamPlayer has PAUSE_MODE_PROCESS)
func _ready() -> void:
	get_tree().paused = true
	$AudioStreamPlayer.play()
	yield(get_tree().create_timer(0.5), "timeout")
	$AudioStreamPlayer.pause_mode = Node.PAUSE_MODE_STOP # <- should stop playing here

Does not happen on master.
Steps to reproduce

Add AudioStreamPlayer
Add any long enough sound
Set pause_mode to Process
Add a script with the above code
Run and observe the player not pausing

Minimal reproduction project
No response

I'd like to submit a solution. It seems that, even though we save the new pause_mode, we don't send any notifications about it. I also added a check for can_process when unpausing AudioStreamPlayer (similar as pausing).
I tried to keep the code changes to minimum. This solution works for both cases (process => stop and stop => process), but I haven't check all combinations :) It's possible that we could use a new method here, like propagate_pause_mode. If so, let me know :)

What is even worse, they sounds sometimes do not unpause! They stream_paused stays true, after unpausing.

Fixed by #58577.


Something weird is going on with IPC since 0.35.x

I am seeing an issue both with 0.35.5 as well as latest 0.36.x when doing IPC communication between the browser side and the render side from a close event of a Window.
index.html
<!DOCTYPE html>

    <meta charset="UTF-8">
    <title>Hello World!</title>

Hello World!

    We are using node ,
    Chrome ,
    and Electron .

main.js
'use strict';

const app = require('app');
const ipc = require('ipc');
const BrowserWindow = require('browser-window');

// Keep a global reference of the window object, if you don't, the window will
// be closed automatically when the JavaScript object is garbage collected.
var mainWindow = null;

// Quit when all windows are closed.
app.on('window-all-closed', function () {
    // On OS X it is common for applications and their menu bar
    // to stay active until the user quits explicitly with Cmd + Q
    if (process.platform != 'darwin') {
        app.quit();
    }
});

// This method will be called when Electron has finished
// initialization and is ready to create browser windows.
app.on('ready', function () {
    // Create the browser window.
    mainWindow = new BrowserWindow({ width: 800, height: 600 });

    mainWindow.on('close', function (event) {
        event.preventDefault();

        const channel = Date.now() + '';
        ipc.once(channel, function () {
            console.log('GOT IT')
        });

        mainWindow.webContents.send('onClose', { channel: channel });
    });

    // and load the index.html of the app.
    mainWindow.loadUrl('file://' + __dirname + '/index.html');

    // Emitted when the window is closed.
    mainWindow.on('closed', function () {
        // Dereference the window object, usually you would store windows
        // in an array if your app supports multi windows, this is the time
        // when you should delete the corresponding element.
        mainWindow = null;
    });
});

The sequence goes as follows:

close the window
this will trigger close event for the window on the browser side
we preventDefault() to stop closing from happening and IPC a message to the window renderer side
renderer receives this message and responds back
the browser side does not print GOT IT so the message is lost

Interestingly this works when using the new require("electron") syntax (e.g. require("electron").ipcMain and require("electron").ipcRenderer
I think this is an issue when one of the IPCs or both use the classic import. For some weird reason I cannot get the new import to work in VSCode in this situation but I am hoping that the bug is the same as reported here.

@zcbenz nevermind I think the issue on my end is that since 0.35 there is a new event object being send as first argument for "ipc.on" if you are on the renderer side. I think previously this was not the case.

Still, it seems to me that require("ipc") and require("electron").ipcRenderer differ in this aspect and so the adoption is not just a replacement of the import. I think this should be made clearer.

In the API changes blog post you can find guides on moving to APIs, including the ipcRenderer thing. We have remove all usages of ipc module in current docs, so for new comers will be no surprises.

Thanks for the link.