Fable: Nagareyama überwacht nicht mehrere fsproj- (und mehrere F#-Quellverzeichnisse) Projekte

Hallo @tomcl! Ja, es ist in Ordnung, Probleme mit Fable 3 hier zu melden und ich weiß es zu schätzen, dass du es tust 😊

Hmm, ich habe Fable 3 in mehreren Projekten mit Projektreferenzen getestet und alle Quelldateien (einschließlich Unterverzeichnisse) werden überwacht. Ich denke jedoch, dass die neueste Version einen Fehler hatte, den ich gerade behoben habe, bei dem, wenn die erste Kompilierung F#-Fehler enthielt, Änderungen keine Watch-Neukompilierung auslösten. Ist das Ihr Fall? Wenn nicht, passiert dies immer (der Beobachter reagiert auf keine Änderung)? Haben Sie mit anderen Projekten getestet? Gibt es etwas Besonderes in Ihrem Setup? Wäre es möglich, ein Repo zu erstellen, um das Problem zu reproduzieren?

Vielen Dank! Ok, mein Repo ist also sehr komplex, ich dachte, ich würde zuerst cmeerens fable-elmish-electron-material-ui-repo ausprobieren. Mein Code basiert lose darauf.

Das ist eine Elektron-Webpack-App. Darauf (einzelnes fsproj für Renderer und Main) funktioniert das Anschauen perfekt, ebenso wie Fable Watch -> Electron-Webpack-Entwicklungsbündelung. Ich denke. Außer dass:

  ERROR in ./src/Renderer/App.fs.js
  Module build failed (from ./node_modules/babel-loader/lib/index.js):
  SyntaxError: C:\github\fable-elmish-demo\src\Renderer\App.fs.js: Unexpected token, expected "," (202:4)

Die .fs.js-Ausgabe scheint von electron-webpack nicht gemocht zu werden

Dies ist definitiv ein anderer Fehler als der oben genannte. Ich möchte jedoch zuerst zu einer einfachen funktionierenden Demo übergehen, bevor ich zu meinem Projekt zurückkehre. Zu Ihrer Information - mein Projekt - im Gegensatz zu dieser einfachen Demo - wird vollständig kompiliert und ausgeführt

Repository ist https://github.com/tomcl/fable-elmish-demo/tree/dev-fable3 (beachten Sie den dev-fable3-Zweig im Link).

Bezüglich Ihres anderen möglichen Fehlers für den ursprünglichen Watch-Bug: Der Code hatte keine Fehler. Von meinen vorherigen Tests hat der Watcher nie etwas neu kompiliert. Ich vermute, dass es etwas Dummes ist, außer dass es viele System- und Tool-Ähnlichkeiten zwischen dem fable-elmish-demo-Build (der gut aussieht) und meinem Repo-Build (der nicht funktioniert) gibt.

Mein Repo "nicht gucken" ist https://github.com/tomcl/ISSIE wieder dev-fable3-Zweig. Aber ich garantiere nicht, dass dies sehr reibungslos zu bauen ist, das npm-Zeug muss aussortiert werden (es funktioniert, aber die Build-Datei verwendet npm, während ich denke, dass es für die Erstinstallation möglicherweise Garn benötigt). Ich werde das klären, wenn ich den Fehler nicht auf etwas Einfacheres replizieren kann, also solltest du es vielleicht noch nicht versuchen.

Die Fable-Kompilierungsausgabe von App.fs:

export const Theme_example = (() => {
    let color, color_1, styles_1, arg10, styles_2, props, props_1;
    const props_2 = ofArray([["palette.type", "dark"], (color = blueGrey, ["palette.primary", color]), (color_1 = purple, ["palette.secondary", color_1]), (styles_1 = ofArray([mkStyle("fontWeight", "bold"), (arg10 = singleton(mkStyle("backgroundColor", "#7FFFD4")), (mkStyle("\u0026$disabled", createObj(arg10))))]), ["overrides.MuiButtonBase.root", createObj(styles_1)]), (styles_2 = ofArray([mkStyle("borderWidth", 10), mkStyle("borderColor", "#000000"), mkStyle("borderStyle", "solid")]), ["overrides.MuiAvatar.img", createObj(styles_2)]), (props = singleton(mkAttr("size", "small")), ["props.MuiButton", createObj(props)]), (props_1 = singleton(mkAttr("fullScreen", true)), ["props.MuiDialog", createObj(props_1)])]);
    const merge = [];
    let theme;
    theme = (function setProperty(target, key, value) {
    const sepIdx = key.indexOf('.')
    if (sepIdx === -1) {
    target[key] = value
    } else {
    const topKey = key.substring(0, sepIdx)
    const nestedKey = key.substring(sepIdx + 1)
    if (target[topKey] === undefined) {
    target[topKey] = {}
    }
    setProperty(target[topKey], nestedKey, value)
    }
    }
    const target = {}
    for (let kv of props_2) {
    setProperty(target, kv[0], kv[1])
    }
    return target
    );
    return StyleImports_createMuiTheme_argsArray(theme, ...merge);
})();

Eindeutig nicht so, wie es sein sollte, kommt von:

module Theme =


  // Not used, but shows how to use style and prop overrides. The returned theme
  // can for example be used as the `theme` prop of `Mui.muiThemeProvider`.
  let example = Styles.createMuiTheme([
    theme.palette.type'.dark
    theme.palette.primary Colors.blueGrey
    theme.palette.secondary Colors.purple

    // Globally override component styles
    theme.overrides.muiButtonBase.root [
      style.fontWeight.bold
      style.inner "&$disabled" [
        style.backgroundColor.aquaMarine
      ]
    ]
    theme.overrides.muiAvatar.img [
      style.borderWidth 10
      style.borderColor.black
      style.borderStyle.solid
    ]

    // Globally override component props
    theme.props.muiButton [
      button.size.small
    ]
    theme.props.muiDialog [
      dialog.fullScreen true
    ]

  ])

Ich bin nicht wirklich besorgt über diesen Fehler: Er wird in keinem meiner Codes angezeigt, ich bin mir nicht sicher, ob er ein eigenes Problem hat.

OK, ich habe einen sauberen Build für mein Hauptrepo, der den Fehler "no watch" zeigt. Ansonsten kompiliert es gut und startet - es scheint ein zusätzlicher Fehler zu sein (vielleicht nicht fable3, aber anders als der vorherige fable2-Build). Ich werde das nach Möglichkeit klären, nachdem die Watch-Kompilierung funktioniert hat, da die Watch/HMR-Neukompilierung die Untersuchung viel schneller macht. Wenn der zusätzliche Fehler vorhanden ist, werde ich ihn als separates Problem kennzeichnen.

Bereinigen Sie das Build-Repo, das den Fehler "no watch" anzeigt:

https://github.com/tomcl/fable-elmish-demo/tree/dev-fable3

Hinweis muss dev-fable3 Zweig sein.

build (Windows) oder dotnet fake build installiert und erstellt Code. Es wird in den Watch/hmr-Modus wechseln, aber dies funktioniert nicht, da die fable3-Uhr nicht zuschaut.

npm run compile wird den Watch-Bug anzeigen, den Hauptprozess kompilieren (OK) und dann den Renderer-Prozess kompilieren/beobachten - der ok kompiliert, aber nicht aufpasst, z. B. ändern src/renderer/renderer.fs

npm run watchmain zeigt, dass es das (viel einfachere Struktur) Hauptprojekt korrekt überwacht.

PS - Ich freue mich sehr darauf, Fable3 zu verwenden. es wird einen viel schnelleren Entwicklungszyklus machen und auch, da die App viel Karten verwendet, kann die App möglicherweise beschleunigt werden. Ich hoffe, dass Nagareyama bis Mitte Januar nächsten Jahres einigermaßen stabil sein kann, da ich dann 60 Studenten im dritten Jahr haben werde, die alle an diesem Code arbeiten ...

Der falsche Code aus Ihrem vorherigen Kommentar sollte hiermit behoben werden: cmeeren/Feliz.MaterialUI#58. Können Sie bitte die neueste Version von _Feliz.MaterialUI ausprobieren?_ Beachten Sie, dass dies ein größeres Update ist, von 0.13.1 in Ihrem Repository auf 1.2.2.

Soweit ich das beurteilen kann, ist Ihr Build-Prozess (sowohl in https://github.com/tomcl/fable-elmish-demo/tree/dev-fable3 als auch in https://github.com/tomcl/issie/tree/ dev-fable3) ruft Fable einfach nicht auf, bevor Webpack ausgeführt wird. Mit Fable 3 haben wir keinen dedizierten Loader für Webpack mehr, daher muss der Fable-Compiler zuerst ausgeführt werden.

Ich rufe Fable 3 wie folgt in meinem Repository EDITED auf: https://github.com/tomcl/issie/tree/dev-fable3
"dev": "dotnet fable src/main && dotnet fable watch src/renderer --run electron-webpack dev" . Ich erwarte, dass dies den Hauptprozess kompiliert (es tut es) und dann den Renderer-Prozess kompilieren (ja, es tut) und beobachten (nein, ich denke nicht, dass dies ein Fehler ist).

Der Standardbuild ruft dieses Skript auf.

Ich habe mich in meinem obigen Kommentar geirrt und vorgeschlagen, dass npm run compile das nie sehen wird, weil es Fabel ohne Uhr aufruft.

Aber auf jeden Fall habe ich auch nur mit dotnet fable watch src/renderer getestet. Das ist der einfachste Weg, den _no watch_-Bug zu erkennen.

OK - ich habe femto auf dem cmeeren Repository ausgeführt und alle Abhängigkeiten aktualisiert, einschließlich material-ui. Es ändert nichts an dem Fehler, der syntaktisch falsches Javascript anzeigt, das von syntaktisch korrektem F# kommt. Es kann sein, dass da irgendwo ein paar schlechte Emissionsdefinitionen drin sind, denke ich, aber das ist für mich nicht offensichtlich.

Aber persönlich habe ich keine Bedenken bezüglich dieses Problems, es ist nicht mein Code und meine Codebasis wird alle in korrektes Javascript kompiliert. (Ich denke).

Hm, ich kann den Teilstring dotnet fable im Repository (tomcl/fable-elmish-demo) nicht finden. Aber dotnet fable watch src/Renderer/ --run electron-webpack dev funktioniert auch auf meinem Computer, bis es auf die ungültige Syntax in der generierten JS-Datei stößt.

Entschuldigung - ich habe den falschen Link gepostet! ich meinte
Mein Repository https://github.com/tomcl/issie/tree/dev-fable3

Das cmeeren Repo sieht gut aus. Also ignorieren Sie dieses Repo. Ich habe es nur hervorgehoben, weil es einen separaten Fehler zu geben schien, von dem jemand wissen möchte.

Ich habe jetzt mein Repo aussortiert (das die ganze letzte Nacht damit verbracht hat), einfach und einfach zu bauen, zeigt den Watch-Bug in einer Struktur mit 3 verknüpften Projekten und mehreren Quellverzeichnissen.

fable watch src/renderer

Fabel3 sagt "watching 'src'", beobachtet aber nicht die Unterverzeichnisse src/renderer usw.

OK - also ich denke jetzt verstehe ich das Uhrenproblem. Es ist nur ein Feature, kein Fehler, wie folgt.

Watch funktioniert für alle .fs Dateien im Projekt oder abhängige Projekte, vorausgesetzt, das _aktuelle Verzeichnis_ ist mit dem .fsproj Verzeichnis identisch.

Also für ein Projekt src/renderer/myproj.fsproj :

dotnet fable watch src/renderer wird kompilieren, aber nicht ansehen

dotnet fable watch . --cwd src/renderer wird kompilieren, aber nicht beobachten.

cd src/renderer

gefolgt von

fable watch . wird kompilieren und beobachten.

Dies ist ein wenig kontraintuitiv, aber in einfachen Fällen leicht zu umgehen.

In einem komplexen Fall wie meinem Repository, in dem das Dev-Skript das Hauptprojekt ausführen und überwachen muss, dann das Renderer-Projekt ausführen und beobachten und dann das Electron-Webpack ausführen muss, das selbst ausgeführt und überwacht wird, ist es schwieriger. Es wäre hilfreich, wenn das aktuelle Verzeichnis nicht mit der Datei fsproj identisch sein muss.

Dieser Satz von Skripten funktioniert für meine Elektron-App. und die typische Kompilierungs- und Ladezeit beträgt 1/10 wie zuvor: Die vorherige Lösung würde alle Dateien neu kompilieren.

    "dev": "cd src/main && dotnet fable watch . --run npm run devr",
    "devr": "cd src/renderer && dotnet fable watch . --run npm run webpack",
    "webpack": "electron-webpack dev",

Vielen Dank für die Untersuchung und für das Repo-Beispiel @tomcl @inosik! Ich freue mich sehr zu hören, dass die typische Kompilierung 10x schneller ist als zuvor :tada:

Es sollte möglich sein, Unterverzeichnisse zu beobachten, auch wenn Sie sich nicht im selben Verzeichnis wie das Projekt befinden. Normalerweise führe ich dotnet fable vom Repo-Root aus und der Watcher funktioniert einwandfrei. Wenn Sie interessiert sind, wird der Watcher so gestartet:

• Starten Sie ein FileSystemWatcher mit Filter .fs(x|proj), das Unterverzeichnisse enthält
• Nachdem die Fable-Kompilierung abgeschlossen ist, wählen Sie das gemeinsame Basisverzeichnis für alle Quelldateien aus, legen Sie es als Pfad des Watchers fest und aktivieren Sie auslösende Ereignisse.
• Wenn ein Ereignis ausgelöst wird, überprüfen Sie, ob die Datei zum Projekt gehört

https://github.com/fable-compiler/Fable/blob/41ccfc253c890292b2514402089c594eabf485cf/src/Fable.Cli/Main.fs#L206 -L241

Ich habe den dev-fable3 Zweig getestet, den Sie freundlicherweise im Issie-Repo vorbereitet haben. Bei mir hat es funktioniert, aber ich musste den Befehl anpassen. Vielleicht hat Fable Watcher funktioniert, aber es hat keine Webpack-Kompilierung ausgelöst, weil --watch beim Aufrufen von Webpack fehlte. Der folgende Befehl hat für mich aus dem Repo-Root funktioniert:

dotnet fable watch src/Renderer --run webpack --config webpack.additions.renderer.js --watch

Jedes Mal, wenn ich Renderer.fs geändert habe, wurde ein neues Bundle erstellt. Das Bundle schlug jedoch fehl, weil in webpack.config.js Sass und Dateilader sowie das Ziel electron-renderer fehlten.

@tomcl Könnten Sie bitte versuchen, ob dieser Befehl ☝️ für Sie funktioniert? Übrigens, Issie sieht toll aus! Ich habe es heruntergeladen und ein bisschen damit gespielt. Aber ich habe nur ein leeres Projekt, daher ist es nicht sehr aufregend, es zu teilen. Haben Sie ein komplizierteres Projekt oder ein paar Screenshots, Gifs, um darüber zu twittern?

Vielen Dank! Die Sache ist Electron-Webpack ist ein Modul, das all das macht (Webpack + Setup + Zuschauen). web-config.js wird also automatisch generiert und normalerweise nicht verwendet, und die "Additions"-Dateien sind minimal.

Ich habe festgestellt, dass nur Dotnet Fable Watch alleine ausgeführt wird, dass es in den von mir angegebenen Fällen beim Anschauen nicht neu kompiliert wurde - aber vielleicht habe ich etwas dummes falsch gemacht? Oder erwartet fable3, in irgendeiner Weise mit Webpack zu kommunizieren, anstatt nur über die überwachten Dateien zu kommunizieren (es überwacht die .fs, generiert js und electro-webpack oder webpack überwacht die .js)?

Ich habe jetzt einen voll funktionsfähigen Build mit den letzten drei Zeilen meines letzten Beitrags. Es mag seltsam sein, aber es überwacht alles und kompiliert automatisch und HMRs.

Ja, ich bin sehr zufrieden mit Issie. Es hat eine ganz wunderbare Benutzeroberfläche für seinen Zweck. Das Hauptproblem ist draw2d, eine großartige Bibliothek, aber sehr komplex, und der darin enthaltene InteractiveManhattanRouter, der ein sehr intuitives schnelles automatisches Routing von Verbindungen ermöglicht, hat einen js-Fehler, der manchmal zu Endlosschleifen mit Stack-Überlauf führt, wenn Komponenten verschoben werden und daher Verbindungen automatisch weitergeleitet werden. Außerdem macht draw2d viel v teure Berechnungen von Bounding Boxes - in unserem Anwendungsfall ziemlich unnötig - das macht es sehr langsam. Es kann 15 Sekunden dauern, ein großes Designblatt zu laden, und das ist alles, was Draw2d lange braucht, um Figuren zu seiner Leinwand hinzuzufügen.

Es scheint also eine gute Idee zu sein, ein fabelhaftes / elmisches Äquivalent für das zu erstellen, was Issie braucht. Das ist geplant, dass Spring nächsten Sommer in Issie integriert wird, wenn alles gut geht.

Wir haben einige ziemlich große Issie-Projekte - das größte ist eine volle CPU mit etwa 10 Designblättern. Ich halte die Veröffentlichung zurück, bis der Build und die Funktionen ein bisschen mehr aussortiert sind. Wir werden im nächsten Semester von Studenten mit komplexen Schaltungen intensiv genutzt werden, dieses Semester ist weniger geeignet, um Fehler auszubügeln, also sollte es dann gut für die Werbung sein.

Bei der Portierung auf Fable 3 waren die beiden Probleme für mich (abgesehen vom Anschauen von Seltsamkeiten):

(1) SimpleJson.stringify - Ich hatte eine ältere Version des Pakets ohne Serialisierung. Die Readme-Datei dokumentiert gut, dass dies mit Fable 3 verwendet werden muss. Keine Probleme, es zu Json.serialize<'T> zu ändern, sobald ich Pakete aktualisiert habe. Vielleicht könnte Fable3 eine minimale Paketversionsprüfung haben oder so? Aber ich verstehe die Verpackung von Nugets/Paketen nicht richtig.

(2) Die App verwendete List.distinct für eine JS-Objektliste. Das ist unter Fable3 kaputt gegangen, wie Sie sich vorstellen können. Ich habe "distinctBy" und eine String-ID verwendet, um dies zu reparieren.

(3) Ich habe die Kartenleistung mit der alten Fable gemessen. Mein Testfall waren Karten der Größe 3, 20, 100. Ich habe mir die Kartensuche und die Kartenaktualisierung als die beiden Operationen angesehen. Für alle diese Geschwindigkeit war sehr ähnlich. Fable 3 kommt etwa 10 % besser für die größeren Karten.

Hier ist eine (einfache) Schaltung , die zeigt, wie sie etwas tut und Sie den Wellensimulator ausführen können - was ziemlich gut ist.

Vielen Dank @tomcl! Ich habe über Issie getwittert und die Leute lieben es! https://twitter.com/FableCompiler/status/1329451503107641348?s=19

In Bezug auf SimpleJson stützte es sich auf einige Implementierungsdetails, die sich in Fable 3 geändert haben, aber Zaid hat das behoben und in der stabilen Version von Fable werden wir tatsächlich eine Möglichkeit bieten, die Compiler-Version zu unterscheiden, um bei Bedarf sowohl Fable 2 als auch 3 zu unterstützen. Auch @inosik hat das Problem mit List.distinct behoben!

Ich bin mir nicht sicher, ob dies das gleiche Problem ist, aber ich scheine nicht in der Lage zu sein, meinen Ordner mit dem Aufruf von dotnet fable watch entweder im selben Verzeichnis wie das Projekt oder mit dem angegebenen Projekt zu überwachen. Auch mit dotnet fable watch . kein Glück. Ausführen von RC8.

Edit: Auch mit RC10 kein Glück.

Was für mich mit einem komplizierten Elektronenaufbau funktioniert hat, der das Beobachten von main und renderer Prozessen erfordert:

    "compile": "dotnet fable src/main && dotnet fable src/Renderer",
    "dev": "cd src/Main && dotnet fable watch . --run npm run devrenderer",
    "devmain": "cd src/Main && dotnet fable watch . --run npm run webpackdev",
    "devrenderer": "cd src/Renderer && dotnet fable watch . --run npm run webpackdev",

In allen Fällen wird die Uhr auf . . --run wird verwendet, um Webpack auszuführen, während Sie noch zuschauen. Um sowohl den Haupt- als auch den Renderer zu sehen, wird --run zweimal verwendet.

Können Sie bitte überprüfen, ob dotnet watch -p src/Renderer test für Sie funktioniert? Nur um zu überprüfen, ob die eigentliche Dateiüberwachung überhaupt funktioniert. Der Befehl führt dotnet test wenn sich eine Datei in einem referenzierten Projekt ändert.

ja, dotnet watch -p src\Renderer scheint sowohl innerhalb als auch projektübergreifend gut zu funktionieren.

Vielleicht könnte #2301 dabei helfen? Sonst gehen mir die Ideen aus. Wir müssten dies entweder irgendwie debuggen oder von vorne anfangen und Sachen hinzufügen, bis sie kaputt gehen.

Ich denke ich habe es!

Unabhängig davon, ob es sich um System.IO.Path.GetFullPath oder System.IO.Directory.GetCurrentDirectory() , gibt Windows einem API-Aufrufer nur den Namen des Ordners zurück, wie er im Parameter angegeben ist, unabhängig davon, ob es die richtige Großschreibung ist oder nicht.

Also wird System.IO.Path.GetFullPath @"c:\windows" immer "c:\windows" zurückgeben, obwohl es technisch "C:\Windows" ist. Das Gleiche gilt, wenn Ihr Arbeitsverzeichnis in einer Shell oder einem Build-Tool oder was nicht falsch groß geschrieben ist.

Wenn Fable.Cli.Main.FsWatcher.Observe den geänderten Dateipfad mit der Liste der zu überprüfenden Dateien vergleicht und das Arbeitsverzeichnis oder der Pfad in der Befehlszeile falsch groß geschrieben ist, stimmt dies daher nicht überein.

Die einfache Lösung besteht darin, zuerst ToLower() (oder ToUpper() ) für fullPath und für jedes Element in filesToWatch aufzurufen. Dies führt zu einigen falsch positiven Ergebnissen bei Dateisystemen, bei denen die Groß-/Kleinschreibung beachtet wird.

Um absolut sicher zu sein, dass dies nicht der Fall ist, könnte die richtige Lösung darin bestehen, eine der Lösungen für diese SO-Frage zu verwenden – obwohl es ehrlich gesagt wahrscheinlich sicherer ist, einfach jede Datei mit demselben Namen neu zu kompilieren eine andere Großschreibung, als es wäre, falsche Negative zu riskieren, die dadurch verursacht werden, dass die SO-Lösungen auf einigen Dateisystemen nicht getestet wurden.

Wenn Sie ts punktieren und kreuzen möchten, können Sie den gesamten Pfad auf Duplikate überprüfen und eine schwerwiegende Warnung ausgeben, _ohne_ das Material mit falscher Groß-/Kleinschreibung zu kompilieren. Nach dem Prinzip der starken Typisierung könnte man argumentieren, dass es besser wäre, die Falldisziplin auf diese Weise durchzusetzen, als das Fehlen einer solchen Disziplin zu umgehen, die andere Werkzeuge zerstören könnte!

Aber ich bin eher Pragmatiker, in diesem Fall denke ich, dass die Umgehung von Fallproblemen - und auch eine Warnung - die optimale Lösung wäre. FABLE löst ein komplexes technisches Problem, und alles, um Anfängerprobleme zu reduzieren, ist gut.

Dies ist eindeutig ein Fall, in dem ich mich der schweren Desorganisation schuldig mache, indem ich der Groß-/Kleinschreibung von Dateinamen nicht mehr Aufmerksamkeit schenke. Es ist jedoch mühsam, und der Vorschlag von reinux würde dies korrigieren.

Oh je, vielen Dank @reinux! Das macht total Sinn. Eigentlich bin ich ein Idiot, weil wir beim Deduplizieren der Pfade im Ausgabeverzeichnis ein ähnliches Problem hatten und mir nicht eingefallen sind, dass es beim Watcher genauso sein könnte. Ich werde Ihre Lösung anwenden, falsch positive Ergebnisse sollten hier kein großes Problem darstellen und es ist besser, auf Nummer sicher zu gehen, wie Sie sagen. Danke noch einmal!

Cool, danke @alfonsogarciacaro !

Ich habe gerade ein wenig mehr über die Berücksichtigung der Groß-/Kleinschreibung in Dateisystemen gelesen, weil es mich buchstäblich nachts wach hält und es tatsächlich irgendwie erschreckend ist – und nicht einmal nur unter Windows.

Wenn Sie beispielsweise auf *nix ein Dateisystem mounten, bei dem die Groß-/Kleinschreibung nicht beachtet wird, das in seiner Wurzel die Groß-/Kleinschreibung beachtet, wird bei Teilen des Pfads die Groß-/Kleinschreibung beachtet, bei anderen nicht. Der Begriff eines "Dateisystem mit Berücksichtigung der Groß-/Kleinschreibung" ist auch etwas mehrdeutig, da NTFS selbst anscheinend die Groß-/Kleinschreibung nicht Fall ist - aktivieren .

Soooo... Ich habe wahrscheinlich auch schon 3269874 mal den gleichen Fehler gemacht, und ich werde es nicht einmal wissen, bis ich eine Datei oder so vermisse.

Oben ist unten, schwarz ist weiß und die Erde ist flach 😐

... und @reinux verdient mehr als ein Emoticon!

Das Aufräumen des Gehäuses löste meinen seltsamen Build-Fehler #2285 #2293. Aber siehe dort für einen Kommentar, weil ich denke, dass es ein Problem mit Bibliotheken in .fable Verzeichnissen gibt.