Not sure if it's best to relay this information here, on Matrix or elsewhere but—

Got branch 7-does-not-appear-to-build-on-windows built and programmed. The light blinks. However, when I plugged it into a spare Samsung HDMI monitor, I did not see the blinking as expected. The HDMI monitor does react, but it oscillates between a black and a different black with a icon in the top left as if the monitor is rapidly gaining and losing signal. The blink pattern is erratic and not the same as the LED blink rate.

Is this surprising?

https://mastodon.social/@mcc/111155360337843136

So integer lists must be treated as int64, and scale between -2^63 and 2^63. That's kind of annoying.

Hm, yeah, from a user perspective this is an unusual enough range that if it cannot be changed to something less surprising, it might actually be better for it to error on integer lists.

Oh, the_cradle.deployer appears to write build\top.bit. And programming that I get a blinking light… exciting, let me try a monitor.

python -m pip install yowasp-yosys
set YOSYS=C:\Users\Andi\work\f\other\the-cradle-colorlight-i9-ecp5-amaranth-hdl\.venv\Scripts\yowasp-yosys.exe
python -m pip install yowasp-nextpnr-ecp5
set NEXTPNR_ECP5=C:\Users\Andi\work\f\other\the-cradle-colorlight-i9-ecp5-amaranth-hdl\.venv\Scripts\yowasp-nextpnr-ecp5.exe
set ECPPACK=C:\Users\Andi\work\f\other\the-cradle-colorlight-i9-ecp5-amaranth-hdl\.venv\Scripts\yowasp-ecppack.exe
set OPENFPGALOADER=C:\Users\Andi\work\f\other\the-cradle-colorlight-i9-ecp5-amaranth-hdl\fake_openFPGALoader.bat
python -m the_cradle.deployer

THIS appears to have worked, and the arguments to my fake openFPGALoader were -c cmsisdap -m C:\Users\Andi\AppData\Local\Temp\amaranth_h21e5e7__top.bit

However, the file C:\Users\Andi\AppData\Local\Temp\amaranth_h21e5e7__top.bit does not exist.

Does the_cradle.deployer delete the file after it is done programming? I would prefer to use ecpdap rather than openFPGALoader.

I put some additional thoughts in #7.

I don't know if this is a real problem. But I tried running pdm install in the project directory to create a venv. This was not necessary (python -m venv also works). When I tried it it printed these errors:

C:\Users\Andi\work\f\other\the-cradle-colorlight-i9-ecp5-amaranth-hdl>python.exe -m pdm install
Lock file does not exist
Updating the lock file...
C:\Users\Andi\AppData\Roaming\Python\Python311\site-packages\pdm\models\candidates.py:584: ExtrasWarning: Extras not found for
setuptools-scm: [toml]
  return filter_requirements_with_extras(
🔒 Lock failed
Unable to find a resolution for amaranth
because of the following conflicts:
  amaranth @ git+https://github.com/amaranth-lang/amaranth@f135226a79fddf5caf894030ac7f49995774c3a7 (from
amaranth-stuff-by-sporniket@git+https://github.com/sporniket/amaranth-stuff@22130d399e82e146aa5a7d4708ec26b002979bab)
  amaranth<0.5,>=0.3 (from
amaranth-boards@git+https://github.com/amaranth-lang/amaranth-boards@91ffa38e788a691464a6873d44537eece72ef76e)
To fix this, you could loosen the dependency version constraints in pyproject.toml. See
https://pdm.fming.dev/latest/usage/dependency/#solve-the-locking-failure for more details.
See C:\Users\Andi\AppData\Local\Temp\pdm-lock-p6kykd8o.log for detailed debug log.
[ResolutionImpossible]: Unable to find a resolution
Add '-v' to see the detailed traceback

I saw this on both the main branch and the 7-does-not-appear-to-build-on-windows branch.

Despite the error, the created venv worked fine. Since your build instructions do not suggest use of pdm I don't know if this is even a problem. Do you think this is a problem…?

Can confirm, resolved

As we discussed in the other issue, recently Amaranth has moved over to a build/deployment system based on pdm. pdm is like npm for python, you can use it in a venv-like way but the normal way is to invoke pdm scripts like python -m pdm run scriptname which then run inside pdm's venv. In 7-does-not-appear-to-build-on-windows you have upgraded to amaranth pdm, but you could go further.

If you compare amaranth projects based on current sample code— for example see this project for doppler (I messed up the build system a little here, see run.txt) or this project for Analogue Pocket, both forks of whitequark templates— every part of install, build and synthesis is managed through pdm. External tools like bash are not needed, everything is scripted through python. A yosys installation is not needed because of some thing whitequark rigged up where yosys is compiled as a wasm blob installed via a python package. In the basic template a bitstream can be created directly from pdm run build_ice40 (which executes function build_ice40() in amaranth_template_fpga/init.py(), see pyproject.toml).

If your workflow works for you, then you do not need to do this :) But, moving to this approach would be more in line with other current Amaranth-based projects and aid with running on a broader range of configurations (for example in #7 to run on Windows I am currently having to open the bash script in a second window and mentally convert it to windows cmd line by line when I type commands, also the bash script has the minor problem that it assumes the python executable is named python3).

Updated the 7-does-not-appear-to-build-on-windows branch and ran

git clean xffd
python.exe -m pdm install
python.exe -m pdm build # I think this didn't do anything?
.venv\Scripts\activate.bat 
python -m ensurepip
python -m pip install --upgrade build pytest twine black coverage
python -m build
python -m pip install --force-reinstall dist\the_cradle_colorlight_i9_ecp5_amaranth_hdl_by_sporniket-0.0.0-py3-none-any.whl
python -m the_cradle.deployer

This time I got further! However on the final step I got this error

(the-cradle-colorlight-i9-ecp5-amaranth-hdl-3.11) C:\Users\Andi\work\f\other\the-cradle-colorlight-i9-ecp5-amaranth-hdl>python -m the_cradle.deployer
========================[ START OF Deployment ]============================
Traceback (most recent call last):
  File "<frozen runpy>", line 198, in _run_module_as_main
  File "<frozen runpy>", line 88, in _run_code
  File "C:\Users\Andi\work\f\other\the-cradle-colorlight-i9-ecp5-amaranth-hdl\.venv\Lib\site-packages\the_cradle\deployer.py", line 48, in <module>
    Deployer(Colorlight_I9_V7_2_Platform(), TheCradle()).deploy()
  File "C:\Users\Andi\work\f\other\the-cradle-colorlight-i9-ecp5-amaranth-hdl\.venv\Lib\site-packages\the_cradle\deployer.py", line 43, in deploy
    self.endpoint.build(self.payload, do_program=True)
  File "C:\Users\Andi\work\f\other\the-cradle-colorlight-i9-ecp5-amaranth-hdl\.venv\Lib\site-packages\amaranth\build\plat.py", line 103, in build
    require_tool(tool)
  File "C:\Users\Andi\work\f\other\the-cradle-colorlight-i9-ecp5-amaranth-hdl\.venv\Lib\site-packages\amaranth\_toolchain\__init__.py", line 33, in require_tool
    raise ToolNotFound("Could not find required tool {} in PATH. Place "
amaranth._toolchain.ToolNotFound: Could not find required tool yosys in PATH. Place it directly in PATH or specify path explicitly via the YOSYS environment variable

I actually do not have yosys installed. So probably this is expected.

I am open to contributing a PR, but if I am going to write docs I need to be sure I understand the behavior.

When you say "scales between the appropriate minimum and maximum", you mean it scales from the range -1…1 to the minimum and maximum values of the output sound file's type?

This description surprises me because in my failed test above I was giving values outside the range -1…1 and they were being snapped to 0 rather than scaled or clipped to the -1…1 range. Is there special case handling for values outside -1…1?

I am open to contributing a PR, but if I am going to write docs I need to be sure I understand the behavior. When you say "scales between the minimum and maximum", which minimum and maximum do you mean? Isn't the int type in python 3 unbounded?

That's very useful, thanks. Can you clarify— https://python-soundfile.readthedocs.io/en/0.11.0/#soundfile.SoundFile.buffer_write What endianness properties should I expect buffer_read/buffer_write to have? Will it depend on format?

DONT forget to restart Unity after plug-ins updated.

I was struggling horribly with this, and this turned out to be what I was missing. I removed Visual Studio Code Editor, and added Visual Studio Editor*, and it was continuing to generate the project xml files with the bad <TargetFrameworkVersion>v4.7.1</TargetFrameworkVersion> xml no matter how many times I regenerated them. After reading this comment I exited and reopened Unity and did a regenerate and THIS time it generated with a good <TargetFrameworkVersion>.

This is very confusing and the error messages are pretty unhelpful! :(

* Also at this step, after installing Visual Studio Editor and based on a comment on a forum, I went into the Player settings and changed the API Compatibility Level from ".NET Framework" to ".NET Standard 2.1". I do not know if this step did anything at all, but if it did, it had no effect until I restarted Unity.

I don't know if this is a real problem. But I tried running pdm install to create a venv. This was not necessary (python -m venv also works). When I tried it it printed these errors:

C:\Users\Andi\work\f\other\the-cradle-colorlight-i9-ecp5-amaranth-hdl>python.exe -m pdm install
Lock file does not exist
Updating the lock file...
C:\Users\Andi\AppData\Roaming\Python\Python311\site-packages\pdm\models\candidates.py:584: ExtrasWarning: Extras not found for
setuptools-scm: [toml]
  return filter_requirements_with_extras(
🔒 Lock failed
Unable to find a resolution for amaranth
because of the following conflicts:
  amaranth @ git+https://github.com/amaranth-lang/amaranth@f135226a79fddf5caf894030ac7f49995774c3a7 (from
amaranth-stuff-by-sporniket@git+https://github.com/sporniket/amaranth-stuff@22130d399e82e146aa5a7d4708ec26b002979bab)
  amaranth<0.5,>=0.3 (from
amaranth-boards@git+https://github.com/amaranth-lang/amaranth-boards@91ffa38e788a691464a6873d44537eece72ef76e)
To fix this, you could loosen the dependency version constraints in pyproject.toml. See
https://pdm.fming.dev/latest/usage/dependency/#solve-the-locking-failure for more details.
See C:\Users\Andi\AppData\Local\Temp\pdm-lock-p6kykd8o.log for detailed debug log.
[ResolutionImpossible]: Unable to find a resolution
Add '-v' to see the detailed traceback

Despite the error, the created venv worked fine. Since your build instructions do not suggest use of pdm I don't know if this is even a problem. Do you think this is a problem…?

@sporniket , thank you, I tried checking out this branch and got the same error.

I then did a second build. On the second try I did a git clean -xffd first, and to create my virtualenv I did python -m venv .venv instead of pdm install. This also got the same error. Here is more context, after this quote it is same as screenshot above.

(.venv) C:\Users\Andi\work\f\other\the-cradle-colorlight-i9-ecp5-amaranth-hdl>python -m pip install --force-reinstall dist\the_cradle_colorlight_i9_ecp5_amaranth_hdl_by_sporniket-0.0.0-py3-none-any.whl
Processing c:\users\andi\work\f\other\the-cradle-colorlight-i9-ecp5-amaranth-hdl\dist\the_cradle_colorlight_i9_ecp5_amaranth_hdl_by_sporniket-0.0.0-py3-none-any.whl
Collecting amaranth-stuff-by-sporniket@ git+https://github.com/sporniket/amaranth-stuff@22130d399e82e146aa5a7d4708ec26b002979bab (from the-cradle-colorlight-i9-ecp5-amaranth-hdl-by-sporniket==0.0.0)
  Cloning https://github.com/sporniket/amaranth-stuff (to revision 22130d399e82e146aa5a7d4708ec26b002979bab) to c:\users\andi\appdata\local\temp\pip-install-p_s44c66\amaranth-stuff-by-sporniket_bfe85ea8525443f3917d4b8a0c8bc9c0
  Running command git clone --filter=blob:none --quiet https://github.com/sporniket/amaranth-stuff 'C:\Users\Andi\AppData\Local\Temp\pip-install-p_s44c66\amaranth-stuff-by-sporniket_bfe85ea8525443f3917d4b8a0c8bc9c0'
  Running command git rev-parse -q --verify 'sha^22130d399e82e146aa5a7d4708ec26b002979bab'
  Running command git fetch -q https://github.com/sporniket/amaranth-stuff 22130d399e82e146aa5a7d4708ec26b002979bab
  Resolved https://github.com/sporniket/amaranth-stuff to commit 22130d399e82e146aa5a7d4708ec26b002979bab
  Installing build dependencies ... done
  Getting requirements to build wheel ... done
  Installing backend dependencies ... done
  Preparing metadata (pyproject.toml) ... done
Collecting importlib-metadata (from the-cradle-colorlight-i9-ecp5-amaranth-hdl-by-sporniket==0.0.0)
  Obtaining dependency information for importlib-metadata from https://files.pythonhosted.org/packages/cc/37/db7ba97e676af155f5fcb1a35466f446eadc9104e25b83366e8088c9c926/importlib_metadata-6.8.0-py3-none-any.whl.metadata
  Using cached importlib_metadata-6.8.0-py3-none-any.whl.metadata (5.1 kB)
Collecting amaranth@ git+https://github.com/amaranth-lang/amaranth@f135226a79fddf5caf894030ac7f49995774c3a7 (from amaranth-stuff-by-sporniket@ git+https://github.com/sporniket/amaranth-stuff@22130d399e82e146aa5a7d4708ec26b002979bab->the-cradle-colorlight-i9-ecp5-amaranth-hdl-by-sporniket==0.0.0)
  Cloning https://github.com/amaranth-lang/amaranth (to revision f135226a79fddf5caf894030ac7f49995774c3a7) to c:\users\andi\appdata\local\temp\pip-install-p_s44c66\amaranth_2fa5c45c69a1466bafff9b4ba65a7904
  Running command git clone --filter=blob:none --quiet https://github.com/amaranth-lang/amaranth 'C:\Users\Andi\AppData\Local\Temp\pip-install-p_s44c66\amaranth_2fa5c45c69a1466bafff9b4ba65a7904'
  Running command git rev-parse -q --verify 'sha^f135226a79fddf5caf894030ac7f49995774c3a7'
  Running command git fetch -q https://github.com/amaranth-lang/amaranth f135226a79fddf5caf894030ac7f49995774c3a7
  Running command git checkout -q f135226a79fddf5caf894030ac7f49995774c3a7
  Resolved https://github.com/amaranth-lang/amaranth to commit f135226a79fddf5caf894030ac7f49995774c3a7
  Installing build dependencies ... done
  Getting requirements to build wheel ... error
  error: subprocess-exited-with-error

  × Getting requirements to build wheel did not run successfully.
  │ exit code: 1
  ╰─> [19 lines of output]

Do you think it is a problem I am running in a venv?

Worked, thanks

Tonight I tried to build this project from Windows 10. The build scripts are Bash, so I ran the commands manually one by one. From a CMD.EXE prompt I ran:

python.exe -m pdm install
.venv\Scripts\activate.bat # I would prefer not to install anything globally
python -m ensurepip
python -m pip install --upgrade build pytest twine black coverage
.\venv\sc
python -m build
python -m pip install --force-reinstall dist\the_cradle_colorlight_i9_ecp5_amaranth_hdl_by_sporniket-0.0.0-py3-none-any.whl

This appeared to work (although the python -m build appeared to have installed a venv inside of the venv, which was a little dizzying) up to the whl step, where it failed with an error I do not understand:

Should I maybe move to a Linux box (or mac, if that would work? mac would be slightly more convenient because my Linux box is my Windows box…) and try again?

It would be great if the build could be driven and virtualized by pdm completely, as I believe that would be more likely to work cross platform, but maybe the build scripts are too complex for that, I don't know.

I agree that "meow root" is clearly "the folder where meow is located", but it is not at all obvious to me that "the folder where meow is located" is the git checkout of its source. My first minutes with vcpkg involved an install step through a "bootstrap" script, followed by a step using the actual name "install" step. Often, pieces of software which are distributed as software and have "install" steps such as this install to some other location (such as ~/.something or %APPDATA%), after which the distribution/source repo can be deleted. Although the "in-place" nature of the vcpkg repo/distribution is now clear to me, it was not inherently obvious at first.

Now that you know what vcpkg root is, how would you document it?

The getting started guide in the README begins with

First, download and bootstrap vcpkg itself; it can be installed anywhere, but generally we recommend using vcpkg as a submodule so the consuming repo can stay self-contained. Alternatively, vcpkg can be installed globally; we recommend somewhere like C:\src\vcpkg or C:\dev\vcpkg, since otherwise you may run into path issues for some port build systems.

… followed by sample invocations of git and .\vcpkg\bootstrap-vcpkg.bat. I would reword this as:

First, download and bootstrap vcpkg itself:

Sample code

The directory from which bootstrap-vcpkg was run is now a functioning vcpkg installation, and all packages downloaded will be installed within it. This directory can be installed anywhere, but generally we recommend using vcpkg as a submodule so the consuming repo can stay self-contained. Alternatively, vcpkg can be installed globally; we recommend somewhere like C:\src\vcpkg or C:\dev\vcpkg, since otherwise you may run into path issues for some port build systems.

Alternately, if the "root" language is important vocabulary to vcpkg (and not just an affectation of Cargo) the added sentence could refer to "a functioning vcpkg root" instead of "a functioning vcpkg installation.

Additionally, I would add a sentence to the getting started guide clarifying under what circumstances it is allowed to move the vcpkg root (for example: do things break if you move the directory after bootstrapping? if so, say so after you describe how to bootstrap. do things break if you move the directory after running integrate? if so, say so after you describe how to integrate).

The README for this project contains some build documentation.

To use rusb no extra setup is required as rusb will automatically download the source for libusb and build it.

In my testing, at least on Windows (Windows 10, Rust 1.69.0), this does not seem to be true. Rather, the default seems to be that it pulls libusb from vcpkg, and in order to make rusb download the source for libusb and build it the "vendored" feature must be specified in cargo. As far as vcpkg goes, the next line of the README does say:

However if building libusb fails you can also try setting up the native libusb library where it can be found by pkg-config or vcpkg.

Which is helpful, but it doesn't clearly explain the conditions under which this fallback is used/needed (anytime the "vendored" feature is not present)

"Expected behavior"

Assuming the behavior I'm seeing is intended, the docs should make it clear that "rusb will automatically download the source for libusb and build it" is a behavior exclusive to the "vendored" feature configuration and that "set… up the native libusb library where it can be found by pkg-config or vcpkg" is the default case.

I check out this repo, check out tag v0.9.3-rusb, and run cargo.exe build --features vendored. It fails with

error: failed to run custom build command for `libusb1-sys v0.6.4 (C:\Users\Andi\work\f\other\rusb\libusb1-sys)`

Caused by:
  process didn't exit successfully: `C:\Users\Andi\work\f\other\rusb\target\debug\build\libusb1-sys-a251194c1ecaa461\build-script-build` (exit code: 101)
  --- stdout
  cargo:rerun-if-env-changed=LIBUSB_STATIC
  cargo:vendored=1
  cargo:static=1

  --- stderr
  thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 3, kind: NotFound, message: "The system cannot find the path specified." }', libusb1-sys\build.rs:108:6
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

I don't know how to interpret this. Line 108 is this unwrap

fs::copy(
        libusb_source.join("libusb/libusb.h"),
        include_dir.join("libusb.h"),
    )
    .unwrap();

There are no other errors or warnings other than a spurious looking warning: functionget_macos_major_versionis never used.

I am on Windows 10 Build 19045. I have Cargo 1.69.0. I was hoping to build vendored because I was having a problem with the vcpkg build (see #182)

Wait, it is possible that my build steps here (building via a dependency of ecpdap) is forcing an out-of-date rusb. I will double check that the problem reproduces with current rusb.

Double checked with a direct checkout of rusb, most recent release tag (v0.9.3-rusb). Same results (IE same error)

Wait, it is possible that my build steps here (building via a dependency of ecpdap) is forcing an out-of-date rusb. I will double check that the problem reproduces with current rusb.

Hm if you open the documentation (https://learn.microsoft.com/en-us/vcpkg/) there is Integrate with a custom buildsystem (https://learn.microsoft.com/en-us/vcpkg/users/buildsystems/manual-integration).

Maybe the README.md should link to documentation after the "How to setup"

Hi, thanks for linking me this— this document is great and answers my remaining questions. Two notes, one, the "magic" .vcpkg_root file is not documented here, two, this document makes reference to the vcpkg root without explaining what the vcpkg root is. Maybe the "vcpkg root" does not need to be defined in the "custom buildsystem" document if it is defined more clearly elsewhere though.

I am trying to build on Windows 10 Build 19045 a Rust project named ecpdap which has rusb as a dependency. On initial build it failed because it could not find vcpkg. Okay, fair enough. I install vpkg via the instructions and then I run vcpkg install libusb¹.

I open a new cmd.exe window and cd to the ecpdap directory. I run set VCPKG_ROOT=/path/to/vkpkg/checkout and then cargo.exe build.

It prints:

error: failed to run custom build command for `libusb1-sys v0.4.4`

Caused by:
  process didn't exit successfully: `C:\Users\Andi\work\f\other\ecpdap\target\debug\build\libusb1-sys-d41f348fb0d0863b\build-script-build` (exit code: 101)
  --- stdout
  Can't find libusb pkg: LibNotFound("package libusb is not installed for vcpkg triplet x64-windows-static-md")

  --- stderr
  thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Custom { kind: NotFound, error: TarError { desc: "failed to create `C:\\Users\\Andi\\work\\f\\other\\ecpdap\\target\\debug\\build\\libusb1-sys-fd75480b6e25ea7c\\out\\source`", io: Custom { kind: NotFound, error: "The system cannot find the file specified. (os error 2) while canonicalizing C:\\Users\\Andi\\work\\f\\other\\ecpdap\\target\\debug\\build\\libusb1-sys-fd75480b6e25ea7c\\out\\source" } } }', C:\Users\Andi\.cargo\registry\src\github.com-1ecc6299db9ec823\libusb1-sys-0.4.4\build.rs:85:37
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...

I am going to try the "vendored" option for libusb next, but since I did everything by defaults, per the rusb instructions my "expected behavior" is this should work out of the box.

¹ It prints this. I notice the triplet is different from the one you are looking for but I don't know if this is meaningful. If you need me to install/build libusb with a specific vcpkg triplet you should probably document that.

C:\Users\Andi\work\g\other\vcpkg>vcpkg install libusb
warning: In the September 2023 release, the default triplet for vcpkg libraries changed from x86-windows to the detected host triplet (x64-windows). For the old behavior, add --triplet x86-windows . To suppress this message, add --triplet x64-windows .
Computing installation plan...
The following packages are already installed:
    libusb:x64-windows -> 1.0.26.11791#3
libusb:x64-windows is already installed
Total install time: 325 us
libusb provides CMake targets:

    find_package(libusb CONFIG REQUIRED)
    target_include_directories(main PRIVATE ${LIBUSB_INCLUDE_DIRS})
    target_link_libraries(main PRIVATE ${LIBUSB_LIBRARIES})

Thanks

Today I installed vcpkg. I followed the getting started instructions and then installed a single package (libusb). It installed many dependencies, then libusb. Great.

…where are the files?

I understand there is a cmake workflow for hooking up to vcpkg. But I wanted to know where the so-installed files were, for two reasons; one, I might want to delete them later, because some of the dependency packages installed (Python, CMake, Meson) sounded kind of large; two, I am not using cmake, I am using Rust "cargo", and Rust "cargo" depends on a environment variable named VCPKG_ROOT (this is its own problem, see here).

It turns out that the files are installed into the git checkout directory created in the getting started instructions. This git checkout directory also turns out to be the VCPKG_ROOT Rust wants (as identified by a file .vcpkg_root at the top level). I had to figure this out myself through detective work. It isn't described in the Windows quick start guide in the README, or the "Installing and Using Packages" guide the README recommends you read next. The quick start guide even makes reference to [path to vcpkg], but does not indicate what the path to vcpkg is (the git checkout). Writing this now I find the "Getting Started guide" linked on the separate website vcpkg.io has the sentence "The repo can be cloned anywhere, and will include the vcpkg binary after bootstrapping as well as any libraries that are installed from the command line" but I didn't see this at the time and I personally find this sentence slightly ambiguous.

I guess it was "obvious" to whoever wrote this documentation that the vcpkg-bootstrap and vcpkg install installs itself in-place into the directory vcpkg has been checked out into but it was not obvious to me :(

"Expected behavior"

I recommend explaining this (that the "install directory" is the same as the git checkout directory) more explicitly in the README and also taking note of the support thread linked above.

Surfacing a little higher in the documentation a link to the explanation of the layout of this magic directory (the significance of .vcpkg_root; which subdirectories are installed packages and which are vcpkg plumbing; whatever it is you do to "reset" the git repo to its uninstalled state, I guess git clean -xffd?) would probably be good but is probably not required.

Environment

Windows 10 , 10.0.19045 Build 19045 Rust/Cargo 1.69.0

There are a series of files attached to release v0.11.0. Unfortunately, there are no explanations or documentations of what these files are or how to use them (either in the "release" notes, the README.md, or the downloadable documentation¹). I am on a current Windows 10, and trying to use the files attached to the Github release, I encountered a few problems:

1. There are four files, and no indication of the difference between them.

   mingw-w64-clang-x86_64-openFPGALoader-ci-1-any.pkg.tar.zst
   mingw-w64-i686-openFPGALoader-ci-1-any.pkg.tar.zst
   mingw-w64-ucrt-x86_64-openFPGALoader-ci-1-any.pkg.tar.zst
   mingw-w64-x86_64-openFPGALoader-ci-1-any.pkg.tar.zst

   Other than the -i686, it's not clear to me the difference between the remaining three versions or under what circumstances I would pick one over the other.

2. The files are in zstd format, but you don't say that anywhere. I was able to figure this out pretty quickly with Google but it would have been helpful to say what software is required.

3. The programs do not seem to run. I downloaded ucrt as I assumed that is the Windows 10 version. Executing from a WSL command prompt or by double-clicking, these EXE files print several error messages saying that dlls such as "libusb-1.0.dll", "libftdi1.dll", and (some DLL with "gcc" and "seh" in the name) are not found.

My "expected behavior" is that if you put up compiled binaries for download, but there are special steps or other prerequisite software that need to be installed to use them (for example, does this software require msys2?²), you should document those. The release notes in the corresponding Github release would be the best place for that, but the README would also be good.

Partial overlap with issue #96.

¹ The documentation tarball contains an "install" page with fairly elaborate installation instructions for Linux and Mac. Unfortunately, the Windows section contains only the following text:

Aside from seemingly being only relevant to xilinx users, this could be clearer (not a complete sentence).

² I tried running the openfpga binary in an msys2-ucrt prompt, and it also just printed the "libusb-1.0.dll not found" error.

Steps to reproduce the problem

I am logged into mastodon.social. At this exact moment, if I open https://mastodon.social/@graydon@types.pl , I see this

Notice the reference to a "last boost".

If I go directly to graydon's feed on types.pl https://types.pl/@graydon , I see this:

Beneath the crawfordsm post, I see the microplastics post. There is a post missing from this feed, but only when I view from mastodon.social.

@crawfordsm@mastodon.social is on mastodon.social, so I assume that there is not a federation issue preventing me from seeing the post. I do not have crawfordsm blocked or muted. I have no filters which hide posts completly (only hide with warning) and none of my filters would apply to this post. It is possible crawfordsm has me blocked, but I assume not because I can see the original post on mastodon.social https://mastodon.social/@crawfordsm/110700335570308419 , I can see crawfordsm's profile, and the UI does not stop me from trying to @-mention Dr. Crawford.

Expected behaviour

I expect that boosts and regular statuses should be shown to me in chronological order if the account is on a peer server in good standing.

Actual behaviour

Post from my instance boosted on other instance missing from user feed

Detailed description

No response

Mastodon instance

mastodon.social

Mastodon version

v4.2.0+pr-27116-50e1f46

Browser name and version

Chrome 117.0.5938.92 (Official Build) (64-bit)

Operating system

Windows 10

Technical details

No response

Steps to reproduce the problem

I get a piece of spam. I want to report it. I click the … next to the spam and

Expected behaviour

All items in the menu are, one way or another, accessible.

Actual behaviour

The menu drops off the bottom of the screen and I cannot select "report"

Detailed description

It seems to do or not do this depending on where the … icon is scrolled to in the browser window. However the rule seems to be inconsistent, it's nothing so simple as "is the … in the top or bottom half of the window. For example, look at this other notification and how far down the screen I could scroll it and the menu still goes "down" instead of "up":

But then I scroll just a little further down and suddenly the menu points up:

There seems to be a slight "hysteresis" where whether I last scrolled the pane up or down slightly influences whether the menu goes up and down. Also this seems so absurd I hesitate to mention this, but the problem case (the inappropriate down menu) seems to happen more often with mentions/DMs than other types of notifications (favs, RTs).

I am seeing this on my laptop. My laptop has a pretty vertically narrow screen (and sometimes I make it worse by using it at a greater than 100% browser scale). I don't remember if I've ever encountered this on my Windows machine which has a taller screen.

Mastodon instance

mastodon.social

Mastodon version

4.2.0+pr-27116-50e1f46

Browser name and version

Chrome 116.0.5845.187 (Official Build) (x86_64)

Operating system

macOS 10.13

Technical details

I am using Advanced mode. I am running uBlock Origin but it claims it is not blocking anything on mastodon.social. I usually use Mastodon with userstyles, but I have turned them off for these tests and screenshots.