07:43:11 XanClic joined the channel
08:23:36 kevin joined the channel
09:12:04 XanClic: https://git.xanclic.moe/XanClic/bare-rust hat übrigens wirklich eigentlich so getan, wie es war
09:12:30 XanClic: Multibootheader in Rust hat leider nicht funktioniert, weil das als toter Code entfernt wurde
09:12:52 XanClic: Und ich wüsste nichts von einem Rust-__attribute__((used))
09:13:02 XanClic: also ist der jetzt halt in einem Assemblerstub
10:00:37 kevin: Wenn man Nicht-Rust-Zeug einbauen will, muss man mit Cargo ein Rustprogramm schreiben, das das externe Zeug aufruft? Spannend.
10:02:17 kevin: Müsste man nicht auch was memset-artiges bauen können, das safe ist, wenn es nur einen Slice nimmt statt Pointer und Länge?
10:03:19 XanClic: Muss man nicht, man kann sein Rustprojekt auch als Bibliothek bauen lassen und dann ganz normal gegen andere Sachen linken
10:03:27 kevin: Oder geht das sogar mit einer einfachen Zuweisung?
10:03:29 XanClic: memset ja, memmove eher nicht
10:03:43 xq: huhu
10:04:11 XanClic: (hatte ich überlegt zu machen, und dann ist mir aufgefallen, dass ich schlecht zwei überlappende Teilslices bekommen kann, die ich einem safe-memmove geben kann)
10:04:37 XanClic: (gut, man könnte eine memmove-Variante machen, die auf einem einzigen Slice arbeitet, mit zwei Start-Indices)
10:04:51 XanClic: moin xq
10:04:54 kevin: Würde in diesem Fall reichen, ja
10:05:14 XanClic: Jedenfalls zu build.rs: Das würde ich entscheiden, je nachdem, ob Rust die Hauptsprache ist oder nicht
10:05:18 kevin: Aber sonst wird das wohl schwierig. Wie sind denn die Slice-Regeln? Ist das gleich, wie eine Referenz aufs ganze zu nehmen?
10:05:39 XanClic: Wenn Rust die Hauptsprache ist, dann find ich das sorum mit build.rs besser; wenn Rust nur ein Modul ist, dann sollte das eine Bibliothek sein, die in den Rest gelinkt wird
10:05:49 XanClic: Eigentlich nicht
10:06:04 XanClic: ich denke, man kann gleichzeitig eine Referenz auf a[0..x] und a[x..n] haben
10:06:08 XanClic: also auch mut
10:06:17 XanClic: hab ich jetzt nicht ausprobiert, aber würde ich hoffen
10:06:18 xq: build.rs?
10:06:40 XanClic: xq, build.rs wird von cargo kompiliert und ausgeführt, bevor/während das Projekt gebaut wird
10:07:02 kevin: Du meinst auch tatsächlich mit Überlappung?
10:07:04 XanClic: Da kann man ein paar Sachen machen und cargo ein paar Optionen geben (wie Features an-/ausschalten, oder zusätzliche Bibliotheken angeben)
10:07:08 XanClic: kevin, das nicht
10:07:17 XanClic: 0..x ist ja [0, x)
10:07:24 XanClic: sonst wärs 0..=x
10:07:25 kevin: Ach so
10:07:31 kevin: Ich kann doch kein Rust
10:07:36 XanClic: Aber Python, dachte ich :)
10:07:44 XanClic: Ruby ist das einzige, was ich kenne, bei dem das inklusiv ist
10:08:00 kevin: Wo hat Python denn ..?
10:08:02 XanClic: Gefällt mir auch besser inklusiv, aber halboffen ist schon, was man meist braucht, insofern…
10:08:03 XanClic: range()
10:08:15 kevin: Jo, das schon
10:08:16 XanClic: 0..x ist doch praktisch range(0, x)
10:08:48 kevin: Ich assoziiere mit ersterem inklusives x, aber frag mich nicht warum
10:09:12 kevin: Wie auch immer, wie kann das der Compiler denn überhaupt zur Buildzeit feststellen, ob es überlappt? Das x kann doch auch tatsächlich eine Variable sein?
10:09:12 XanClic: Weil man es „0 bis x“ liest
10:09:25 XanClic: und das klingt für mich geschlossen
10:09:42 xq: XanClic: ah, wie build.zig dann *grins*
10:09:43 kevin: Jo
10:09:44 XanClic: dann muss ich das jetzt wohl doch ausprobieren
10:11:21 XanClic: > error[E0502]: cannot borrow `*self.buffer` as immutable because it is also borrowed as mutable
10:11:24 XanClic: schade, dann gehts wohl doch nicht
10:12:42 kevin: Ah, vielleicht denke ich auch an "case 0 ... 5:" in gcc, das ist inklusiv
10:14:08 kevin: Oh, und Arrays in Pascal, da ist es auch inklusiv
20:32:09 Paddy joined the channel