Comments (3)
Hmm, I'm not so sure about this.
I don't think the gain justifies the additional effort required in development and maintenance.
Even if I were to ignore the development work this would require, the additional maintenance work required for this would be:
- Building and maintaining separate packages for every release
- Performing the same testing on multiple binaries
- Managing multiple binaries with a different set of shared object dependencies - this is a form of hell that I'm not willing to suffer any more than once.
- Ensuring that all new code is decoupled from the Insight component - although I already aim to keep each component within Bloom loosely coupled, there are instances where coupling can save me a lot of time, at least as a temporary solution, even if it's not the best approach from a software-design perspective.
Those are just the points from the top of my mind. There are probably others.
Furthermore, I feel like this would be taking Bloom in a direction that I never intended. Bloom was designed to run on development machines - machines that embedded developers would use for development - machines that can handle a 3.2 MB binary. It wasn't designed to run on resource-constrained machines.
I know that Insight causes Bloom to use around 30-40 MB of RAM, instead of the 4-6 MB when Insight is disabled. The way I see it is: If you can run a modern bulky web browser (like Google Chrome's 190 MB binary), or an IDE like CLion on your machine, you should have no problem running Bloom. If your machine can't handle running modern IDEs or web browsers, then Bloom wasn't intended to run on it.
I may change my mind on this at a later date, but for now, I don't want to worry about binary size as I feel a 3.2 MB binary should not be a problem for any of the intended users. Apologies if this is going to be a problem for you.
What architectures/distributions are you looking to run Bloom on? If these are not significantly resource-constrained and used as development machines, by embedded developers, I will consider supporting them (but only once there is clear evidence of demand).
from bloom.
Even if I were to ignore the development work this would require, the additional maintenance work required for this would be:
- Building and maintaining separate packages for every release
- Performing the same testing on multiple binaries
- Managing multiple binaries with a different set of shared object dependencies - this is a form of hell that I'm not willing to suffer any more than once.
- Ensuring that all new code is decoupled from the Insight component - although I already aim to keep each component within Bloom loosely coupled, there are instances where coupling can save me a lot of time, at least as a temporary solution, even if it's not the best approach from a software-design perspective.
Those are just the points from the top of my mind. There are probably others.
I have not yet taken a look at the code so I am not sure how strongly some of the stuff is currently linked but given that it can be disabled there do not seem to be codepaths which require it leaving only some potential compiler/linker troubles.
That being said I do not expect you to be distributing multiple package versions. Just like many stuff in other projects can be disabled (apache, curl, linux kernel) it is so only for some specific use cases and the published packages always contain all the features.
Furthermore, I feel like this would be taking Bloom in a direction that I never intended. Bloom was designed to run on development machines - machines that embedded developers would use for development - machines that can handle a 3.2 MB binary. It wasn't designed to run on resource-constrained machines.
[...]
What architectures/distributions are you looking to run Bloom on? If these are not significantly resource-constrained and used as development machines, by embedded developers, I will consider supporting them (but only once there is clear evidence of demand).
We intent to run Bloom on some Raspberry Pis (i.e. arm64) such that students are able to access our development boards remotely to implement their assignments as well as on the computers inside the lab. As the RPis are headless devices they do not have any of the GUI libraries installed. Checking on a headless x86_64 machine of mine showed that apt install ./Bloom-0.9.1-Linux.deb
would pull in about 400MB of dependencies...
from bloom.
I have not yet taken a look at the code so I am not sure how strongly some of the stuff is currently linked but given that it can be disabled there do not seem to be codepaths which require it leaving only some potential compiler/linker troubles.
It's not tightly coupled, but that doesn't mean it won't be a lot of work and pain to completely strip out the Insight component when a feature flag has been set. And that's not just in the initial development work, but also in the maintenance. I'll still have to test multiple binaries, constrain any new changes in other components from touching the Insight component, handle support requests for different build configurations, and manage optional shared object dependencies which will lead to pain further down the line - pain that I will have to deal with. And the idea of polluting my codebase with #ifdef
s doesn't sit well with me either.
We intent to run Bloom on some Raspberry Pis (i.e. arm64) such that students are able to access our development boards remotely to implement their assignments as well as on the computers inside the lab. As the RPis are headless devices they do not have any of the GUI libraries installed.
I see. I'm afraid Bloom was not designed to accommodate this use case, and more importantly, it's not something I'd be able to accommodate with respect to the development and maintenance required. I'm sorry @septatrix, but I'm going to have to reject this.
What I fear most is Bloom becoming a chore. When development and maintenance becomes too painful, Bloom will become a chore. And at that point, it won't be long before I begin to lose interest. I hope you understand.
As an alternative, you could always fork the repo and maintain your own headless version of Bloom.
from bloom.
Related Issues (20)
- Provide JSON list of supported targets via CLI command HOT 2
- Support new AVR DU-series targets
- Support AVR EA/B-series targets
- bloom Website Down? HOT 5
- RSP kill command 'k' is silently ignored HOT 14
- Raspberry Pi OS Version HOT 30
- Wrong target signature (ATtiny416) HOT 3
- variantName doesn't appear to work on atmega328p-pu HOT 1
- Issues when stepping into a static library HOT 7
- Insight shows no TCA0 registers for the AVR128DA32 HOT 2
- Bit field annotations in register inspection window
- Distro packaging: Search resources in /usr/share/bloom? HOT 4
- Support for hardware breakpoints HOT 1
- Breakpoints being lost after programming session in GDB HOT 1
- Move away from using RUNPATH to specify shared library paths HOT 1
- Can't find Atmel-ICE Debugger when attached to USB hub HOT 1
- Delta programming (restrict uploads to changes only) HOT 2
- RISC-V HOT 3
- Add support for UPDI over /dev/ttyUSBx and similar interfaces HOT 4
- Keep target halted after activation
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from bloom.