Something to note here is that everything is known and done statically in the source code. This could be addressed through metaprogramming if only the Go language had some ^^
We have similar needs at Sqreen but for security monitoring and protection reasons: we need to dynamically instrument functions at run time, while not asking any code modification to our users. To do so, we instead leverage the Go compiler to perform compile-time instrumentation that inserts hooks anywhere interesting. You can read more about this approach at https://blog.sqreen.com/dynamic-instrumentation-go/
We haven't modified the compiler but instead plugged into it an external instrumentation tool using the compiler option `-toolexec`.
With this option, the compiler invokes every toolchain binary (compile, asm, link, etc.) through the provided program. So you can basically write a proxy program intercepting calls to `compile` to do source-code instrumentation, exactly like you would with go generate, but now automatically done during compilation on every package.
But, but... you get to run Facebook binaries on your desktop computer! Comes with a full access to everything, so it must be very exciting for at least one party involved.
I previously created my own "native" app from this by wrapping https://web.whatsapp.com in an Electron wrapper so that I could have WhatsApp live separate from the browser, with it's own Dock icon.
Some ways in which the official app is better:
* The official app extends to the edges of the window, whereas the web app has a "window on a background" design, which takes up more space.
* The official app has keyboard shortcuts.
* The official app has better notifications.
A couple weeks ago. One thing it does better than the official app is that on Mac the red window button hides the window rather than terminating the process.
Can I make a suggestion? It looks like this is aimed at open-source users and it might be a better fit over on GitLab (https://gitlab.com/).
It's a great idea to create this repository of information, but putting it in GitHib's proprietary silo is a turnoff to some potential contributors. It isn't wrong to use GitHub, it's just better to make GitLab the default choice for FOSS (and especially crowd-sourced!) projects.
Either way good luck with it, I like the idea and as I'm already running Ubuntu I may try the PPA and see if I can generate some useful data to contribute.
> it's just better to make GitLab the default choice for FOSS (and especially crowd-sourced!) projects
Care to expand? I think many would disagree and even counter that putting things on GitLab is a turnoff to some potential contributors (it would be to me). Nothing against GitLab, but I think it's tough to make an argument for any single platform being the "default."
GitHub does have that popularity and mind-share going for it, so I can see why people might not care to leave and create a new account at GitLab. The primary concern is the license which could be identical at either platform so that's a non-issue.
The primary difference is that GitLab (referring to CE, the 'Community Edition') is completely portable and self-hostable. That means if things change later or the platform host gets a legal challenge or takedown request, you are free to say 'go pound sand' and take your data and platform elsewhere. You are not at the mercy of the platform provider.
For a classic example of a community effort where the rules were changed after a great many users altruistically gave of their time and effort see CDDB, also known as Gracenote[0]. And as I typed my original comment, this thread[1] was on the HN front page with some choice comments illustrating the difficulty of doing a 100% clean export of your data from GitHub.
Google has a great initiative, humorously called the 'Data Liberation Front'[2] which makes sure users can easily export all their data in a useful format if they want to take it elsewhere. I used it when I closed my Google accounts and I can report it works perfectly. I see no comparable effort by GitHub. Users like me check for this early and it's absence is always a red flag.
Hope that answers your question and if my assumption that you don't want to use GitLab because of the friction of creating yet another online account is incorrect please clarify what your real reason is.
Over the last few years, I wrote a GNU Make library to make people able to write Makefiles in a very declarative way to help everyone in my company, me included, with this serious problem. I tried to make it as simple as possible using simple widespread concepts like UML components where you simply say a component has interfaces you can require and implementations you can link against. It is used to build our Operating System, our applications and even our reactjs web application.
It solved every problem I noticed about writing bare Makefiles: dependency tracking and generation is automated; the Makefile can be split into multiple sub-makefiles in your source-tree so that it matches your UML (these one http://agilemodeling.com/images/models/componentDiagramUML1.... you can perform out-of-source builds; generating complex software with deep dependency trees made simple (you inherit from other components' dependencies), etc.
cmake does not really offer the declarative interface I want (i.e. descriptions of components). It is still "low-level" and I would have to write cmake macros too. So I preferred native gnu make. Adding another tool on top of Make adds another layer of complexity, no matter how simple it is.
To me, the big benefit of cmake is its portability because it is able to generate visual studio files, eclipse files, etc.
Another one is that you end up with a static Makefile while my solution is dynamic: the makefile is evaluated at every execution (unless gnu make caches its parsed files but I don't think it does so far). It could be a problem for big projects like linux which would require a certain amount of parsing time of the Makefiles before evaluating them - while cmake or autotools, you go through this only once.
I just embedded it on a PowerPC P2020DS processor as a baremetal program (using the newlib and by stubbing the syscalls) and it works, I get a baremetal javascript interpreter ;)
;){kind=link}
We have similar needs at Sqreen but for security monitoring and protection reasons: we need to dynamically instrument functions at run time, while not asking any code modification to our users. To do so, we instead leverage the Go compiler to perform compile-time instrumentation that inserts hooks anywhere interesting. You can read more about this approach at https://blog.sqreen.com/dynamic-instrumentation-go/