Massive update to get images on pages, fix details, titles, ...

TODO.txt

@@ -0,0 +1,31 @@
+Urgent:
+- [ ] Images sam
+- [ ] Finir la plannif
+- [ ] MVP
+- [ ] Epoll (ptetre lier ca a BD ?)
+- [ ] Changer le _index.org qui fait qu on arrive sur Utils
+
+N importe quand:
+- [ ] error.CeQueJeVeux
+- [ ] Corriger le feedback web et concu
+- [ ] tout relier et mettre Dans mes conclusion mettre des liens vers ma doc
+- [ ] Essayer export pdf avec les nouveaux ***
+- [ ] Noter tous les documents checkes et pas checks
+- [ ] Page accueil Hextra, avec gh, presentation, images, ...
+- [ ] Verifier que tous les premieres scripts sont exectuables
+- [ ] Un script pour lancer les serveurs se serait pas mal
+- [ ] https://zig.news/minosian/deciphering-many-item-types-the-skeleton-19i
+
+Fin: 
+- [ ] sources zotero
+
+Peut etre:
+- [?] Websocket
+- [?] Zig and C TODO Add other languages that can use C code and make a graph with matplotlib
+- [?] CICD
+- [?] debug, binutils, breakpoints, debugger
+
+Questions:
+- Moyen que l expert regarde le site plutot que le document PDF pour la doc ?
+
+

content/docs/#errors.org#

@@ -0,0 +1,95 @@
+#+title: Errors
+#+weight: 3
+
+** Errors
+In ZIG, [[https://ziglang.org/documentation/master/#Errors][errors]] are juste values.
+
+Those values are those of a special type of enum, that looks just like an enum but with the =error= keyword added.
+#+begin_src zig
+  const TcpConnectionError = error{
+      HandshakeFailed,
+      ConnectionClosed,
+      UnexpectedData,
+  };
+#+end_src
+
+When you declare your enum using this keyword instead of =enum=, the compiler is going to know that those values are going to be errors, therefore they can be catched, tried and so on.
+
+If you want to return an error without having to make a whole enum for that, you can just return =error.MyPeronalError= like so.
+#+begin_src zig
+      return error.MyPersonalError;
+#+end_src
+
+#+RESULTS:
+
+*** Handling errors in the application flow
+Functions can return either a value or an error, this is done by adding the =!= to the return type of a function
+With the =!= the return type of the function below is the coerced =anyerror!u8=, which means that it can either return the excepted value or an error.
+
+This way of handling errors is different from languages like Rust for exemple where you encapsulate the error or the value in a completly different type, the =Result= type.
+
+Note that since error sets are just enums, under the hood all the errors are just =u16= by default.
+
+It is important the the syntax of the type is =ErrorSet!Payload= and not =Payload!ErrorSet=. You first have to precise the error and then the payload, it is not possible to mix them up.
+
+When a function can return an error we have to either =try= or =catch= it.
+
+=try= is going to either get the result or the error. If your function contains a =try= statement, it has to return a =!T= type, where =T= it the type of the excepted value.
+
+=catch= is going to treat the error and return a value even if an error occured.
+
+#+begin_src zig :imports '(std)
+  fn maybeErrorMaybeValue(isError: bool) !u8 {
+      // ... might return an u8 or an error
+      if (isError) {
+          return error.Bar;
+      } else {
+          return 2;
+      }
+  }
+
+  test "return value or error" {
+      // "try" version
+      const res = try maybeErrorMaybeValue(false); // if error, return the error
+      try std.testing.expect(res == 2);
+
+      // "catch" version
+      const err = maybeErrorMaybeValue(true) catch 3;
+      try std.testing.expect(err == 3);
+  }
+
+  test "should panic" {
+      _ = maybeErrorMaybeValue(true) catch unreachable;
+  }
+#+end_src
+
+*** anyerror
+This is the global error set containing all the possible errors that can happen in the current compilation unit. It is the superset of all the errors.
+
+This is the default error used when you just add the =!= withtout precsing the error type. Which means that =!u64= is just a syntaxic sugar for =anyerror!u64=.
+
+*** Errdefer
+  This exemple is taken from the [[https://ziglang.org/documentation/master/#errdefer][official documentation]]
+  [[https://ziglang.org/documentation/master/#errdefer][errdefer]] is a particularity of ZIG, it allows the user to execute some code when the function returns an error, it is useful exemple for deallocating variables you would have normally returned from the function, but since the function failed you deallocate that memory to avoid a memory leak.
+  #+source: simple
+  #+begin_src zig :imports '(std)
+    fn createFoo(param: i32) !Foo {
+       const foo = try tryToAllocateFoo();
+       // now we have allocated foo. we need to free it if the function fails.
+       // but we want to return it if the function succeeds.
+       errdefer deallocateFoo(foo);
+
+       const tmp_buf = allocateTmpBuffer() orelse return error.OutOfMemory;
+       // tmp_buf is truly a temporary resource, and we for sure want to clean it up
+       // before this block leaves scope
+       defer deallocateTmpBuffer(tmp_buf);
+
+       if (param > 1337) return error.InvalidParam;
+
+       // here the errdefer will not run since we're returning success from the function.
+       // but the defer will run!
+       return foo;
+   }
+#+end_src
+
+

content/docs/allocators.org

@@ -3,7 +3,6 @@
 
 #+bibliography: bibliography.bib
 
-* Allocator
 The Zig language doesn't hide the memory management, the mantra of Zig is to have no hidden control flow.
 Like the C language, Zig has manual memory management however, Zig will offer the programmer different allocators that allow him to handle exactly how to use his memory.
 That's why Zig doesn't have a runtime and it can be used without the ~libc~ runtime.
@@ -358,4 +357,3 @@ Adding the ~libC~ in the project will add more dependencies.
 Allocators are a great feature of Zig, they allow the programmer to have full control over the memory management while still having some nice tools to work with: like detecting memory leaks for exemple. The Zig allocators are not as restrictive as Rust's borrow checker, but they still come with great tools. On the other hand they are nice abstraction over C like heap allocations systems.
 
 {{< references >}}
->>>>>>> main:content/docs/allocators.org

content/docs/build-system.org

@@ -6,8 +6,6 @@
 
 #+HTML_MATHJAX: align: left indent: 5em tagside: left
 
-* Build system
-
 ** Build modes
 Zig build modes are way easier for beginners to graps compared to [[https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html][C]]
 

content/docs/code-styles.org

@@ -2,7 +2,6 @@
 #+weight: 4
 #+bibliography: bibliography.bib
 
-** Code styles
 All of the above affirmations are taken from the [[https://ziglang.org/documentation/master/#Style-Guide][Zig Style Guide]] itself.
 
 Here we just point out what we consider the most important.

content/docs/compiler-messages.org

@@ -1,7 +1,6 @@
-#+title: Compiler messages
+#+title: Unclear compiler messages
 #+weight: 10
 
-** Compiler messages
 In a language that aims to report most of its issues at compilation time, it is important to have clear and concise error messages. However at the time we are writing this it is sadly not the case. Here are a few compiler messages that you might encounter that are very hard to understand.
 
 *** Trying to print without the incorrect struct syntax

content/docs/comptime.org

@@ -2,7 +2,6 @@
 #+weight: 11
 #+bibliography: bibliography.bib
 
-* Comptime
 Zig has a concept called ~comptime~, it's stands for "compile-time".
 Comptime is used to evaluate an expression at compile time and not at runtime.
 In comparison with C, Zig comptime has the purpose of replacing marco with a more explicit syntax.

content/docs/concurrency/async_await.org

@@ -20,7 +20,7 @@ You can see [[https://ziglang.org/download/0.12.0/release-notes.html#AsyncAwait-
 By adding async/await you introduce a new problem. Tracking the execution flow of the program becomes much harder and inpredictable and this job is done by the compiler, providing a sequential looking code to the user. With function coloring introduced every async code has to be called in an async function, which may lead to situations where you have to refactor a lot of your code to be async just for a few functions. This is very nicely sumed up by this [[https://x.com/ryanrwinchester/status/1702730128520830994][image from Ryan Winchester]]
 #+CAPTION: Function coloring
 #+NAME:   fig:SED-HR4049
-[[/images/fcolor.png]]
+[[/HEIG_ZIG/images/fcolor.png]]
 
 Here is an exemple in JavaScript where you have to have an =async= main function because it is calling an other async function, if you remove the =async= keyword from the main function it is not going to work anymore.