| 23 Jan 2024 |
 Moritz Sanft | Was man noch überprüfen könnte: Ist das JUCE-Package, dass du importierst, auf der Version, die Ultraschall-Soundboard required? Falls nicht könnte es natürlich sein, dass bestimmte Symbole noch nicht oder nicht mehr in JUCE definiert sind. | 15:37:54 |
 Benedikt Ritter (britter) | Das werde ich mal nachsehen. Aber es kommen so viele Fehler, dass ich glaube, dass JUCE garnicht richtig gefunden wird. | 15:38:28 |
| Moritz Sanft | Hier noch ein Paar weitere Infos zum Compilen und Linken (spezifisch für C, aber trifft eigentlich auch auf alles andere zu, was compiled): https://www.cprogramming.com/compilingandlinking.html | 15:39:04 |
| Benedikt Ritter (britter) | Leider ist das etwas schwierig genau rauszufinden welche Version verwendet wird, weil der Build von Ultraschall einfach immer nur die Source Repos cloned, ohne dass ein commit hash angegeben ist 🙄️ | 15:39:15 |
| Moritz Sanft | Ah. Es wäre am besten, wenn man die Dependencies alle über Nix zur Verfügung stellen würde | 15:40:00 |
| Benedikt Ritter (britter) | Das hat man davon, wenn man Wirtschaftsinformatik studiert und es im ersten Semester direkt mit Java losgeht 🙂️ Bin auch bei keinem Job mal mit was anderem in Beruehrung gekommen. Java hat immer alle Rechnungen bezahlt 😁️ | 15:40:22 |
| Benedikt Ritter (britter) | In reply to @msanft:matrix.org
Ah. Es wäre am besten, wenn man die Dependencies alle über Nix zur Verfügung stellen würde Ja, da arbeite ich ja dran... Ich hab in meiner Derivation das Repo gefetchet und dann juce als buildInput uebergeben. | 15:40:54 |
| Moritz Sanft | Also im Bachelor habe ich auch nur Python und Java gemacht -- Leider. Im Master wurde man dann ins kalte Wasser geschmissen. | 15:41:29 |
| Moritz Sanft | Also Ultraschall-Soundboard hat einfach einmal den kompletten JUCE-Source in ihrem Repo, oder? | 15:43:16 |
| Benedikt Ritter (britter) | In reply to @msanft:matrix.org
Also Ultraschall-Soundboard hat einfach einmal den kompletten JUCE-Source in ihrem Repo, oder? Ja! https://github.com/Ultraschall/ultraschall-soundboard/tree/main/JUCE Dann macht es vermutlich keinen Sinn, dass ich das noch mal als buildInput uebergebe 🤔️ | 15:46:41 |
| Moritz Sanft | Es wäre vermutlich sinnvoll, das als Buildinput zu übergeben und dann Ultraschall-Soundboard zu sagen, dass die nicht dden JUCE-Source aus ihrem Repo bauen sollen (vermutlich als Patch in der CMakelists.txt). Kenne mich aber selbst leider überhaupt nicht mit CMake aus. Da hast du dir auf jeden Fall eine harte Nuss zum packagen ausgesucht. :D | 15:47:56 |
| Moritz Sanft | add_subdirectory("./JUCE" JUCE) ggf. könnte man das hier so patchen, dass der JUCE-Source aus nixpkgs genutzt wird. | 15:49:17 |
| Moritz Sanft | Sonst würde ich JUCE aus den Buildinputs rausnehmen. Das dürfte auch funktionieren. | 15:49:35 |
| Benedikt Ritter (britter) | Ach, das waere nicht das erste Problem, das ich hier loesen muss. Ich musste ja schon die ganze StudioLink Geschichte packagen. Das habe ich nach vier Wochen letztens endlich fertig gehabt. Da dachte ich, jetzt wuerde es einfach werden. Naja, dann kam halt Soundboard :) | 15:53:24 |
| Benedikt Ritter (britter) | In reply to @msanft:matrix.org
add_subdirectory("./JUCE" JUCE) ggf. könnte man das hier so patchen, dass der JUCE-Source aus nixpkgs genutzt wird. Aber die sourcen sind ja nicht in nixpkgs, nur der build output, oder? | 15:53:56 |
| Moritz Sanft | Genau, aber du könntest auch den Source mit nixpkgs fetchen und den dann reingeben (z.B. fetchFromGithub). Dürfte aber nichts ändern im Vergleich zu einfach JUCE als BuildInput rausnehmen. Hilft dir nur später bei Reproducibility | 15:55:04 |
|  blipp joined the room. | 21:58:49 |
| 2 Feb 2024 |
| Benedikt Ritter (britter) | In reply to @msanft:matrix.org
Genau, aber du könntest auch den Source mit nixpkgs fetchen und den dann reingeben (z.B. fetchFromGithub). Dürfte aber nichts ändern im Vergleich zu einfach JUCE als BuildInput rausnehmen. Hilft dir nur später bei Reproducibility Hab gar nicht mehr geantwortet. Bin noch nicht dazu gekommen weiter zu machen. Ich glaube hinsichtlich Reproducibility waere es besser das JUCE zu nehmen, welches im Repo ist. Dann passt es immer zum Code. Vielleicht muss ich den buildInput wieder rausnehmen und dann die richtigen make und ld flags setzen, damit es verwendet wird? | 20:01:15 |
| Benedikt Ritter (britter) | Mal ne andere Frage: Derivations laufen ja in einer Art Sandbox. Sind aus der Sandbox heraus http requests moeglich? Ich hab da eine Derivation, welche Gradle aufruft. Aber der Gradle Build kann seine Plugins nicht aufloesen. Wenn ich das Repo clone und den Build dort ausfuehre funktioniert es :-/ | 20:02:51 |
| Benedikt Ritter (britter) | nix build github:britter/nix-configuration/bene/issues/4#groovy-language-server
| 20:03:10 |
 CRTified | In reply to @britter:yatrix.org
Mal ne andere Frage: Derivations laufen ja in einer Art Sandbox. Sind aus der Sandbox heraus http requests moeglich? Ich hab da eine Derivation, welche Gradle aufruft. Aber der Gradle Build kann seine Plugins nicht aufloesen. Wenn ich das Repo clone und den Build dort ausfuehre funktioniert es :-/ Nein, man kann die sandbox aber deaktivieren | 20:24:21 |
| CRTified | Ist aber nicht sinnvoll normalerweise | 20:25:57 |
| Benedikt Ritter (britter) | Wie macht man es denn, wenn man in der derivation ein tool nutzen will, welches http requests machen muss? | 20:32:28 |
| CRTified | Fixed output derivations sind da iirc die Antwort | 20:38:07 |
| CRTified | https://bmcgee.ie/posts/2023/02/nix-what-are-fixed-output-derivations-and-why-use-them/ | 20:38:50 |
| Benedikt Ritter (britter) | Ich habe hier das gefunden: https://github.com/NixOS/nixpkgs/pull/72306/files#diff-6055d07eece505268ab5fe931a712118d8bc4ef8de2d484d624ea371a26761c4R51-R69 Verstehe aber nicht, warum in dieser derivation die dependencies geladen werden koennen. | 20:41:39 |
| CRTified | Ist eine fixed output derivation | 20:43:16 |
| CRTified | Also zumindest der erste teil | 20:43:22 |
| CRTified | outputHashAlgo = "sha256";
outputHashMode = "recursive";
outputHash = "1sscxrr32f2agwz34pm491xqkz7m4bwdc1p3g64kcnl3p6rg7r7k"; | 20:43:25 |
| Benedikt Ritter (britter) | Ach so, jetzt verstehe ich. | 20:43:30 |
