Hans Loeblich

Hi, I was looking through some of the files from the software DVD of my recently purchased HM310T, and I noticed some references to ClassID, which is always a two...

@tomtastic I don't know if you've seen my recent posts elsewhere (EEVblog thread and sigrok etommens PR), but I made some extensive changes to hm305.py, starting from your branch, and...

Thanks @NateTG, I appreciate the contribution, but could you submit this in the form of a github pull request? It makes it easier to code review and merge, and you'll...

I typically wouldn't close an issue until the relevant code is merged. Its nice to keep this space open for general discussion until then.

rounded cube needs to be commited to its own branch in order to keep it separate from your master (the default branch), it looks like no separate branch has been...

It took me years to get used to git / github workflow so I totally understand your confusion.

I think I do not have permissions to edit your PR, if you are willing to allow that then I could make some of the changes myself before merging: https://help.github.com/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork/

OK, my mistake then. Its not clear from my perspective in github interface whether you have enabled that, and I assumed it was unchecked by default. Thanks for confirming. I'll...

Overloading "." operator to disguise function calls as accessing member data is a very bad idea that will only lead to confusion and headache.

I was responding to the original post's suggestion: > My suggestion is to interpret "." as an operator such that v.name is implemented as name(v).