Pairing: remove preCompute and go routines in MillerLoop

@yelhousni following your recent awesome PR (#26) did some experiments and benchmarks on various architectures (x64), that confirms that for a small number of pair of points in the Pairing function, there is a severe penalty (specifically on amd platforms).
In this PR, I just removed the go routines, the multiple [68]lineEvaluation (replace by a single lineEvaluation object) and merged the preCompute loop within the line evaluation / result compute loop. Did on bn256 and bls381.
** If we want to deal with large number of pairs in Pairing, then we should probably revisit the preCompute strategy **
Here is where we're at on our reference benchmark (running on AWS z1d.3xlarge instance, with hyperthreading disabled) :

mcl(ns/op)
gurvy(ns/op)

Pairing(bn256)
478244
489258

Pairing(bls381)
676513
707984

For the before/after removal of go routines and precompute:
on AMD Ryzen 3700X, bn256 and bls381:
benchmark                  old ns/op     new ns/op     delta
BenchmarkPairing-16        717847        429341        -40.19%
BenchmarkMillerLoop-16     330055        209102        -36.65%

benchmark                  old ns/op     new ns/op     delta
BenchmarkPairing-16        1156689       644036        -44.32%
BenchmarkMillerLoop-16     517074        308647        -40.31%

on Intel MBP, less conclusive but not too bad:
benchmark                 old ns/op     new ns/op     delta
BenchmarkPairing-8        561681        546137        -2.77%
BenchmarkMillerLoop-8     253963        263012        +3.56%

In the last commit, I applied the same changes to bls377.

In the last commit, I applied the same changes to bls377.


question about affine transformation？

Hi, @SuperMHP
I met one question about affine transformation in https://github.com/SuperMHP/GUPNet/blob/f4e26601ba5551065c36ab7ecf17f6915015d311/code/lib/datasets/kitti_utils.py#L398
To get affine matrix, we need to know three pixel pairs.
why dst_dir = np.array([0, dst_w * -0.5], np.float32) rather than dst_dir = np.array([dst_w * -0.5, 0], np.float32).
Namely, why use [width-axis,height-axis] to add [height-axis, width-axis]? This is too strange!!!
In my opinion, the second piexl is the left piexl, so we need np.array([dst_w * 0.5, dst_h * 0.5], np.float32) + np.array([dst_w * -0.5, 0], np.float32).
I am not sure if I misunderstand this transformation and wishing for your reply!

Hi, please refer to the CenterNet repo https://github.com/xingyizhou/CenterNet/issues/377


Mobile build workflow do not cover errors from executable projects

Coming from https://github.com/ppy/osu/actions/runs/3571414877/jobs/6003262801. Currently the workflow only builds osu.Framework.{iOS,Android}, which are only library projects. It should include building SampleGame projects alongside it to cover errors like the ones seen above.

I'm not sure how we can do this, because it fails with:
Error: /Users/runner/.dotnet/sdk/5.0.408/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.TargetFrameworkInference.targets(141,5): error NETSDK1045: The current .NET SDK does not support targeting .NET 6.0.  Either target .NET 5.0 or lower, or use a version of the .NET SDK that supports .NET 6.0. [/Users/runner/work/osu-framework/osu-framework/osu.Framework/osu.Framework.csproj]

Yet another situation where moving to .NET 6 would help.

I would imagine this to work similar to how building osu.iOS osu-side was working all this time.

osu.iOS depends on osu.Game which is only netstandard2.0.
SampleGame.iOS depends on osu.Framework which is netstandard2.0 + net6.0. The msbuild process dies on that net6.0 step.

With the migration to .NET 6, we're now able to build via solution filter and cover executable projects. Closing as fulfilled.


Can't train with multiple GPUs

Hi. Thanks for your work.  The code works in single GPU training but when I try to run in multiple GPUs mode I got an error.
The command I run:
python3 projects/WSL/tools/train_net.py --num-gpus 2 --config-file projects/WSL/configs/PascalVOC-Detection/oicr_WSR_101_DC5_1x.yaml OUTPUT_DIR output/oicr_WSR_101_DC5_VOC07_`date +'%Y-%m-%d_%H-%M-%S'`

The error message:
-- Process 1 terminated with the following error:
Traceback (most recent call last):
  File "/home/anaconda3/envs/detectron2/lib/python3.6/site-packages/torch/multiprocessing/spawn.py", line 20, in _wrap
    fn(i, *args)
  File "/home/anaconda3/envs/detectron2/lib/python3.6/site-packages/detectron2/engine/launch.py", line 94, in _distributed_worker
    main_func(*args)
  File "/home/projects/DRN-WSOD-pytorch/projects/WSL/tools/train_net.py", line 243, in main
    return trainer.train()
  File "/home/anaconda3/envs/detectron2/lib/python3.6/site-packages/detectron2/engine/defaults.py", line 399, in train
    super().train(self.start_iter, self.max_iter)
  File "/home/anaconda3/envs/detectron2/lib/python3.6/site-packages/detectron2/engine/train_loop.py", line 140, in train
    self.run_step()
  File "/home/projects/DRN-WSOD-pytorch/projects/WSL/tools/train_net.py", line 88, in run_step
    loss_dict = self.model(data)
  File "/home/anaconda3/envs/detectron2/lib/python3.6/site-packages/torch/nn/modules/module.py", line 722, in _call_impl
    result = self.forward(*input, **kwargs)
  File "/home/anaconda3/envs/detectron2/lib/python3.6/site-packages/torch/nn/parallel/distributed.py", line 528, in forward
    self.reducer.prepare_for_backward([])
RuntimeError: Expected to have finished reduction in the prior iteration before starting a new one. This error indicates that your module has parameters that were not used in producing loss. You can enable unused parameter detection by (1) passing the keyword argument `find_unused_parameters=True` to `torch.nn.parallel.DistributedDataParallel`; (2) making sure all `forward` function outputs participate in calculating loss. If you already have done the above two steps, then the distributed data parallel module wasn't able to locate the output tensors in the return value of your module's `forward` function. Please include the loss function and the structure of the return value of `forward` of your module when reporting this issue (e.g. list, dict, iterable).

Do you have any suggestions?

We have tested this config again with 4 GPUs for a few iterations.
It works well for us.
I suggest comparing our training log with your log.
or you can show me the training log.

Yes the log.  I will also check your log.

Ok, I will update a new training log later.

Hi, Just an update on this issue -- Re-installing and re-building helps me solve it. Thanks.

Hi, Just an update on this issue -- Re-installing and re-building helps me solve it. Thanks.


Typo in DOC0001 Message

Dear @365businessdev team,
I've noticed there is a typo in the message from code-analyzer rule DOC0001.

I think the text should be "The procedure MyProcedure is missing documentation." (or something similar).

Oops! You're absolutly right. Will fix it with next release.


Move TestProgram into XCT Tests

TestProgram was written to test code that has no easy way to be tested inside XCT test cases (i.e. code that parses env var and argv). We should revisit this issue and see if there is any way to test those code in XCT without having to build a separate executable.

Unable to setenv in Swift code on Linux: https://bugs.swift.org/browse/SR-5076
Moving command-line argv test to XCTest should be possible as CommandLine.arguments is a mutable array. ProcessInfo.processInfo.environment is a get-only dictionary so I'm unable to inject env var to it directly.

Problem should be solved in Package.swift with the new SPM in Swift 4:
https://swift.org/blog/swift-package-manager-manifest-api-redesign/
Export public targets using the product API.

Library packages should explicitly export their public targets to allow other packages to import them. Avoid exporting targets like sample code targets, test support library etc.

+1 on this. My applications all end up with a separate TestProgram target.


Undefined table 'checkpoints' when using Postgres

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.postgres import PostgresSaver
from psycopg import Connection

DB_URI = "postgresql://postgres:postgres@localhost:5432/llama_db?sslmode=disable"
connection_kwargs = {
    "autocommit": True,
    "prepare_threshold": 0,
}

with Connection.connect(DB_URI, **connection_kwargs) as conn:
    checkpointer = PostgresSaver(conn)
    # NOTE: you need to call .setup() the first time you're using your checkpointer
    checkpointer.setup()
    # Finally, we compile it!
    app = workflow.compile(checkpointer=checkpointer)

    config = {"configurable": {"thread_id": "1"}}

    while True:
        user_input=input("User: ")
        if user_input.lower() in ["quit","q"]:
            print("Good Bye")
            break

        for event in app.stream({'messages': user_input}, config, stream_mode='updates'):
            for value in event.values():
                pass

            print_update(event)

        print("Assistant:",value["messages"][0].content)

Error Message and Stack Trace (if applicable)
psycopg.errors.UndefinedTable: relation "checkpoints" does not exist
LINE 34: from checkpoints WHERE thread_id = $1 AND checkpoint_ns = $2...

Description
I was trying this example to create a custom chatbot with memory that is managed according to my logic instead of 6 messages. When i try to use Postgres  instead of MemorySaver() I get the above error message that 'checkpoints' table doesn't exist.
System Info
Ubuntu 20.04
Python 3.11.10
langgraph==0.2.34
langgraph-checkpoint==2.0.1
langgraph-checkpoint-postgres==2.0.1

@vbarda i didn't get any errors i checked the Postgres DB it had the following tables
checkpoint_blobs
checkpoint_writes
checkpoint_migrations
but checkpoints table is not present

@vignesh-spericorn hmm, could you try deleting all checkpoint-related tables you mentioned and then re-running .setup()?

I am having the same issue. Any assist would be helpful.

@kishorekkota i would recommend deleting the tables & rerunning .setup() again. let me know if that fixes the issue

looks like my issue was related to having bad data in thread id section. I was using UUID, i did not format it correctly to be treated as str.  Error message was some what misleading.

@kishorekkota what was the error you were seeing? were you invoking the graph with UUID for thread ID?

@vignesh-spericorn closing the issue due to inactivity, but feel free to reopen if you're still having an issue

@kishorekkota what was the error you were seeing? were you invoking the graph with UUID for thread ID?

Error was:
psycopg.errors.UndefinedFunction: operator does not exist: text = uuid LINE 34: from checkpoints WHERE thread_id = $1 AND checkpoint_ns = $2...

I was pushing UUID directly into the thread_id, making it an object, not a str. I have to fix it by  changing to take hex section and assign to thread_id.
** causing issue **
self.thread_id = uuid.uuid4()
** had to take hex ***
self.thread_id = uuid.uuid4().hex

@kishorekkota got it, thanks! you can also just wrap it in a str -- str(uuid.uuid4())

I ran into this issue. For the async-connection string scenario, make sure to run .setup() with await.
async with AsyncPostgresSaver.from_conn_string(DB_URI) as checkpointer:
    await checkpointer.setup()
    graph = create_react_agent(model, tools=tools, checkpointer=checkpointer)
    config = {"configurable": {"thread_id": "6"}}
    res = await graph.ainvoke(
        {"messages": [("human", "what's the weather in nyc")]}, config
    )
    checkpoint_tuples = [c async for c in checkpointer.alist(config)]

I also ran into this issue. For the async-connection string scenario, make sure to run .setup() with await.
async with AsyncPostgresSaver.from_conn_string(DB_URI) as checkpointer:
    await checkpointer.setup()
    graph = create_react_agent(model, tools=tools, checkpointer=checkpointer)
    config = {"configurable": {"thread_id": "6"}}
    res = await graph.ainvoke(
        {"messages": [("human", "what's the weather in nyc")]}, config
    )
    checkpoint_tuples = [c async for c in checkpointer.alist(config)]

This worked for me.

Faced the same issue... when hosting on FastAPI we manage the connection pool with fastapi lifespan...
@asynccontextmanager
async def lifespan(app: FastAPI):
    postgresql_settings = PostgresqlSettings()
    connection_kwargs = {
        "autocommit": True,
        "prepare_threshold": 0,
    }

    async with AsyncConnectionPool(
        conninfo=postgresql_settings.pg_connectionstring,
        kwargs=connection_kwargs,
    ) as pool:
        checkpointer = AsyncPostgresSaver(conn=pool)

        try:
            await checkpointer.setup()
        except Exception as e:
            print(f"Error setting up checkpointer: {e}")
            raise e

        graph = simple.build_graph(checkpointer)

        app.async_pool = pool
        app.checkpointer = checkpointer
        app.graph = graph

        yield

    await app.async_pool.close()

And in the app we invoke the graph as following:
@router.post(
    "/{session_id}/messages",
    status_code=status.HTTP_201_CREATED,
    response_model=list[Message],
    summary="Add user message to the session",
)
async def add_user_message(
    session_id: str,
    add_message_req: AddMessageRequest,
    req: Request,
) -> list[Message]:
        config = RunnableConfig({"configurable": {"thread_id": session_id}})
        response = await graph.ainvoke({"messages": [("user", content)]}, config=config)
        ai_message = response["messages"][-1].content
        answer_messages = [BotMessage(content=ai_message)]
        return answer_messages

@vbarda Hello, I'm facing the same issue. Could you tell me why the thread table is undefined? Thanks, it's really useful.
2024-12-26T10:43:31.668461Z [error    ] Traceback (most recent call last):
  File "/usr/local/lib/python3.11/site-packages/starlette/routing.py", line 693, in lifespan
    async with self.lifespan_context(app) as maybe_state:
  File "/usr/local/lib/python3.11/contextlib.py", line 210, in __aenter__
    return await anext(self.gen)
           ^^^^^^^^^^^^^^^^^^^^^
  File "/api/langgraph_api/lifespan.py", line 29, in lifespan
  File "/usr/local/lib/python3.11/site-packages/langgraph_storage/database.py", line 148, in start_pool
    await migrate()
  File "/usr/local/lib/python3.11/site-packages/langgraph_storage/database.py", line 108, in migrate
    await cur.execute(stmt.strip(), prepare=False)
  File "/usr/local/lib/python3.11/site-packages/psycopg/cursor_async.py", line 97, in execute
    raise ex.with_traceback(None)
psycopg.errors.UndefinedTable: relation "thread" does not exist


Productization job script

preparing the script to just execute ./build-publish.sh REGISTRY_URL

looks generally ok, few comments:
please add directly there a shell script header and some comment for the argument directly into script.
@paulovmr would be helpful to have a script also for non-linux shells ?

@tiagobento @paulovmr discussing with @mareknovotny we notice probably yarn publish probably is not the right command to execute but we are not 100% sure.
Probably we should replace it by yarn publish-all and add a new script to https://github.com/kiegroup/kogito-tooling/blob/c7bcb0c7e2acf4e6c12a02e9337039d86baa83bb/package.json#L9 with "publish-all": "npx lerna run publish"
WDYT guys?

@Ginxo Yes, you're right. Since this repo is composed by many different packages, we should use Lerna tooling to execute the publish commands on each package. See my comments inline.

@mareknovotny Since this script is only going to be used by our CI/Prod builds, I believe we don't need a Windows version, unless you run these processes in a Windows instance too.

@Ginxo Please take a look at https://github.com/kiegroup/kogito-tooling/blob/b71e7810b115ab4d1da20dae236323badb6df2a8/.github/workflows/publish_artifacts.yml#L82-L87. This is how we publish our packages to NPM. Of course the filtering doesn't need to be applied in this case, but I believe the commands are still slightly different. What's the purpose of this publish:all script?

Closing as I think this subject is resolved now. cc @Ginxo

Closing as I think this subject is resolved now. cc @Ginxo


FIxes Issue #58

Fixes #58
The buttons were not displayed because of an exception in the GetAttributes method from the ProductAttributeService.
I fixed that code to handle the case where Attributes have been deleted.
I also added code to the ProductAttributesPartDriver, so that when the Part is saved, any deleted attributes are removed from the record.

The change I had to make to the validation makes it so that the record for the ProductAttributesPart is also updated whenever someone tries to add the product to the cart.


cmd/link: darwin_amd64: running dsymutil failed: signal: segmentation fault

Just to get this out of the way: a very similar issue was described in #23046, but I'm running a version of Go that includes the fix to that issue.
What version of Go are you using (go version)?
go version devel +a62071a209 Sat Jan 6 04:52:00 2018 +0000 darwin/amd64

Does this issue reproduce with the latest release?
No.
What operating system and processor architecture are you using (go env)?
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/benesch/Library/Caches/go-build"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/benesch/go"
GORACE=""
GOROOT="/usr/local/Cellar/go/HEAD-a62071a/libexec"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/HEAD-a62071a/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/2m/klw683vj1575nyyymnc0mr280000gn/T/go-build978307768=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?
go get -d github.com/cockroachdb/cockroach
cd $(go env GOPATH)/src/github.com/cockroachdb/cockroach
make build GOVERS=.

What did you expect to see?
A built cockroach binary.
What did you see instead?
go build -i -o ./cockroach -v  -tags ' make x86_64_apple_darwin16.7.0' -ldflags ' -X github.com/cockroachdb/cockroach/pkg/build.typ=development -X "github.com/cockroachdb/cockroach/pkg/build.tag=up-784-g742b93b01" -X "github.com/cockroachdb/cockroach/pkg/build.utcTime=2018/01/08 15:31:57" -X "github.com/cockroachdb/cockroach/pkg/build.rev=742b93b0111e0370bf793aeb3323ad153dd2635d"' .
# github.com/cockroachdb/cockroach
/usr/local/Cellar/go/HEAD-a62071a/libexec/pkg/tool/darwin_amd64/link: /usr/local/Cellar/go/HEAD-a62071a/libexec/pkg/tool/darwin_amd64/link: running dsymutil failed: signal: segmentation fault

A few thoughts, in no particular order:

The affected package depends on several packages that make heavy use of cgo.
I'm afraid I don't have the expertise necessary to produce a smaller reproduction.  I don't have the faintest idea what's going wrong.
You only need to run make build in the Cockroach repository once to compile a few C/C++ dependencies. We generate Go files with the appropriate cgo flags so that, after the first make build, a bare go build will work correctly (until the C/C++ dependencies need to be recompiled, of course).
I've collected the output of go build -x -ldflags=-v.
go build -ldflags=s and go build -ldflags=-w both produce working binaries, which suggests the problem is DWARF-related, as in #23046.

Closing this out, has been fixed for a while.

I just subscribed to this a couple of days ago because I'm sill getting it after upgrading to 1.10.1. What was/is the fix?

"running dsymutil failed" means that the Go toolchain produced a binary that was rejected by macOS's toolchain. There are myriad reasons this could happen—basically any misplaced bit during linking could cause this—and it's statistically unlikely that it happens to be the same problem that was addressed here.
I think you're best off filing another issue with a code sample that reproduces the issue!

Agree with @benesch -- there are many reasons why dsymutil can have problems. Please file an issue if possible.


Two '404' Prod Failures 3/7/23

Problem statement
Two (2) failures were reported via slack that simply state a "status code 404 error."
What you need to know

Exception message: not-found: Request failed with status code 404 error
Client IP is listed as <IP_ADDRESS> and with a City/State of Herndon, VA
Operation Name: /file-handler/validate
Under 'activeMembership,' the "parsedName" value is "vt-doh"

not-found: Request failed with status code 404
at https://reportstream.cdc.gov/static/js/main.caab66a3.js:2:2802871
at c (https://reportstream.cdc.gov/static/js/main.caab66a3.js:2:984768)
at Generator._invoke (https://reportstream.cdc.gov/static/js/main.caab66a3.js:2:984521)
at Generator.throw (https://reportstream.cdc.gov/static/js/main.caab66a3.js:2:985131)
at Cn (https://reportstream.cdc.gov/static/js/main.caab66a3.js:2:990004)
at s (https://reportstream.cdc.gov/static/js/main.caab66a3.js:2:990245)

Acceptance criteria

Resolve 404 error, ensure any missed data is resubmitted, and confirm no further issues.

To do

[x] Assign to engineer
[ ] Investigate the cause of the 404 error
[ ] Resolve the underlying issue and confirm normal function

This failure has been resolved and resubmitted.


Calculated abundance for paired-end sequencing

In ARGs-OAP V3.2, each sample produces paired-end files corresponding to two results of ARGs abundance. I wonder if the abundance of ARGs from each sample is the sum of the abundances of the paired-end files. Thank you for your reply.

if your paired files ends with _1|_2, _R1|_R2 or _fwd|_rev, a sample should show up only once in your output file.
if the abundance is defined as copies per 16s/cell/Gb, then you cannot simply sum the abundance of _1 and _2 up.

if your paired files ends with _1|_2, _R1|_R2 or _fwd|_rev, a sample should show up only once in your output file.
if the abundance is defined as copies per 16s/cell/Gb, then you cannot simply sum the abundance of _1 and _2 up.

Thanks for your answer! Can we calculate the average value of them as the relative abundance (copies per 16s/cell/Gb)?

yes, _1 and _2 should have similar abundance


Appstudio update mvp-test-component

Pipelines as Code configuration proposal

Pipelines as Code CI/mvp-test-component-on-pull-request has successfully validated your commit.

StatusDurationName

✅ Succeeded
6 seconds
init

✅ Succeeded
18 seconds
clone-repository

✅ Succeeded
1 minute
build-container

✅ Succeeded
13 seconds
deprecated-base-image-check

✅ Succeeded
13 seconds
sanity-inspect-image

✅ Succeeded
17 seconds
clair-scan

✅ Succeeded
59 seconds
clamav-scan

✅ Succeeded
11 seconds
sbom-json-check

✅ Succeeded
17 seconds
sanity-optional-label-check

✅ Succeeded
17 seconds
sanity-label-check

✅ Succeeded
5 seconds
show-summary


Won't run using Visual Studio 2017

Hello,
Im' already familiar with the original tool chain, so I was happy to see your NuGet-Package here on GitHub. However, I can't get it to run with Visual Studio 2017. Did you ever try it using Visual Studio 2017?
I tried using VS2015 and it seems to run fine there... Any thoughts?
Regards,
tajbender

It seems it has to do with conceptual changes in VS2017: Changes in Visual Studio 2017 extensibility


Error block submit in  bitcoin testnet:{"result":"inconclusive","error":null,"id":"1"}

Testing in bitcoin testnet and got several:
{"result":"inconclusive","error":null,"id":"1"}
Is it a known issue?

testnet = true;

must be set at
build/run_jobmaker/jobmaker.cfg
build/run_sserver/sserver.cfg
for bitcoin testnet3 mining.
If you still have the problem, please tell me the version of the bitcoin source code you linked to, and paste your build/run_sserver/sserver.cfg.

The code version is commit: 206e610db7e885d1da11f7d17312242935700eba
Yes, i set testnet = true in those files.
Here's my sserver.cfg
testnet = true;

kafka = {
  brokers = "ip:9092";
};

sserver = {
  ip = "<IP_ADDRESS>";
  port = 3339;

  // should be global unique, range: [1, 255]
  id = 1;

  // write last mining notify job send time to file, for monitor
  file_last_notify_time = "/path-to-sserver_lastnotifytime.txt";

  // if enable simulator, all share will be accepted. for testing
  enable_simulator = false;

  // if enable it, all share will make block and submit. for testing
  enable_submit_invalid_block = false;

  // how many seconds between two share submit
  share_avg_seconds = 10;
};

users = {
  //
  // https://example.com/get_user_id_list?last_id=0
  // {"err_no":0,"err_msg":null,"data":{"jack":1,"terry":2}}
  //
  list_id_api_url = "http://ip/GetUserList";
};

Seems about 50% of the block submit got this error.

I want to know the bitcoin's version your linked to BTCPool.
You know you need download a bitcoin's source code before building BTCPool.
The consensus rule about how to build a block is provided by the bitcoin's source code, not BTCPool.
The block may invalid if the bitcoin's source code your linked to BTCPool not match your actual running node.
Please provide the bitcoin node's version that your running, and the bitcoin source code's version that your linked to BTCPool.

The version of the bitcoin source code i was using is the latest release: https://github.com/bitcoin/bitcoin/archive/v0.16.0.tar.gz
Thanks!

looks like late blocks, you could provide some log with jobmaker and sserver.

I checked around the invalid blocks, seems the issue only happened when the testnet net diff was set to 1, (one nBits sample : 486604799), so the reason could be too many block submits at the same time from miners and mine was late. Please let me know your thoughts, thanks for your time!

It is entirely possible. The situation occurs if the miner has the ability to found multiple blocks before switching jobs. For example, mining in a regression test network.

I see, thanks. So the issue can be closed I think. Thank you very much!


Update README.md

a little shoutout to both of us?  :grimacing: :beers:

excellent, I was thinking about adding your praise the other day :+1:


[Release] Increase version to 0.4.5

Codecov Report

Merging #105 (ac32bd3) into main (a481165) will not change coverage.
The diff coverage is n/a.

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #105   +/-   ##
=======================================
  Coverage   98.76%   98.76%
=======================================
  Files          61       61
  Lines         970      970
  Branches      195      195
=======================================
  Hits          958      958
  Misses         12       12

Impacted Files
Coverage Δ

lib/src/array/forEach.ts
100.00% <ø> (ø)


[Feature Request] Python 3.14 TypeForm support

          **Good news everybody!**

PEP 747 will likely land soon (unlike some of the same-numbered planes ^^). It defines a new annotation TypeForm[T], which can be used in place of type[T] and explicitly supports type narrowing. If it is accepted, it will be in Python 3.14 and according to the docs it should be part of the next minor release of typing-extensions. Then we can have our cake 🎉🍰
Originally posted by @lorenzo-w in https://github.com/beartype/beartype/issues/166#issuecomment-2391289803
JWCS:
Moved to new, open issue to better track. Builds off the discussions in #166 and #255, but it's really a whole new feature. Tho, I hope it'll happen, since Jelle & Eric are pushing it. Might need to get added to the 3.14 milestone... which means we have a year to fix the other bugs procrastinate.

unlike some of the same-numbered planes ^^

Ho, ho. What's this? A Boeing breakdown meme in my tracker!? :rofl:

@beartype 0.18.0 and the 2024 edition of boeing share much in common

PEP 747 will likely land soon!

Oh, frabjous day! That's genuinely wonderful news. The days of is_bearable(obj: object, hint: object) -> bool: are long behind us, everybody. Python 3.14 brings many gifts to the weary and the wasted – including:
is_bearable[T](obj: object, hint: typing.TypeForm[T]) -> typing.TypeIs[T]:

The future is upon us and it finally feels good. :partying_face:

Boring Update (Stardate 1739.12): In preparation for the coming glory that is PEP 747, I'm very leisurely annotating all type hints across the entire @beartype as TypeForm. Previously, @beartype used to annotate type hints as object. This probably makes @beartype the first type-checker to begin supporting PEP 747. Of course, PEP 747 is still an unaccepted draft and nobody else currently supports PEP 747. @beartype starting to walk this road thus means nothing to nobody.
In fact, I had to tell mypy and pyright to both "...shut up already!" about TypeForm not existing. Here's how @beartype portably defines TypeForm in a future-proofed way despite TypeForm not actually existing:
# Portably backport *ALL* type hint factories introduced by subsequent Python
# interpreters more recent than that of the oldest actively maintained Python
# interpreter still supported by @beartype, regardless of the current version of
# Python and regardless of whether this submodule is currently being subject to
# static type-checking or not. Praise be to MIT ML guru and stunning Hypothesis
# maintainer @rsokl (Ryan Soklaski) for this brilliant circumvention. \o/
#
# If this submodule is currently being statically type-checked (e.g., mypy),
# intentionally import from the third-party "typing_extensions" module rather
# than the standard "typing" module. Why? Because doing so eliminates Python
# version complaints from static type-checkers (e.g., mypy, pyright). Static
# type-checkers could care less whether "typing_extensions" is actually
# installed or not; they only care that "typing_extensions" unconditionally
# defines this type factory across all Python versions, whereas "typing" only
# conditionally defines these type factories under particular Python versions.
if TYPE_CHECKING:
    ...

    # ....................{ PEP 747                        }....................
    # PEP 747-compliant "TypeForm[...]" type hints first introduced by Python
    # >= 3.14 are a high internal priority for @beartype. Hinting parameters,
    # returns, and local variables of both private and public @beartype
    # callables (including the common first parameter "hint" accepted by most
    # callables) with type forms created by this factory enables static
    # type-checkers to ensure that these objects are actually type hints.

    #FIXME: Unconditionally globalize this *AFTER* dropping Python 3.13: e.g.,
    #   from typing import TypeForm as TypeForm
    #FIXME: Remove "# type: ignore[attr-defined]" *AFTER* "typing_extensions"
    #officially supports PEP 747.
    from typing_extensions import TypeForm as TypeForm  # type: ignore[attr-defined]
# Else, this submodule is currently being imported at runtime by Python. In this
# case, dynamically import these type factories from whichever of the standard
# "typing" module *OR* the third-party "typing_extensions" module declares these
# factories, falling back to various builtin types if none do.
else:
    ...

    # ....................{ PEP 747                        }....................
    TypeForm = import_typing_attr_or_fallback(
        'TypeForm', TypeHintTypeFactory(object))

All the karmic glory goes to Hypothesis maintainer @rsokl, long may he win the Internet. \o/


Moving a pinned editor unpins it

Testing https://github.com/microsoft/vscode/issues/98019
Drag a pinned tab and drop it on a tab bar empty space. I expected it to remain pinned. 🤷

@joaomoreno can you clarify, do you only have 1 pinned tab? In general, moving a pinned tab after the last tab will unpin it if that last tab is unpinned.

In general, moving a pinned tab after the last tab will unpin it if that last tab is unpinned.

You seem to distinguish between the last tab of the drop container being pinned or not. As a user, this doesn't make much sense, since my perception is that I'm dragging a pinned tab onto a container, so it should remain pinned, independently of what the state of the last tab of that container is.

Well, my argument is that you are dropping a tab after an existing tab of a tab group. Now I am in conflict: should the tab be pinned or should it be after the last tab. Pinned tabs cannot be after unpinned tabs (currently), so I can either respect the index of the tab (which I prefer) or the pinned state.

Isn't a split different than a drag and drop? :think

Yeah, fair point. Again, I am preferring to preserve the index, not the pinned state here. If you drop into an empty group, I preserve pinned state.

@bpasero  🙈

POWERED BY GIFCAP

@joaomoreno well that is just how Chrome behaves. I decided to do what Safari does which allows you to easily drag/drop tabs in and out of pinning state (which is something I heard from users is good to have).


Update the dependencies to kuberntest-1.10.0 version

What this PR does / why we need it:
It updates the Kubernetes dependencies to 1.10.0 version.
Special notes for your reviewer:
We would like to use the sonobuoy client in jenkins-x but there is a dependencies conflict at the moment with 1.9.
The changes are tested with GKE. The compliance E2E run successfully.
Release note:
release-note

cc @jstrachan

Thank you for the PR, but I'll be updating for v1.11 in the coming week(s).