<_whitenotifier-3>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] f679644 - Deploying to main from @ amaranth-lang/amaranth@f25bf51a928daf45075b6c694c073a7f2eaa1438 🚀
<_whitenotifier-3>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] c43dc80 - Deploying to main from @ amaranth-lang/amaranth@7e18786c9732b15f650682977a74d001c96fc930 🚀
<whitequark[cis]>
<cr1901> "Catherine: When would be a..." <- looking over it, some more comments
<whitequark[cis]>
- is boolector multithreaded at all?
jfng[m] has quit [Quit: Idle timeout reached: 172800s]
<whitequark[cis]>
- you should not be committing a pdm.lock file, nor an empty tests directory
<whitequark[cis]>
- the way version is determined for Python should match other yowasp packages
<whitequark[cis]>
- .dev in a PEP 440 version string is equivalent to .dev0 according to the PEP, it's not up to pdm
<whitequark[cis]>
- there's no CI scripts at all (these tend to be as time consuming as everything else)
<whitequark[cis]>
setuptools_scm is actually just used for the parse_git function, which is a bit cursed, but it's easier to maintain the packages when they all work the same, and yowasp predates me using pdm
<cr1901>
>there's no CI scripts at all (these tend to be as time consuming as everything else) <-- IIRC, you said you wanted to take care of CI/integrating it w/ the other yowasp packages. Did you change your mind?
<cr1901>
Does version detection differ? I'll have to recheck- didn't think it did.
<cr1901>
Yea, I'm not happy with the parse_git stuff, but I couldn't think of anything better within the confines of PDM
<cr1901>
Ack on everything else
<cr1901>
>is boolector multithreaded at all? Did not check. If sby runs any of the solvers multithreaded, that's news to me
<whitequark[cis]>
cr1901: the way it's integrated with pyproject.toml differs--I want you to use setuptools, not pdm-backend (or pdm itself), to match the rest of yowasp
<whitequark[cis]>
you can still use pdm locally, of course, it works fine with setuptools
<whitequark[cis]>
cr1901: if it's not you don't need to branch on threading in build.sh
<cr1901>
oooooooooh, okay. Will do.
<whitequark[cis]>
(and I don't need to maintain that branch in working order)
<whitequark[cis]>
<cr1901> ">there's no CI scripts at all (..." <- yeah. I'm more busy than I anticipated
<cr1901>
Ack
<whitequark[cis]>
please don't upload anything to PyPI or TestPyPI though, that would be a bit annoying to transfer later
<whitequark[cis]>
is boolector still actively developed?
<cr1901>
bitwizula seems to be the successor
<cr1901>
But even if it wasnt actively developed, for riscv-formal use case, boolector is the only solver that gets reasonable solve times
<cr1901>
I stopped yices after 12+ hours for something that took 15 minutes w/ boolector
<galibert[m]>
google never heard of bitwizula, wow
<cr1901>
it's bitwuzla*
<cr1901>
sorry
<whitequark[cis]>
to be clear, if it wasn't actively developed, there would be only two things that I'd ask to be done differently
<whitequark[cis]>
first, you obviously don't need the track-upstream workflow in that case
<whitequark[cis]>
second, I wouldn't ask you to submit the wasm related changes upstream, since there's no point
<cr1901>
Ahhh, well last commit was like 4 months ago. Happy to submit PRs for the patches and see what they think
<cr1901>
I mainly did the patch thing to quickly get something working and not wait on PRs
<whitequark[cis]>
it's fine to have the patch but my policy is to also submit the changes upstream
<galibert[m]>
cr1901: got it. Still, you managed to invent a new name, congrats
<whitequark[cis]>
yeah. wasm threads are still in flux, that branch requires active maintenance
<whitequark[cis]>
also, yowasp uses ccache, not sccache
<whitequark[cis]>
(and you aren't using ccache for the cmake builds)
<whitequark[cis]>
oh, I missed the set()--you are using sccache
<cr1901>
I only have sccache installed locally
<whitequark[cis]>
sure, but ccache is a part of the acceptance criteria
<cr1901>
Then I will install ccache :P
<whitequark[cis]>
the build.sh script is for CI first, and for local builds second; it is the responsibility of whoever checks out the repo to make sure their local environment matches what CI does
<cr1901>
I can make a container too if it really causes problems (not all build trees like having both ccache and sccache installed).
<whitequark[cis]>
right
<whitequark[cis]>
if a lot of people end up wanting to contribute, a dockerfile somewhere under the yowasp org is probably the way to go
<cr1901>
Okay, I'll take care of making yowasp-boolector have parity w/ other packages when I circle back (should be soon)
<whitequark[cis]>
the CDN requires no authentication, so you can just download stuff
<mcc111[m]>
ha ha great
<mcc111[m]>
Catherine: i'm not sure if this is worth an issue but in basic tests, the current amaranth template-fpga fails to pdm install, and then if i delete the pdm.lock, it works
<whitequark[cis]>
interesting
<whitequark[cis]>
it succeeds for me
<mcc111[m]>
then perhaps i did some other thing wrong
<whitequark[cis]>
what does it say?
<whitequark[cis]>
* it say when it fails?
<mcc111[m]>
it appears to succeed but with many weird errors, then i try to run the script and it says "module amaranth not found", i saw this with two repeated pdm install runs, then i deleted pdm.lock and began from beginning and got fewer warnings and the script ran