However it looks like I can't find my way out of a wet paper bag with git; no big surprise with me..
It won't let me modify my author.txt file:
Also tried git pull, git push ..etc to no effect. Hopefully that will be resolved soon.# git diff diff --git a/author.txt b/author.txt index 51ef602..b4be640 100644 --- a/author.txt +++ b/author.txt @@ -1 +1,3 @@ I write radio automation software for a living. Very interested in Genode, and now trying to port CommandCenter (and companion apps) to Genode. + +*Company* [https://www.tunetrackersystems.com - TuneTracker Systems LLC] # git commit On branch master Your branch is up to date with 'origin/master'. Changes not staged for commit: modified: author.txt no changes added to commit
Anyway if all goes well, Fossil will get a "git" compatibility back-end in a few months, and I'll be able to pilot git repos from the comfort of Fossil. Fingers crossed.
Anyway, this past week's emails fostered more reflexion:
Later on we'll focus more on the 'chain' which leads to the sink: we'll need the ability to insert some audio "nodes" that intercept audio traffic and modify it (for various audio effects) before it reaches the mixer/sink. But that's farther down the road.
If some reflexion about audio latency is in order though, maybe the Be newsletter archive (see below) could help... I'm not overly familiar with the depths of the Media Kit (kind of a paradox for someone writing audio broadcasting apps); but I remember e.g. that each BMediaNode has accessors to report its internal Latency(), one's downstream latency, and so on. That way, when building an audio processing chain you can make informed decisions.
It was commonly agreed that the Be (and Haiku) Media Kit was the least mature of the kits though. Hard to get into, hard to code for and get right even when experienced. Genode would do well to tread carefully there.
Just now I see that libav and avplay are being moved from libports to "world"; will look into doing a git clone and follow the readme soon.
If memory serves, it had a recurrent structure:
Given how time consuming writing a newsletter is though, it might make sense to have those written not by the 'core' Genode team but by a third party who is very familiar with Genode.
(bonus link: http://bedope.com/)
A few years ago I found out that
grep -R SomeSymbolNameEtcHere .
is blazingly fast compared to other solutions, because there is no fork()ing involved: there is exactly one instance of /bin/grep running, at full speed, from the beginning to the end of the search.
In fact, when running it for the second time around and the disk data is cached in the OS "file cache", it returns results very very fast, even on a quite big tree like Genode.
There is something complementary, that the Genode team should look into though: talk to someone who hosts a cross-reference indexer, so that they index the Genode source, and keep the indexing current.
For example, Haiku is indexed (together with FreeBSD, Fuschia..) over here: http://xref.plausible.coop/source
The ability to click any symbol and go to its definition (or go to references to it) is invaluable, for experienced devs doing hardcore work and for newbie explorers alike. More convenient than even a recursive grep.
Maybe the indexer can even be hosted on the genode.org server itself, no idea.
On all four of these, the laptop's touchpad and keyboard work. All four of those work with the "make run/demo KERNEL=nova" scenario; two also support the newer Sculpt scenario, including wired networking. Not much success with acpica.
It just says there was a NULL indirection, at instruction-pointer such and such. Wonder if one can guess which function/method is involved, from that info or some other hints? I have so much left to read about Genode, maybe there is a way to get more info and I just didn't run into it yet.[init -> hello_client] BWindow Ctor for: Zwei no RM attachment (READ pf_addr=0x0 pf_ip=0x1000ab7 from pager_object: pd='init -> hello_client' thread='ep')
UPDATE: d'oh. Now I remember, when building the GCC 6.3 toolchain last month, I commented out building of GDB. When I get around to re-building the tool chain (doing a "clean" build) I'll make sure to include GDB this time -- that must be what is invoked for userland crashes, and reporting to the genode log..
Anyway I'm adding massive Genode::log() tracing to my code, helps a lot.
libports/src/apps/acpica/READMEhas some detailed info which might help me; will look into why I get warnings/errors loading acpica in Sculpt. Maybe adding acpica to my own scenarios and tweaking the configuration will do the trick.
https://www.haiku-os.org/guides/daily-tasks/access_bfs_with_fuseThat page makes it sound like it is not rocket science to compile and use FUSE/BFS on another OS (including Genode's noux ?).
Also noticed this post from @ehmry:
As for my personal roadmap, in the past few weeks I've begun work on a distributed non-hierarchal storage layer. The intention is to support a subset of the de facto file-system semantics with quick composition using the formalism of set logic. This is a pivot of my roadmap from a year ago and reuses code and ideas from another storage project of mine, so progress is swift. The use-case is distributed and redundant storage for things like my permanent music collection as well as the package depot.Even if I'm somewhat successful with FUSE ..etc, I'll still follow the above project for a 'native' Genode FS: it has potential to be most robust, better integrated. If in addition to that it also sports attributes (or allows extending with plugins ..etc to support them) I'll be a most enthusiastic supporter!
The 'non-hierarchal' bit somewhat reminds me of Be Inc's quest for a file system, that initially led them to a database-like (instead of conventional) file system. I was not yet in the Be community at that time but followed it on the web, I think it was around BeOS AAPR or DR1/DR2 era. Fun times.
os/src/test/nitpicker/main.ccis all I needed to get started. The coding style and paradigm are unfamiliar of course, but I'm having fun discovering, creating boot images with my experiments and so on. Still can't get over how the image.elf file is a couple MB big, and boots almost in the blink of an eye.
Curiously, I get this warning in qemu; sounds a bit ominous and won't go away even if I increase platform_drv caps from 800 to 1800:
[init -> platform_drv] Warning: Out_of_caps during Device_component constructionSeems to be without any (visible) consequence though. Anyway, next thing I know, I'm going to ask for a "screenshot" feature so that I can capture interim states of my progress, for posterity *g*.
Should we prioritize documenting the use of Sculpt or the use of Genode? The former would look only at the building blocks (but not inside them). Such documentation can be in the form of light-hearted and practical use-case anecdotes, which are fun to read and immediately applicable by Sculpt users without any programming.Speaking as a newcomer, and wanting to attract more newcomers, I'd recommend spending (slightly) more time on the former, documenting what the building blocks can do. From the simple to the elaborate.
As to documenting how those use cases are implemented: obviously we want the Genode developer community to thrive and help them do their programming job; but 1) developers must know something exists, before wishing to use it or build upon it -- Sculpt scenarios documentation is a good way to do that. And 2) even when it comes to getting up to speed coding things, I find myself
grep'ping dozens of times per day... And learning a lot that way. Developers can in many cases find their way even if the documentation lags behind.
Your mileage may vary, but that's it for me as of today.
That state of mind evolved going into December though. Already in Q32018, kernel-land problems were overwhelming. Then they became unbearable, and finally we went into full brainstorm mode. It now looks like we might be able to benefit from micro-kernel stability, while not burning our bridges: if we can pull off making a solid Haiku compatibility layer on Genode, then Haiku applications can be written targetting either Haiku proper or Genode, with little adaptation work needed to support both. In theory. Anyway that's what we are hoping for.
If all goes well this year will see the realization of that, and 2019 will see Command Center and hopefully more TTS apps (and maybe even other, non-TTS apps?) running like a champ on both target platforms.
Early work has started: on one end, I'm stubbing out some classes in
app, support, storage, interface kits and so on. On the other end, I'm examining and tweaking Genode 'gem' GUI code. Will slowly get both ends closer to each other until I obtain a nascent haiku.lib.so.