diff --git a/doc/devel/rfc/LayerNames.txt b/doc/devel/rfc/LayerNames.txt index 013d7573c..5d36f9fa0 100644 --- a/doc/devel/rfc/LayerNames.txt +++ b/doc/devel/rfc/LayerNames.txt @@ -5,7 +5,7 @@ LayerNames [grid="all"] `------------`----------------------- -*State* _Idea_ +*State* _Final_ *Date* _Fr 05 Oct 2018 15:05:58 CET_ *Proposed by* Ichthyostega ------------------------------------- @@ -62,8 +62,8 @@ Tasks ~~~~~ // List what needs to be done to implement this Proposal: * find convincing new names ([green]#✔ done#) - * update and add documentation [yellow-background]#WIP# - * adjust source folders and namespaces [red yellow-background]#TBD# + * update and add documentation ([green]#✔ done#) + * adjust source folders and namespaces [yellow-background]#WIP# * adjust build system and library names [red yellow-background]#TBD# * fix textual usage in code and documentation [red yellow-background]#TBD# @@ -149,8 +149,60 @@ Comments -------- //comments: append below +.Mail Thread +[quote] +____ + + Subject: Re: Aw: Re: Session + Date: Sat, 15 Sep 2018 10:29:11 +0200 + From: Benny Lyons + To: Ichthyostega + + > On 14.09.2018 22:37, Ichthyostega wrote: + > Du bringst hier einen Punkt zur Sprache, der mir auch schon länger durch den + > Kopf geht, Benny. Eigentlich sind die Namen für unsere Layer etwas "daneben". + > Sie sind nicht wirklich gut. Zum einen klingen sie etwas dröge (vor allem + > "Proc"), und etwas, mit dem man so viel arbeitet, sollte doch auch inspirieren ;-) +... + > Ein anderer Ansatz, der mit auch immer mal wieder durch den Kopf geht, + > ist, ob wir nicht sogar metaphorische, oder symbolische Namen wählen sollten. + > Etwas, was man vielleicht auch nicht gleich versteht, was aber die Phantasie + > anregt. Meine Favoriten wären da (Du weißt, was für Filme ich mag....) + > + > - Stage + > - Steam + > - Vault + +Die finde ich sogar gut, sogar sehr gut. Warum nicht! +Wenn wir die Meinug sind, dass wir keine zutreffende Beschreibung in +einem Wort finden können! +``Stage'' wurde erfogreich in Git von ``Index Area'' umgenannt. 'Stage' und +'Vault' sind sehr gut, 'Steam' obwohl gut, erreicht nicht die Hohe von 'Stage' +und 'Vault', meiner Meingung nach. Können wir etwas finden die eine +Verbindung zwischen Stage und Vault herstellt, sowas wie Backstage +(wollen wir natürlich nicht), Make-up, Props, ... alles natürlich nicht +gut, aber Du weisst was ich meine. + +Aber Du sprichst eine sehr guten Punkt an. Mit ``Backend'' könnte jeder +etwas darunter vorstellen, aber ``Proc Layer'' war nicht besonders gut. +Hmm! ist aber wichtig, das können wir nicht nur hier machen. ABER übliche Namen, +die im alten Schneiderraum benutzt wurden, müssen +immer fanatisch eingesetzt werden. Alte Profis müssen sich sofort wohl +finden. +____ + + +.State -> Final +//add reason +This is not really a ``RfC'', to be honest. Rather I am pulling this off now. +I am working solitary on the coding, which has the benefit that I can settle +such global matters without much further ado... + +Ichthyostega:: '2018-11-15 19:38:32 +0100' ~~ + //endof_comments: '''' Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] + diff --git a/doc/devel/rfc/SchedulerRequirements.txt b/doc/devel/rfc/SchedulerRequirements.txt index 63047a693..239bd52d6 100644 --- a/doc/devel/rfc/SchedulerRequirements.txt +++ b/doc/devel/rfc/SchedulerRequirements.txt @@ -12,13 +12,13 @@ SchedulerRequirements ******************************************************************************** .Abstract +Define the expected core properties and requirements of the Scheduler service. +******************************************************************************** + The rendering and playback subsystem relies on a Scheduler component to invoke individual frame rendering and resource fetching jobs. This RfC summarises the general assumptions and requirements other parts of the application are relying on -******************************************************************************** - -Define core properties and requirements of the Scheduler service. Description ----------- diff --git a/doc/devel/rfc_pending/LayerNames.txt b/doc/devel/rfc_final/LayerNames.txt similarity index 100% rename from doc/devel/rfc_pending/LayerNames.txt rename to doc/devel/rfc_final/LayerNames.txt diff --git a/doc/technical/code/c++11.txt b/doc/technical/code/c++11.txt index dad754c0e..2dd3a70a8 100644 --- a/doc/technical/code/c++11.txt +++ b/doc/technical/code/c++11.txt @@ -284,7 +284,7 @@ notorious techniques for detecting a function work well on conventional lambdas, And it is not possible to ``probe'' a template with SFINAE: If you instantiate a template, and the result is not valid, you've produced a _compilation failure_, not a _substitution failure._ Which means, the compilation aborts, instead of just trying the next argument substitution (as you'd might expect). Another consequence is that you -can not _just accept a generic lambda as argument and put it into a `std::function` (which otherwise is the +can not _just accept a generic lambda as argument_ and put it into a `std::function` (which otherwise is the idiomatic way of ``just accepting anything function-like''). In order to place a generic lambda into a `std::function`, you must decide upon the concrete argument and return type(s) and thus instantiate the template at that point.