Thank you
I still don't see how installing an "incompatible" version of kicad can make the system unbootable or break your shell or DE, but I will let it pass given your great effort at constructive criticism -- even when you sound slightly offended.
Sorry, I did not mean to sound harsh, communication is hard when we don't have access to normal cues of social interaction.
Please see the link I sent, it explains exactly how you can end up with a broken system. Even though it might not be that likely in this case, it even has a link to an example user story in the next post.
Would you prefer
sudo pacman -Syu && sudo pacman -S kicad-niightly
over justsudo pacman -Syu kicad-nightly
?
Any of those would be fine.
Not anecdotal, but empirical experince. Yes, bugs were created on the archlinux bug tracker, but that does not mean there was no breakage.
Right, but wouldn't your experience be biased
Even though you might have seen more breakage in that form, I don't think your sample pool is very representative of overall userbase.
If people has a recently updated system, which I expect arch users to have
This is an unreasonable expectation IMO. Users won't simply at all points in time have an up-to-date system. I might have updated the system 30s ago but in the meanwhile new packages been released.
the risk is probably lower than for the prebuilt package to be too old because the user just did a -Syu in the 23rd hour before it is schedule to be re-triggered
I think you underestimate it
Even for ubuntu we are not suggesting people "upgrade" their system before installing the packages.
Because that is a supported use-case, it is designed to work. Installing kicad-nightly will force the correct dependencies to be updated as the versions are pinned, this is not the case on Arch Linux.
"forcing" users to update the system like that with pacman is way more likely to break other packages they have installed from AUR.
And doing this might render your system unbootable, break bash, systemd, pacman, and all kind of other awful failure modes.
See https://bbs.archlinux.org/viewtopic.php?pid=1811733#p1811733
You say you are not trying to teach users how to use their system, so these users that use packages from the AUR should be aware of the effects of a system upgrade, and should take the necessary steps to make sure your AUR packages are not left in a broken state.
That said, you should keep in mind not all users will be aware of the full impacts of the commands you present, and should try to minimize bad failure modes.
Doing a full system update via pacman will at worst left you with broken AUR packages, which already require you to be more of a power user to have installed. Doing a partial update will at worst make it so that your system does not boot the next day, has corrupt data, etc.
Please do not recommend possible system breaking instructions on your documentation.
This was even raised in the original PR, but you seem to completely ignore the feedback and go ahead with this change.
This is completely unsupported. If you update the repos, you must do a system upgrade, otherwise your system might break. Partial updates are not supported in Arch Linux.
https://wiki.archlinux.org/title/System_maintenance#Partial_upgrades_are_unsupported
Maybe it would make sense to add a footnote telling people they should avoid setup.py install
regardless of the problem on the blog anyway.
nitpick: I would recommend simply python -m build
(without the .
)
s/copying that/copying the source files/, otherwise it may seem it simply zips it, which is not true, wheels get their own metadata, setup.py install
produces eggs.
The issue and PR links are switched.
s/orchestrates the build environment/orchestrates the build environment and invokes the build backend/, no? Otherwise, it may seem it only prepares the environment, right?
I'd recommend "distributable artifact", or just "artifact", instead of "installable artifact", as sdists are not really installable, they will have to be turned into wheels first.
If we are putting different usage pages in the same item, this assumption is no longer correct.
Let's create a new inner loop that will get the feature page of the entry and call the dissection functions based on that. This means that we should remove the data loop from the dissection functions, and perhaps just replace it with an index.
hid-parser fails on the descriptor with
NotImplementedError: Unsupported global tag: 0b101
.
Yes, I haven't added the code for the exponent yet
Yes, it should.
They're not within a collection, we actually do not save any data related to collections as it is unecessary to parse. Collection data might be useful for a more high-level interpretation, like the OS deciding to have some custom handling for touch inputs to interact with the system, which it may want to be different than what it does with mice. Since we are only interested in interpreting the raw data, we do not need them. It would be interesting to add the collection details to the items, but that'd only be a small nice-to have IMO.
IIRC the groupings are per main item, so the assert should be fine. I don't have time to look at your capture right now, so I don't know what is going wrong there, sorry. Perhaps I will have some time later, if Tomasz needs a hand.
What we should probably do is remove the item groups in favor of actual data entries. This was the first HID parser I wrote, so I was not exactly sure how to structure it and this end up being a design oversight. I have a better structured parser at https://github.com/usb-tools/python-hid-parser, which does not have this design issues. The differences are that it is fully dynamic -- it dissects the data based on the usage type, instead of having custom per-page dissection routines -- and that it splits into actual data fields internally.
I think it is explicit about it not affecting the global state, as it would be a local item. At most, you could argue that it modifies the following entries for the current main item. But, among other things, the spec says "Extended usages can be used to override the currently defined Usage Page for individual usages.", emphasis on for individual usages.
The code overall looks good anyway
I think the main point of extended usages is exactly to support this. Do you have a device that uses them, or are you just adding this for completeness? Personally, I haven't ever seen extended usages used in the wild, and I would guess if I did, it would be to override the active usage page. The reason I left this out originally was for simplicity, as properly supporting extended usages would require a biggish amount of complexity added, I think.
Would it be possible to add footprints for the SAM S70/V70 families? I can try to give it a go when I have time. Are there any scripts or tools to help automate the process?