• 97 Posts
  • 4.45K Comments
Joined 5 years ago
cake
Cake day: May 31st, 2020

help-circle

  • Ephera@lemmy.mltoich_iel@feddit.orgich⚡🚲iel
    link
    fedilink
    Deutsch
    arrow-up
    8
    ·
    6 hours ago

    Berg hochradeln ist einfach ätzend. Ohne gute Gangschaltung braucht es extrem viel Kraft. Mit guter Gangschaltung strampelst du dich trotzdem noch zu Tode, weil du sonst zu langsam wirst und das Gleichgewicht verlierst.

    Berg runterradeln ist hingegen sehr angenehm, weil du i.d.R. gar nicht treten musst.



  • Ephera@lemmy.mltoWikipedia@lemmy.worldFreedom fries
    link
    fedilink
    English
    arrow-up
    5
    ·
    8 hours ago

    The political renaming occurred in context of France’s opposition to the proposed invasion of Iraq.

    Jeez, I understand that self-reflection isn’t the strong suit of these people, but you’d think at some point they would consider whether branding the bombing of a country as “freedom” really makes sense.





  • That’s definitely being done. It’s referred to as “tool calling” or “function calling”: https://python.langchain.com/docs/how_to/tool_calling/

    This isn’t as potent as one might think, because:

    1. each tool needs to be hooked up and described extensively.
    2. the naive approach where the LLM generates heaps of text when calling these tools, for example to describe the entire state of the chessboard as JSON or CSV, is unreliable, because text generation is unreliable.
    3. smarter approaches, like having an external program keeping track of the chessboard state and sending it to a chess engine, so that the LLM only has to forward the move that the user described, don’t really make sense to incorporate into a general-purpose language model. You can find chess chatbots on the internet, though.

    But all-in-all, it is a path forward where the LLMs could just do the semantics and then call a different tool for each thinky job, serving at least as a user interface.
    The hope is for it to also serve as glue between these tools, automatically calling the right tools and passing their output into other tools. I believe, the next step in this direction is “agentic AI”, but I haven’t yet managed to cut through the buzzword soup to figure out what that actually means.






  • Man pages are displayed in less (which acts as the so-called “pager” here), so you can search man pages interactively like you search in less. And you do that by pressing /, then typing your search term and pressing Enter. Then you can jump between results with n and Shift+n. This is also how search works in vim, by the way.

    Perhaps another tip in this regard, to search in your command history with Bash (for re-running a command you’ve previously used), you can press Ctrl+R, then start typing your search term. Pressing Enter will run the displayed command. To skip to older search results, press Ctrl+R again. If you want to edit a command before running it, press or Ctrl+F instead of Enter.
    This UI is a bit fiddly in Bash, but worth figuring out.

    As for Fish, it’s great for new users, because:

    • it has a much more intuitive Ctrl+R UI, displaying all the search results interactively and not behaving weirdly in certain situations.
    • it automatically sifts through your command history as you type and suggests the most recent command which starts with the prefix you typed. You can fill in its suggestion with or Ctrl+F, or only use the next word from it via Alt+F. You can skip to older matches with , which is then a proper search like Ctrl+R in Bash, so not just prefix-matching. And yeah, overall just really useful, because it’ll both make it quicker to run frequently-used commands, and sometimes suggest a complex command which I didn’t even remember that I once ran.
    • its tab-completion shows short descriptions of what most (sub-)commands or arguments do.

    But:

    • don’t set it as your system-wide default shell or there’s some chance of shell scripts not executing correctly. What you should do instead, is to set it as the startup command to run in your terminal emulator.
    • the syntax of Fish is somewhat different to that of Bash, which can be confusing when you’re still learning the Bash syntax. It’s not the worst thing in the world, as it basically only affects scripting and more complex command chains.
      Scripting is not a problem, because you can throw a shebang into the first line to use Bash syntax (#!/bin/sh or #!/bin/bash). You should add a shebang to your scripts anyways.
      And running more complex commands isn’t too big of a deal either, because you can run bash in your terminal to launch Bash, then paste the command into there to run it, and then quit back to Fish with exit or Ctrl+D. Typically you’ll know to run bash, because Fish’s syntax highlighting turns red after you’ve pasted a complex command.








  • It feels more solid to have a complex program covered by tests, yes, but how can this be confirmed in an objective way? And if it can, for which kind of software is this valid? Are the same methodologies adequate for web programming as for industrial embedded devices or a text editor?

    Worth noting here that tests should primarily serve as a (self-checking) specification, i.e. documentation for what the code is supposed to do.
    The more competent your type checking is and the better the abstractions are, the less you need to rely on tests to find bugs in the initial version of the code. You might be able to write code, fix the compiler errors and then just have working code (assuming your assumptions match reality). You don’t strictly need tests for that.

    But you do need tests to document what the intended behaviour is and conversely which behaviours are merely accidental, so that you can still change the code after your initial working version.
    In particular, tests also check the intended behaviour of all the code parts you might not have realized you’ve changed, so that you don’t need to understand the entire codebase every time you want to make a small change.