-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Chore/update nim version #1052
Chore/update nim version #1052
Conversation
codex/rest/json.nim
Outdated
@@ -90,7 +90,7 @@ proc init*(_: type RestNode, node: dn.Node): RestNode = | |||
peerId: node.record.data.peerId, | |||
record: node.record, | |||
address: node.address, | |||
seen: node.seen | |||
seen: node.alreadySeen() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@cskiraly Is this the right method to call to verify that a node is seen?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
alreadySeen tells you whether it had been already seen (responded) at least once.
seen, instead, gives you a exponential moving average of responses (or missing responses), with more weight on recent attempts.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay so if I want to detect the connection with a peer is "good enough", I could check that node.seen > 0.5 I guess ? 0.5 is totally arbitrary.
…e coding fix attempt code
# Conflicts: # codex/contracts/clock.nim # codex/contracts/market.nim # codex/utils/asyncstatemachine.nim # tests/integration/nodeprocess.nim # tests/integration/testecbug.nim # tests/integration/testmarketplace.nim # tests/integration/testproofs.nim
if: inputs.os == 'windows' | ||
shell: ${{ inputs.shell }} {0} | ||
run: | | ||
git config --global core.symlinks false |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@veaceslavdoina Double check if it is okay for you
tests/codex/testchunking.nim
Outdated
expect Defect: | ||
await raiseStreamException(newException(CatchableError, "test error")) | ||
# This test cannot exist anymore. | ||
# The signature of the method readOnce is explicitly listing the error raised: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cool, I think we can get rid of this test completely.
Great job! This is looking really good, lets try to merge this ASAP |
if: inputs.os == 'windows' | ||
shell: ${{ inputs.shell }} {0} | ||
run: | | ||
pacman -U --noconfirm https://repo.msys2.org/mingw/ucrt64/mingw-w64-ucrt-x86_64-gcc-13.2.0-6-any.pkg.tar.zst https://repo.msys2.org/mingw/ucrt64/mingw-w64-ucrt-x86_64-gcc-libs-13.2.0-6-any.pkg.tar.zst | ||
pacman -U --noconfirm https://repo.msys2.org/mingw/ucrt64/mingw-w64-ucrt-x86_64-gcc-14.2.0-2-any.pkg.tar.zst https://repo.msys2.org/mingw/ucrt64/mingw-w64-ucrt-x86_64-gcc-libs-14.2.0-2-any.pkg.tar.zst |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Windows is installing latest GCC version, which currently is 14 and 15 is on the way :)
We can remove this step, but later we might have an issue with version 15 (?).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For Windows 2025 right ?
But the windows-latest is still pointing on windows-2022 which is using gcc 12.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We are not relying on the preinstalled GCC on Windows. It is about MSYS2 and how it works
MSYS2 is a rolling release distribution
At some point, it will just install latest GCC and version 15 will be released in March~April (#875 (comment)). It will appear in MSYS2 repository with a delay and we can expect an issue in August, as we had it with the version 14 😄
So, if we remove that step, we can get in the the issue in August, but will have latest GCC releases all the time.
Let's leave it to have a stable CI?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We are not relying on the preinstalled GCC on Windows. It is about MSYS2 and how it works
Ah ok.
Let's leave it to have a stable CI?
Yeah I agree. I prefer to leave it for now and after testing GCC 15, we could remove it.
@@ -40,6 +40,7 @@ jobs: | |||
os: ${{ matrix.os }} | |||
shell: ${{ matrix.shell }} | |||
nim_version: ${{ matrix.nim_version }} | |||
coverage: false |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should add an input coverage
to the .github/actions/nimbus-build-system/action.yml and set it false
by default, than pass true
just for coverage (we are doing it already).
https://github.com/codex-storage/nim-codex/actions/runs/12689785802
os {linux}, cpu {amd64}, builder {ubuntu-20.04}, tests {contract}, nim_version {${{ env.nim_version }}}, shell {bash --noprofile --norc -e -o pipefail} | ||
os {linux}, cpu {amd64}, builder {ubuntu-20.04}, tests {integration}, nim_version {${{ env.nim_version }}}, shell {bash --noprofile --norc -e -o pipefail} | ||
os {linux}, cpu {amd64}, builder {ubuntu-20.04}, tests {tools}, nim_version {${{ env.nim_version }}}, shell {bash --noprofile --norc -e -o pipefail} | ||
os {linux}, cpu {amd64}, builder {ubuntu-latest}, tests {unittest}, nim_version {${{ env.nim_version }}}, shell {bash --noprofile --norc -e -o pipefail} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We switched to ubuntu-20.04
in #939 and because of the #932.
Probably we should stick with the 20.04?
Btw, we also have a release workflow and 20.04
is required mostly for releases. But as I remember, there can be an issue when cache from latest
(24.04
) is restored on 20.04
and vice versa.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably we should stick with the 20.04?
There are two problems: 1- 20.04 will be deprecated soon, 2- I am not sure I will be able to install GCC 14 on ubuntu 20.04.
Maybe #932 is fixed now with the update to Nim 2.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It was related to the glibc version. So, new releases will not run on old distributions.
Deprecation will begin on 2025-02-01 and the image will be fully unsupported by 2025-04-01.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, this is what we discussed yesterday.
Running make clean, make update, and make, works without any issues on my Win11 MSYS2-UCRT. |
# Conflicts: # codex/node.nim # tests/codex/node/testcontracts.nim # vendor/nim-ethers
# Conflicts: # codex.nim # codex/conf.nim # codex/discovery.nim # tests/codex/slots/testbackendfactory.nim # tests/codex/slots/testprover.nim # tests/contracts/testDeployment.nim # vendor/nim-ethers
Update Nim to
2.0.122.0.14