Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)R
Posts
2
Comments
133
Joined
2 yr. ago

  • Looks nice. It has a very good “wooow” effect

  • I would have liked a link to the LKLM thread. Usually they are quite informative

  • I use a 42 key layout modified from bépo (french dvorak inspired layout) with the altgr layer of ergol. Go check this altgr layer it's awesome for programming, and there is a version compatible for qwerty and lafayette.

     
        
    ╭╌╌╌╌╌┰─────┬─────┬─────┬─────┬─────┰─────┬─────┬─────┬─────┬─────┰╌╌╌╌╌┬╌╌╌╌╌╮
    ┆     ┃   ¹ │   ² │   ³ │   ⁴ │   ⁵ ┃   ⁶ │   ⁷ │   ⁸ │   ⁹ │   ⁰ ┃     ┆     ┆
    ┆     ┃   ₁ │   ₂ │   ₃ │   ₄ │   ₅ ┃   ₆ │   ₇ │   ₈ │   ₉ │   ₀ ┃     ┆     ┆
    ╰╌╌╌╌╌╂─────┼─────┼─────┼─────┼─────╂─────┼─────┼─────┼─────┼─────╂╌╌╌╌╌┼╌╌╌╌╌┤
    ·     ┃     │   ≤ │   ≥ │  *¤ │   ‰ ┃  *^ │     │   × │  *´ │  *` ┃     ┆     ┆
    ·     ┃   @ │   < │   > │   $ │   % ┃   ^ │   & │   * │   ' │   ` ┃     ┆     ┆
    ·     ┠─────┼─────┼─────┼─────┼─────╂─────┼─────┼─────┼─────┼─────╂╌╌╌╌╌┼╌╌╌╌╌┤
    ·     ┃     │   ⁽ │   ⁾ │     │   ≠ ┃  */ │   ± │   — │   ÷ │  *¨ ┃     ┆     ┆
    ·     ┃   { │   ( │   ) │   } │   = ┃   \ │   + │   - │   / │   " ┃     ┆     ┆
    ╭╌╌╌╌╌╂─────┼─────┼─────┼─────┼─────╂─────┼─────┼─────┼─────┼─────╂╌╌╌╌╌┴╌╌╌╌╌╯
    ┆     ┃  *~ │     │     │   – │     ┃   ¦ │   ¬ │  *¸ │     │     ┃           ·
    ┆     ┃   ~ │   [ │   ] │   _ │   # ┃   | │   ! │   ; │   : │   ? ┃           ·
    ╰╌╌╌╌╌┸─────┴─────┴─────┴─────┴─────┸─────┴─────┴─────┴─────┴─────┚ · · · · · ·
    
      
  • Yeah, this make sence

  • It's also what I understood from what I read but I assume it was just a poor choice of word. Debug symbols are way too important for debugging to be stripped by default.

  • That's only a summary of the introduction! The full story is much more interesting

  • That's a really good explanation. I would just add that I find easier to search for orphans with git log --graph --reflog than using `git reflog directly, especially if it's one of the top entries in the reflog.

  • vim can have IDE-like capabilities thanks to lsp and tree-sitter. That's a real game changer and is quite easy to set-up with something like kickstart.nvim.

  • If you have references explain why and how that it’s easier to port C to a new architecture by creating a new compiler from scratch than to either create a backend for llvm (and soon gcc) or to create a minimal wasm executor (like what zig is doing) to this new architecture I’m interested. And of course I talking about new architectures because it’s much easier to recreate something that as already be done before.

  • I’m not familiar with C tooling, but I have done multiple projects in C++ (in a professionnel environnement) and AFAIK the tooling is the same. Tooling to C++ is a nightmare, and that’s and understatement. Most of the difficulty is self inflicted like not using cmake/meson but a custom build system, relying on system library instead of using Conan or vcpkg, not using smart-pointers,… but adding basically anything (LSP, code coverage, a new dependency, clang-format, clang-tidy, …) is horrible in those environments. And if you compare the quality of those tools to the one of other language, they are not even close. For exemple the lint given by clang-tidy to the one of Rust clippy.

    If it took no more than an hour to add any of those tools to a legacy C project, then yes it would be disingenuous to not compare C + tooling with Rust, but unfortunately it’s not.

  • With Bram Moolenaar death, I sincerely think that vim will no longer be able to play catch-up with nvim. Bram Moolenaar did an amazing job with nvim, but with its death I think that vim is going to be an editor of the past, just like vi is an editor of the past. And nvim is its successor since its where the developers have moved.

  • Nice try kiddo!

  • I never had to use this estimate in front of a client, but if I had, I would decompose it first before giving the total estimate. If there is about 10 items to do per button, so 10 buttons would be a hundred complexe tasks. So let say that it take an hour per task, but since we are fast we can do 10 a day. So suddenly 10 working days, or said otherwise 2 weeks don't seems unrealistics for this apparently simple 10 buttons task.

  • As a rough estimation, if you include everything (apperance, discussion, functionality, interaction with other controls, …) I would say that every single input field or button is about a day of work. And then you start to realise how many buttons there is in any GUI and how much it will cost.

  • Usually when people say “I suck at maths”, it means that they are bad at doing manual calculus. Maths is extremely useful in programming, but it’s absolutely not the same kind of math. I don’t think that the grade you had in math at school will influence in any if you will be good or bad in programming.

  • That's an interesting idea to use zig to test C code. It's quite an achivement for zig to be better than C at testing C code. I really hope for them that this language will become popular.

    And this post was interesting to see how a new user of zig approaches that language

  • I would even have said that both throwing and catching should be pure, just like returning an error value/handling should be pure, but the reason for the throw/returning error itself is impure. Like if you throw and ioerror it's only after doing the impure io call, and the rest of the error reporting/handling itself can be pure.

  • I'm surprised about this statement, I would have said that exceptions are the consequence of an impure operation (that may or may not fail differently every time you call it).

  • There take on what they call capabitilites is very interesting. Basically anything that would make a function non-pure seems to be declared explicitely.

    A computational effect or an "effectful" computation is one which relies on or changes elements that are outside of its immediate environment. Some examples of effectful actions that a function might take are:

    • writing to a database
    • throwing an exception
    • making a network call
    • getting a random number
    • altering a global variable