Forking deviationTx

More
20 Apr 2016 07:20 #46846 by mwm
Replied by mwm on topic Forking deviationTx

Richard96816 wrote: It's all such a tower of babble. I have things I'd like to try. But where do I find the information that tells me how to quickly set up the build environment? This is free software, but it doesn't quite act like it. I've built other packages from other projects and it was relatively quick and painless. Getting started with this one looks like it will take weeks.


It's hard to find, but then again, so is pretty much anything.

Click Links in the menu on the left. Click "Team repository". Read the contents of the README in the repository, which tells you how to set up a build environment. Which is the first place I look for that information on open source projects.

This is changing - we've got docker images now. But they aren't done yet, so not listed in the README.

Do not ask me questions via PM. Ask in the forums, where I'll answer if I can.

My remotely piloted vehicle ("drone") is a yacht.

Please Log in or Create an account to join the conversation.

More
20 Apr 2016 07:32 #46848 by FDR
Replied by FDR on topic Forking deviationTx
We are in the middle of significant changes, which might not reflected in the documentation yet.

BTW I plan to remove the "Links" menu and move its items into the download pages and/or the main menu...

Please Log in or Create an account to join the conversation.

More
20 Apr 2016 10:12 #46856 by Richard96816
Replied by Richard96816 on topic Forking deviationTx
HOW TO BUILD IT!

No one has yet suggested putting words to that effect on the home page. It's an absolutely primary enticement to participation, and you're all suggesting hiding it somewhere. It's your pride and joy, but it looks like you're somehow embarrassed to show it off.

:-(

Open software flourishes when others download, build and try their own ideas. Faceless software junkies getting hooked on your creation and stretching it in new and wondrous ways. But first impressions need to be as effortless as possible. Hook them before they have a chance to change their minds.

Please Log in or Create an account to join the conversation.

More
20 Apr 2016 10:26 #46857 by FDR
Replied by FDR on topic Forking deviationTx
It is on the main page of the source code: github.com/DeviationTX/deviation

BTW that is the content of the README file. Have you read it?
...if not, I will tell you how to build:
make

But without getting through that file in order to build up your developing environment it won't work anyway.
As I've already said things are changing, so that file needs upgrading too, but feel free to make a fork, correct the readme file, and send a pull request about that...

Please Log in or Create an account to join the conversation.

More
20 Apr 2016 12:40 #46865 by PhracturedBlue
Replied by PhracturedBlue on topic Forking deviationTx
Richard, I think others have addressed most of your points, but the question of 'why isn't it on the home page' is simple:
I don't think it belongs there. The home page is for users. It should give a description of what the project is and why you should be interested.

When 5.0 comes out, I'll rework the front page to have more prominent links to the Wiki, and as FDR mentioned, the side-bar will likely get a work-over as well (possibly with a 'Developers' link directly into to Wiki). mwm has certainly spurred on some significant change here, but it will take time to complete all that change.

Please Log in or Create an account to join the conversation.

More
23 Apr 2016 10:05 #47030 by TheSFReader
Replied by TheSFReader on topic Forking deviationTx
Hi, I tried and install a docker compilation chain on my (obsolete) PC, and will probably replace it in a few days. When it's replaced, I will try and test a few ideas about memory optimisations for the devo7e.

I saw in an other thread that for now the most memory constrained protocol was DSM2, right ? By looking at it I seem to have identified a few dozens of bytes to shave.
What other protocols are near/at the limit ?

Additionally, I may have an idea to shave some bytes in the ROM side too (related to "binary" configuration files, but keeping a tool-less one-way compatibility and other way tooled one).

However, I'm not sure it's worth the effort if the devo7e is "outscoped" post 5.0. So the big question is : if I were to manage to temporarily relieve the "memory" pression for a few months, will you all consider taking it along for the ride a few (sub)releases more ?

Please Log in or Create an account to join the conversation.

More
23 Apr 2016 10:55 #47035 by mwm
Replied by mwm on topic Forking deviationTx
PB had already done some work on binary config files. I've also thought about it. Nobody really wants to abandon the 7e, but the memory constraints are getting painful.

It seems like the real plan for the 7e is to use the docker images to make it easy to build versions with a different features set. We'll then pick a feature set (or several?) to build as part of the distribution/nightly.

My choices would be to turn off telemetry and multi-module support. I know there are 7e users who needed those things, but I think they are in the minority. Having to do your own build beats no support at all. Taking out telemetry will also help with protocol space issue. But this is all up in the air.

Do not ask me questions via PM. Ask in the forums, where I'll answer if I can.

My remotely piloted vehicle ("drone") is a yacht.

Please Log in or Create an account to join the conversation.

More
23 Apr 2016 13:03 - 23 Apr 2016 13:04 #47044 by PhracturedBlue
Replied by PhracturedBlue on topic Forking deviationTx
If you have ideas about binary model files, I'm all ears. The config stuff is one of the largest parts of the code base. My solution was to use emscrten to compile the ini reader/writer as code that could be run on the PC and to only store the actual 'struct Model' and its subordinates, which would mean there is no longer a parser on the 7e, but users could still work with ini files. More info here:
www.deviationtx.com/forum/7-development/...i-handler-gone#36337

But, I was never happy with that solution, and I'm certainly interested in others.

In the end the primary complaint on this subject is that the 7e and its siblings are stifling development due to the restrictions they place on developers. As soon as 5.0 is out, I plan to remove those restrictions by disabling 7e features. The smaller the code base, the more features the 7e can keep. And to cutoff any conversation in this direction, the set of features to remove has not been decided yet. We'll cross that bridge when we get there.

So I am certainly interested in any ideas you have to squeeze size out of the code. Just don't make it harder to maintain. If you compile the code, or download a 7e image, you'll find the .mod files. in the end these all need to be under 4k. The biggest are dsm2, dsmx, then devo and cx10 currently.
Last edit: 23 Apr 2016 13:04 by PhracturedBlue.

Please Log in or Create an account to join the conversation.

More
23 Apr 2016 13:42 #47047 by TheSFReader
Replied by TheSFReader on topic Forking deviationTx
Actually, my idea for config files is (in the memory limited targets) to replace in the config/*.c files the const strings by smaller memory hashes. Then, when loading a file, using a variant of the MATCH* which would test against the hash of the string if there is no direct match.
When reading a "non native" ini file all the tested value would fail the "direct test", but correspond with the hashed value.
When storing, the hashed key is used, and the ini file would not be directly readable. But at next read by the 7e, the direct comparison works.

And one could use a map of the strings and their hashes to convert back the "hashed" ini file to the more compatible and human readable one.

To implement that, one would only need to create a specific .h file, only included for memory limited Txs, where all the string constants to be replaced are "#Defined" as their hash, and create an alternative set of "MATCH" macros which implements the two-step test instead of a single string comparison.
If compatibility is foreseen as a problem, one could also add the "dictionary" (list of the strings and their hashes) to the distribution, so that the ini file can be reconstitued without the exact same version.

Clearly a hack, but that could gain some bytes to the expense of the hashing time when reading the file. If that can help wait for a more complete overhaul of the config, it seems like a win to me, with limited cost.

Please Log in or Create an account to join the conversation.

More
23 Apr 2016 19:27 #47072 by Richard96816
Replied by Richard96816 on topic Forking deviationTx
I still like the idea of using an Android phone or tablet instead of a PC. You could connect it to the transmitter with USB and store chunks or plug-ins or whole code modules and quickly change setups. And you'd have much more computing and storage in the field then even the bigger Devos. Then there would clearly be no limit to development going forward.

The trick would be to start simple. Then phone-side development could make wonderful things happen down the road. Voice and video and more inputs and lots more. The small form-factor of the 7e would be a real asset.

Please Log in or Create an account to join the conversation.

Time to create page: 0.039 seconds
Powered by Kunena Forum