That is, I use C/Python for reading/writing BMP, PNG, TIFF, any other image format; instead of writing those functions in VHDL.
I use a tool like xxd to convert a binary file to ASCII, and then use hread() to read it in VHDL.
As a matter of fact, I wanted to gather multiple examples about dealing with files (text, binary, CSV, hexdumps, etc.) in VHDL >=2008. However, I don't know where to put that content. I feel it doesn't fit in the GHDL docs, nor in the ghdl-cosim docs, or in OSVB... And currently I cannot handle maintaining yet another repo...
I really hope the fpga-toolchain is kept until the oss-cad-suite is improved. Currently, they are reinventing appimage/flatpak manually...
There is 1GB of Ubuntu system libs included in the tarball, and all the executables are wrapped in bash/perl scripts for overriding the linker and library paths.
Oh my god. Sounds like the Xilinx method.
Well, someone will go and dockerize it, eventually.
Most of the tools are dockerised already... So, fpga-toolchain makes sense because it's a different (all static) solution. In oss-cad-suite, they are partially duplicating the MINGW packages and they are partially duplicating the hdl/containers. See YosysHQ/oss-cad-suite-build#1.
Nonetheless, if they want to provide "their own solution for their clients" it makes sense for them to have a branded bundle.
I was about to ask something in the gitter channel of another open source community and I saw they moved to https://zulip.com a week ago.
I didn't know about that software/service.
It looks really nice. It's open source. The default free plan is limited to 10k messages of search history and 5GB of storage. However, they provide the standard plan for open source projects: https://zulip.com/for/open-source/.
Moreover, open source projects can open invitations, so that anyone can join without one.
We have previously discussed how awful the threading solution in gitter is, and how barely usable it is on smartphones.
I believe the main reason for staying here is the very nice integration with github/gitlab for cross-references.
Zulip seems to have a nice integration too, and users can also login using github/gitlab accounts.
The main drawback I see is that zulip communities seem not to be public. So, users can join freely if we enable it, but they do need to join in order to read the content. I really like that gitter allows users to reads without requiring them to register and login.
No strong opinion. I prefer an open-source solution, but moving has also a cost.
It could also be that all gitter chatrooms are automatically converted into matrix rooms in the future, in which case no change would be necessary
We use an zulip with an internal instance at work. It’s okay, you can have a lot of streams, it supports threads, private communication etc. What I don’t like are their electron based „native“ apps. I use it only in the browser instead.
@nobodywasishere:eowyn.net matrix being a decentralized/federated solution, it can be used regardless of the preferred centralized entrypoint. I don't see the point of making matrix the main entrypoint, because it is an aggregator from a conceptual point of view. Am I misunderstanding it?
@nobodywasishere:eowyn.net I mean there is no "matrix client". Matrix is a thing. Clients are a different thing. Therefore, zulip cannot be compared to matrix. zulip/gitter need to be compared to some client of matrix. From the user interaction point of view, having matrix below is not relevant.